8

Ok, after resolving how to Hot-Load a DLL in a running App at Runtime (See my previous post), I have noticed that breakpoints inserted in the freshly loaded DLL are not hit.

Situation
I have a server Application that I want to avoid terminating/re-running every time I make a change to a Dynamically loaded DLL (by Reflection)

Goal
Here is what I am trying to do (I am aware this may not be possible per se) :

  • Run Application.exe
  • Load into it Process.dll in newAppDomain and run Process
  • Debug Process.dll
  • Unload Process.dll
  • Edit Process code, recompile Process.dll
  • Dynamically reload it in Application.exe
  • Debug Process.dll
  • etc...

Problem
I have noticed that when Application.exe is launched in Debug mode, code that is loaded from another AppDomain is unreachable by the debugger attached to Application.exe (I guess If i just launch Application.exe directly from executable file, there is no way to get VS debugger to debug anything, inluding the newly loaded DLL)

Prossible workaround
A workaround (ugly) solution is to separate the "injection" of the DLL into the running App in a separate executable, that would be, then, monitorable by the VS Debugger

I mus admit I am a bit confused. Any efficient, clean ideas ?

Community
  • 1
  • 1
Mehdi LAMRANI
  • 11,289
  • 14
  • 88
  • 130
  • This is very strange. I have an application server which loads application into a secondary app domain and I have no problems setting breakpoints. Is the Process.dll file the output of a class project of the solution you use to start Application.exe from? – Pieter van Ginkel Feb 04 '11 at 11:25
  • It sounds like in your referenced question that you haven't solved the issue of unloading the assembly. In that case, your code wouldn't break since the debug symbols don't match. – Sam Trost Feb 04 '11 at 15:45
  • could be that the place your application is loading the dll from is not where the dll is being built to in debug mode – Asher Aug 14 '13 at 11:25

2 Answers2

3

Since it may help others (as this was a top search result for me), I found that adding a reference to the DLL to the "other" project made it possible to debug the assembly being "injected." While I won't deploy my solution like this, it did allow me to at least debug the code being injected to resolve a problem with otherwise stable code. This suggests the IDE looks at references when determining assembly identity (or similar.)

In this scenario a DebugBreak() does nothing, the VS debugger will not be signaled without the reference being added. I did not test, but would imagine any other debugger would have been signaled just fine, so again this suggests the IDE is explicitly ignoring the signal (other DebugBreak()s work just fine.)

As a veteran .NET developer I have to say this problem is new for me, ie. I would say it's a safe bet that if we load Windows 2000, VS.NET 2001-2002 and this same test code that the breaks signal just fine.

Based on the OPs prior post it's most likely that the assembly being loaded is actually being loaded with a distinct identity, even if it's the same assembly but loaded from a different location/mechanism (for example) the CLR will identify it as a unique assembly, consequently so will the IDE.

Some readers may or may not find LoaderOptimization of value in certain scenarios where they are loading the same assembly between appdomains and notice the same assembly is being loaded multiple times.

HTH someone, I was stumped for about an hour. Thanks.

Shaun Wilson
  • 8,727
  • 3
  • 50
  • 48
1

Does putting System.Diagnostics.Debugger.Break() in your DLL where currently you have breakpoints, throw a break correctly?

http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.break.aspx

If not I'm inclined to agree with Sam, that unload is failing, or you're loading a different library than you think.

stephbu
  • 5,072
  • 26
  • 42