Debug external DLLs with Visual Studio for Unity enabled! [Proper pdb2mdb]

[Asteroid]

Hi guys!

The programmer volunteers among you (and future modders) are gonna love this one.

As of SVN revision 6197 and a rebuild of the DLLs, attaching to Unity with the official Visual Studio Tools for Unity and debugging external DLLs such as AIWarExternalCode.dll just works(TM).

Thanks to the Kerbal Space Program modding community for putting me on the right track! The key was to use a proper pdb2mdb.exe that's compatible with Roslyn-compiled dlls. The one that comes with unity 2019.1 is ironically not compatible.

To debug you can just load the AIW2Unity project in the editor with the ActualGame.unity scene, attach VS Tools For Unity, set breakpoints where you want, and press play.

If Chris adds to Google Drive a standalone build with the "Copy PDB files", "Development Build" and "Script Debugging" options enabled, it would allow people who don't have unity installed to attach a debugger. Perhaps there's a way to add such a build to Steam too, perhaps a release one with only the Script Debugging option enabled? Would save modders who want to debug their AIWarExternalCode.dll the trouble of replacing some files to produce a debuggable build.

[x4000]

Very killer!  I love that you figured this out, thanks for that!

[Asteroid]

Very killer!  I love that you figured this out, thanks for that!

You welcome, I hope it'll facilitate development. I still have a few tweaks to do, namely have the External Code project actually invoke pdb2mdb as a post-build step so it can work for people just using the solution for modding - as opposed to building using the batch files.

For the other issue causing you to have to proxy Linq functionality, I believe that you don't have issues when building with Visual Studio, the problem arises when building with Roslyn/csc.exe directly? If so the solution will be to build the solution on the command-line through msbuild and let it figure out which dlls to reference. Normally, since .NET is a standardized platform you shouldn't have to reference the DLLs that come with Unity for any of the platform stuff. Just target .NET 4.5 or .NET standard, and trust that Unity will provide matching version of the correct assemblies. I hope to have a crack at this myself soon - less of a priority since as you said Linq isn't ideal for high-performance stuff anyways.

[x4000]

Linking against non-unity-version DLLs makes me super nervous, for a few reasons.  In theory you're right that it shouldn't matter what we link against, but I've run into some kind of surprising issues in the past with things not actually working properly if the correct thing wasn't linked against.  I don't remember the details at this point, but I remember fighting with it for hours.