Unity Test player builds dont support debugging - 2020.1.2f1

Test player builds don’t seem to support debugging nor the attachment of the debugger in the first place.

However, regular non-test player builds can have their process attached to/debugged just fine.

Here is a short video I created that outlines how to reproduce this issue:

My company heavily uses the Unity Test Framework. We often find that our PlayMode tests can pass when run in-editor, but will fail when run in the standalone test player builds. For this reason, we really need the ability to properly debug test player builds.

Have you tried using the TestPlayerBuildModifier attribute? The “Modify the Player build options for Play Mode tests” section on this page includes an example which shows enabling debugger attach for builds:

https://docs.unity3d.com/Packages/com.unity.test-framework@1.1/manual/reference-attribute-testplayerbuildmodifier.html

Thanks for the reply, Superpig

Unfortunately, enabling the AllowDebugging build option resulted in il2cpp build failures. I also tried mixing in additional build options that seemed relevant, such as the Development flag.

Attached are the two errors I encountered. Any ideas what might be going wrong?

Thanks again!

7163671–857770–error1.txt (5.94 KB)
7163671–857773–error2.txt (2.67 KB)

Looks to me like this is the important bit in that first log file:

il2cpp.exe didn't catch exception: Unity.IL2CPP.Building.BuilderFailedException: 
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\bin\HostX64\x64\link.exe
/out:"C:\Users\garre\Documents\Repos\vnext\Library\il2cpp_cache\linkresult_2042BCC54CCBC1CC93D27440D14F06D0\GameAssembly.dll"
/ignore:4206 /DEBUG /INCREMENTAL:NO /LARGEADDRESSAWARE
/NXCOMPAT /DYNAMICBASE /NOLOGO /TLBID:1 /OPT:REF /OPT:ICF
/HIGHENTROPYVA /DLL /IGNORE:4104 /NODEFAULTLIB:uuid.lib
"kernel32.lib" "user32.lib" "advapi32.lib" "ole32.lib" "oleaut32.lib" "Shell32.lib"
"Crypt32.lib" "psapi.lib" "version.lib" "MsWSock.lib" "ws2_32.lib" "Iphlpapi.lib"
"Dbghelp.lib"
"C:\Program Files\Unity\Hub\Editor\2020.1.2f1\Editor\Data\PlaybackEngines\WindowsStandaloneSupport\Variations\win64_development_il2cpp\baselib.dll.lib"
/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\lib\x64"
/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x64"
/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x64"
/SUBSYSTEM:WINDOWS @"C:\Users\garre\AppData\Local\Temp\tmpB934.tmp"

9B8A3069390690B30C7EC18046C45CF7.obj : fatal error LNK1136: invalid or corrupt file

The linker is choking on that object file for some reason. I don’t even see it as an input on the command line - my guess is it is specified inside “C:\Users\garre\AppData\Local\Temp\tmpB934.tmp” - but I think the most likely explanation is that somehow that file is corrupt (and cached for reuse between builds), and you should track it down and delete it so that the pipeline is forced to compile it again.

I was able to fix this IL2CPP error by deleting the Library folder, and doing a fresh standalone test player build/run. However, I still found that the test player is not recognized by the Rider debugger, despite my adding the “AllowDebugger” flag in the TestPlayerBuildModifier:

playerOptions.options |= BuildOptions.AllowDebugging;

The test player however, does prompt me to attach a debugger, it just isn’t recognized/displayed as an attachable process when I actually attempt to attach to it with the latest version of Rider (2021.1.2).

Attached is an image of a test player prompting me to attach a debugger, yet rider’s Attach To Unity Process dialogue only showing the Editor process as being attachable.

That’s pretty weird - as far as I know it should work. You might want to reach out to the JetBrains team on this one.

I haven’t tried IL2CPP, but here is a workaround, which worked for me with mono
https://youtrack.jetbrains.com/issue/RIDER-63051#focus=Comments-27-4917206.0-0

1 Like

Hi, you are right about player not being visible in available list. Issue is that we opening broadcasting only when we are in listening code and not when we are connecting from player to editor (this is behaviour we see in the test framework). In my knowledge debugger port is open it is just not announced in network and because of that not visible in the player list. I think as workaround you should be able to connect to it using IP address.

This is of course temporary solution as we are working on improving this behaviour.

1 Like

Yep! Connecting directly via IP address and port solves the problem for me. I was able to attach to unity process in rider, and then connect manually by IP. Thanks for your help.

For future persons reading this, the IP and port of a test player are logged to the test player’s log file

This solution works for me, and I use IL2CPP. Thanks for your help here in Unity forums and In the rider bug tracker :slight_smile: