11

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?

Soner Gönül
  • 97,193
  • 102
  • 206
  • 364
Venatu
  • 1,264
  • 1
  • 13
  • 24

2 Answers2

12

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
8

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.

Jammer
  • 9,969
  • 11
  • 68
  • 115
  • The pdb file is being copied to the same directory, but it still does not trigger breakpoints. They are marked as "The breakpoint will not be hit. No symbols have been loaded for this document". Thanks for the suggestion though – Venatu Aug 12 '13 at 12:47
  • You were correct thanks! The copy method I used did not overwrite the previous version. – Venatu Aug 12 '13 at 12:57