When do I need debugging symbols (pdb or mdb) for external dll?

I’ve followed the basic manual instruction on how to build my own managed plugin in Visual Studio in copy the library into Unity to use. The documentation mentions a command-line process to create a pdb.mdb file next to the pdb and that it is required to have one for debugging. When I built my library from Visual Studio, however, it automatically created:

  • MyLibrary.dll
  • MyLibrary.pdb
  • MyLibrary.pdb.mdb

I did a few tests, both in debug and release by setting a break point in my VS solution, attaching it to Unity and then running the code. The breakpoint was hit as expected. Then I deleted the pdb and pdb.mdb files, expecting the debugging to fail, but it still worked. I practically tested all combinations and everything still worked correctly. I’m using Unity 5.5 and Visual Studio 2015 with the new built-in “Visual Studio Tools For Unity”.

What am I missing here? When do I need those debugging files and which can I omit? Is this only relevant, when I don’t have access to my original solution? Like when the dll throws an exception in Unity and the log gives me a stacktrace etc? Will this only work with symbol files? What about the final built?

Thank you! :slight_smile:

PS: Another mini-issue I have: When building directly into the assets folder, VS will also copy all referenced libraries from the original solution, meaning that things like UnityEngine.dll will be copied into the assets folder as well, which of course I don’t want. Is there any way to omit those when building?

for your last issue, don’t build directly to the unity folder. build to somewhere else and attach a post-build event to your visual studio project. this lets you run basic bat file stuff such as xcopy.

Thanks, this is working. I also found out, that I could select my referenced libraries in VS and on the properties panel set Don’t Copy to Output Folder. This makes it even easier for simple projects, where I don’t have any other dependencies than Unity.

1 Like