For modularity, I am linking to a dll in my solution at runtime rather than compile time to allow for me to update it independently. When I place breakpoints in the library project, these are not triggered when the class is linked to, and a type is created.
For reference, this is the reflection code:
Assembly a = Assembly.LoadFile(FULL_APPLICATION_CACHE + targetVersion + "\\Core.dll");
Type engineCoreType = a.GetType("Core.EngineCore");
object instance = Activator.CreateInstance(engineCoreType);
Is it possible for Visual Studio to offer its normal debugging tools in this scenario? How would I configure this?
To do this, go to the Modules window and from the context menu of a . NET assembly, and then select the Decompile source code command. Visual Studio generates a symbol file for the assembly and then embeds the source into the symbol file. In a later step, you can extract the embedded source code.
The debugger needs to be able to find the .pdb file for the assembly. You can diagnose this from the Debugger + Windows + Modules window. Right-click the DLL and choose Symbol Load Information, it shows you where the debugger looked for the PDB.
Do note that you should never use Assembly.LoadFile() in this scenario, it loads assemblies without a loading context. An expensive word that means that the CLR pays no attention to where the DLL came from and allows you to load the DLL more than once. In itself an explanation for why the debugger can't find the PDB. Always use LoadFrom() instead.
You need to make sure the .pdb files are in the same location as the dll you are loading. Visual Studio will then load that data and allow it to stop at break points.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With