Debuggable does not work for assemblies loaded via reflection RRS feed

  • Question

  • I have a rather complicated scneario. Let's say we have 3 assemblies: a.exe, b.dll and c.dll. b.dll references c.dll. I start a.exe, it does the following:

    1. Loads b.dll via reflection (Assembly.LoadFrom ("b.dll"))

    2. Pauses and waits for the user to attach a debugger.

    Now I attach VS on a.exe and I examine loaded modules. I can see that b.dll is not optimized but c.dll is, although both are built with /optimize- option. I have also verified with IL Spy that c.dll is indeed tagged with Debuggable attribute. If I create a d.exe and reference c.dll directly and debug d.exe in VS, c.dll is not optimized. So I'm pretty sure it's how c.dll is loaded that makes it not debuggable.

    Any ideas why this is happening? Let's assume launching a.exe from VS directly is not an option. Thanks.

    Tuesday, October 30, 2012 3:29 AM

All replies

  • Hi Deling,

    Welcome to the MSDN Forum.

    I am trying to involve some other one in this thread, please wait it patiently.

    Best regards,

    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, October 31, 2012 5:49 AM

  • I get different behavior -- a and b are shown as optimized, while c is not.

    If I change a so that I can attach before the LoadFrom("b.dll"), and attach before loading b, then a is optimized, b and c are not. In other words, modules loaded after the debugger attached are not optimized.

    You haven't said where you're going with this, but you can use an ini file to disable optimizations for the whole app. Create an a.ini with these contents:

    [.NET Framework Debugging Control]

    And you should see all modules non-optimized when attaching to a.exe. Use these ini file contents for 'normal' behavior:

    [.NET Framework Debugging Control]

    More info:


    Friday, November 2, 2012 8:45 PM