- Home /
VSTU Debugging with Remote Symbols and Sources
Howdy - my team is writing libraries for use with Unity across our entire development studio.
We have taken the approach of compiling our libraries into DLLs so we can unit test them and use them outside Unity. We have also packaged them as NuGet packages so we can track transitive dependencies among libraries.
We are having trouble debugging the libraries using VSTU.
We have TeamCity configured as both a source and symbol server. We have Visual Studio (2015) configured to use the source and symbol servers from TeamCity. For non-Unity projects, like servers, when the local development environment lacks symbols and sources, Visual Studio automatically goes to the network and obtains the symbols and also the sources. Everything is wonderful.
When we try to debug Unity using this setup, almost nothing works correctly.
When I open the Debug -> Windows -> Modules dialog in VS, only the Assembly-CSharp symbols are loaded despite "Right Click -> Load Automatically" being checked. The dialog fails to identify where the symbols are loaded from (Symbol File) and several other attributes. When I "Right Click -> Load Symbols", nothing appears to happen. I have symbol files (PDBs and their automatically generated MDBs) copied into the same directory as the DLL included in the Unity project. I pcap'd the network and am pretty sure that VS is not even trying to load PDBs from the Debug -> Options -> Symbols symbol servers.
When I include a reference to the original project in my Unity game solution but it is in a different directory than that from which the DLL came, it fails to load the debugging symbols despite searching included projects being supported by native VS.
The other search option supported by native VS is searching "Solution -> Common Properties -> Debug Sources". The properties on Unity solutions are disabled by VSTU.
The one and only one thing that appears to work is :
Copy the DLL into the Unity project
Copy the PDB into the same location
Leave the source in the same file system location that the DLL/PDB thinks it originally came from
Under these very special circumstances, VSTU will report the Symbols as loaded and permit stepping into the source.
Other debug options like "Show disassembly if source is not available" do not work.
Have you come with a conclusion about how to debug it?