Debugging .net libraries in both the GAC and local folder

[phnimx]

Hi ,
We have developed a number of plug-in .NET Library Components that we
typically deploy with our various applications by installing them into the
GAC.
Each of the applications contains an app.config file referencing arbitrary
versions of the plug-in components they wish to consume.

Here's the problem:

Assuming I have installed any one of our application software,

when working on any of these plug-in library assemblies as a developer in
Visual Studio, I'd like to be able to debug the plug-in library assemblies
similar to the way we can in C++, either select a surrogate exe that
references the plug-in, from the VS Project/Debug tab to use for debugging
or "Attach to Process".



Neither technique works. I can't set or hit any breakpoints I've set. What's
worse, I can't use the VS Disassembly Window to reference the disassembled
code and set a breakpoint there either, as it never finds the symbols.



My questions:

1 Can anyone supply a tip on how to truly debug a local library assembly
(dll) when the same version of that assembly resides in the GAC.

2 Is there a technique for debugging the library assembly (dll) that resides
in the GAC?

3 Do assemblies have the concept of symbols and symbol files?

4 Can anyone supply web links to advanced debugging techniques in .NET,
specifically for C#?

Thanks

 

[Michael Nemtsev]

Hello phnimx,

p> 1 Can anyone supply a tip on how to truly debug a local library
p> assembly (dll) when the same version of that assembly resides in the
p> GAC.

use codeBase element in your app.config

p> 3 Do assemblies have the concept of symbols and symbol files?

Do u mean PDB? you can generate debugging symbol for release turning this
feature in project properties

p> 4 Can anyone supply web links to advanced debugging techniques in
p> .NET, specifically for C#?

recommend to read this first http://www.codeproject.com/dotnet/demystifygac.asp
put PDF next to the GAC assembly and user the general way of debugging http://groups.google.com/groups/search?q=dotnet+debug+GAC
---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

Based on my understanding you want to debug your class library assembly
that resides in the GAC.

Can you tell me what type of application that consumes your plug-in
assembly, console, winform, or Asp.net? I assume it is not Asp.net first.
Then, what type of debugging you want to perform over the plug-in assembly,
source code level, IL level or binrary code level? Do you have the source
code of the class library assembly in project form? Finally, what version
of .Net you using, .Net1.1 or 2.0? This information will help me understand
your problem context more accurate. Thanks.

Below is my further comment:

#1, yes, after you have deployed the signed assembly to the GAC, CLR will
always load the signed assembly from GAC not your local copy of assembly.
This behavior is defined by the design of CLR probing logic below:
"How the Runtime Locates Assemblies"
http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx

As you can see the CLR runtime will always check GAC before private
folders. This behavior can not be changed in .Net1.1. However, in .Net2.0,
you can override the probing logic by hosting CLR, please refer to our
Fusion developer Junfeng Zhang's blog below:
"Override CLR Assembly Probing Logic ---
IHostAssemblyManager/IHostAssemblyStore"
http://blogs.msdn.com/junfeng/archive/2006/03/27/561775.aspx

#2, I have used VS2005 to create a test Winform "GACDebuggingTest" project
and adding a class library project into the solution with name "PlugInLib"
and code below:

namespace PlugInLib
{
public class Class1
{
public static int AddInt(int a, int b)
{
return a + b;
}
}
}

The Winform project contains the code below to use the "PlugInLib":
private void button1_Click(object sender, EventArgs e)
{
MessageBox.Show(PlugInLib.Class1.AddInt(3, 5).ToString());
}

I configured these 2 projects as "release".
After signing the "PlugInLib", I drop it into the GAC. Then I use VS2005
debugger to F5 launch the application. By using "Modules" window in the
debugger, I got the GAC version PlugInLib.dll loaded as expected. Path is
listed below:
C:\WINDOWS\assembly\GAC_MSIL\PlugInLib\1.0.0.0__e9b0090aab61820b\PlugInLib.d
ll

Also, in the window, I find the symbol is loaded for PlugInLib.dll, even if
it is loaded from GAC. Then I set a breakpoint in the class library
project, and the debugger breaks when I clicked the button to call the
"AddInt" method in PlugInLib.dll. So it seems that I can debug the class
library in GAC without any problem. So if you did not move the pdb files
around, debugger should find it without any problem.

A few questions: do you use "release" or "debug" configuration in your
plug-in project? Is your assembly symbol loaded in the debugger? You may
verify it in "Module" window. In VS2005, there is a new feature named "Just
My Code" which is enabled by default. This means that VS2005 will not load
symbol for non-user code assemblies, such as all .Net BCL assemblies. Below
is the rule for "your code":
1. If the code is compiled optimized, it is not your code
2. If you don't have symbols, it is not your code
You may also verify if your assembly is optimized and identified as
"User-Code" in "Module Window" in VS2005. Below link contains more
information regarding JMC feature:
"Is 'Just my Code' for you?"
http://blogs.msdn.com/greggm/archive/2004/07/29/201315.aspx

Once you find your plug-in assembly is identified as non-User Code, you
should disable the JMC feature from Tools | Options | Debugging "Enable
Just My
Code" check box.(the VS2005 IDE maybe need close&re-open to enable the
setting). This tells VS2005 load symbol for non-user code.

Finally, if your plug-in source code is not in VS project, you may use the
trick below to debug at source code level:
"How To: Debug Into File References "
http://weblogs.asp.net/okloeten/archive/2003/11/03/35418.aspx

#3, Yes, after building, the linker/compiler will generate a pdb file for
the assembly by default, and the linker/compiler will embed the absolute
path to this symbol file in the assembly so that debugger can parse this
symbol path and find the pdb file for loading.

#4, We have several ways of debugging .Net application. Regarding advanced
..Net debugging, I assume you are interested in using SOS.dll to debug the
..Net internal data structure and flow. Below are some good articles
regarding SOS.dll debugging:
"SOS: It's Not Just an ABBA Song Anymore"
http://msdn.microsoft.com/msdnmag/issues/03/06/Bugslayer/default.aspx
"Drill Into .NET Framework Internals to See How the CLR Creates Runtime
Objects"
http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/
"Investigating Memory Issues"
http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/

In VS debugger side, I recommend Mike Stall's blog, he is Microsoft VS
debugger developer:
http://blogs.msdn.com/jmstall/default.aspx

Finally, the best book on .Net debugging side is John Robbins' wonderful
book <Debugging Applications for Microsoft .NET and Microsoft Windows>.
John has just released the new version for .Net2.0 although I haven't read
it yet, see links below:
http://www.amazon.com/Debugging-Applications-Microsoft-NET-Windows/dp/073561
5365
http://www.microsoft.com/mspress/books/8650.aspx

Hope this helps and feel free to feedback, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[phnimx]

Hi Jeffrey,
First I'd like to thank you for your fantastic reponse, for all the web
links, for your tips, your recommendations and for your valuable insights on
the GAC.
Yours is the most complete response I have received or heard of on the MSDN
Newsgroups EVER! So, Thank you, Thank you, Thank you!

Now, here are the replies to your questions:
1) .NET Framework Version = 1.1
2q)... type of application that consumes your plug-in assembly, console,
winform, or Asp.net?
2a)The applications are C++/MFC SDI applications containing portions of
Managed C++.NET, includingWinforms, app.config that loads the plug-ins based
on
the IConfigurationSectionHandler implementation. This gives us the ability
to have app.config files like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="MyConfiguration"
type="Myyyyyyy.MyPlugin.MyConfigurationHandler, Myyyyyyy.MyPlugin.base,
Version=1.1.0.0, Culture=neutral, PublicKeyToken=abcdef123456789"/>
</configSections>
<Components>
<Component assemblyName="my.plugin1.pluggable, Version=1.4.0.0,
Culture=neutral, PublicKeyToken=abcdef123456789" />
</Components>
</MyConfiguration>
</configuration>


3q) ...what type of debugging you want to perform over the plug-in assembly?
3a) C# Source code level debugging. I have the FULL SOURCE base for ALL
applications and plug-ins.
I'd also like to learn how to do IL level debugging. I must admit I don't
understand binary code level debugging as it applies to .NET. My impression
is that IL Level is the lowest. Please let me know if I am mistaken.

I have read up on the .NET Runtime sequence of assembly access and I
understand that the GAC takes prescedence. I can also see in VS.NET2003 that
the assemblies are actually loaded from the GAC. However, I was wondering
whether there's a method for pointing the VS.NET IDE to the symbol files
(pdb) in order to debug the assemblies that are in the GAC? That is, the PDB
files match the assemblies precisely.

If the answer is the <codebase> element as M. Nemtsev suggests, can you give
me a sample of how this is done?


4q)... do you use "release" or "debug" configuration in your plug-in
project?
4a) RELEASE configuration.


5q)Is your assembly symbol loaded in the debugger?
5a)These particular plug-ins and applications have not been migrated to
VS2005. Can the techniques you describe be applied in VS2003 because I don't
see a JMC option in Tools | Options | Debugging of VS2003? If not can I use
the VS2005 IDE to debug VS2003 compiled assemblies with symbols? Must I
absolutely migrate all to VS2005?


Thank you for your debugging sample, it too is very informative.

Question: Can I use the same debugging technique in your sample by doing an
"Attach to Process" to any one of our CLI/EXEs or assembly applications?

I'm attempting to debug the assemblies directly after an application
installation deployed by an MSI where the plug-ins are MSM merge modules
merged into the various MSI applications. I possess all of the source base
and all symbol files. Is there a way to use the solution debugging technique
in Visual Studio for C++ binaries where "sympath" points to symbol files or
does the .NET runtime ALWAYS find the symbol files?
i.e.:
.sympath
SRV*f:\localsymbols*http://msdl.microsoft.com/download/symbols.


Thanks so much for all your help Jeffrey.
Much appreciated.
PhNimx
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hi Phnimx,

Based on my understanding you want to debug your class library assembly
that resides in the GAC.

Can you tell me what type of application that consumes your plug-in
assembly, console, winform, or Asp.net? I assume it is not Asp.net first.
Then, what type of debugging you want to perform over the plug-in
assembly,
source code level, IL level or binrary code level? Do you have the source
code of the class library assembly in project form? Finally, what version
of .Net you using, .Net1.1 or 2.0? This information will help me
understand
your problem context more accurate. Thanks.

Below is my further comment:

#1, yes, after you have deployed the signed assembly to the GAC, CLR will
always load the signed assembly from GAC not your local copy of assembly.
This behavior is defined by the design of CLR probing logic below:
"How the Runtime Locates Assemblies"
http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx

As you can see the CLR runtime will always check GAC before private
folders. This behavior can not be changed in .Net1.1. However, in .Net2.0,
you can override the probing logic by hosting CLR, please refer to our
Fusion developer Junfeng Zhang's blog below:
"Override CLR Assembly Probing Logic ---
IHostAssemblyManager/IHostAssemblyStore"
http://blogs.msdn.com/junfeng/archive/2006/03/27/561775.aspx

#2, I have used VS2005 to create a test Winform "GACDebuggingTest" project
and adding a class library project into the solution with name "PlugInLib"
and code below:

namespace PlugInLib
{
public class Class1
{
public static int AddInt(int a, int b)
{
return a + b;
}
}
}

The Winform project contains the code below to use the "PlugInLib":
private void button1_Click(object sender, EventArgs e)
{
MessageBox.Show(PlugInLib.Class1.AddInt(3, 5).ToString());
}

I configured these 2 projects as "release".
After signing the "PlugInLib", I drop it into the GAC. Then I use VS2005
debugger to F5 launch the application. By using "Modules" window in the
debugger, I got the GAC version PlugInLib.dll loaded as expected. Path is
listed below:
C:\WINDOWS\assembly\GAC_MSIL\PlugInLib\1.0.0.0__e9b0090aab61820b\PlugInLib.d
ll

Also, in the window, I find the symbol is loaded for PlugInLib.dll, even
if
it is loaded from GAC. Then I set a breakpoint in the class library
project, and the debugger breaks when I clicked the button to call the
"AddInt" method in PlugInLib.dll. So it seems that I can debug the class
library in GAC without any problem. So if you did not move the pdb files
around, debugger should find it without any problem.

A few questions: do you use "release" or "debug" configuration in your
plug-in project? Is your assembly symbol loaded in the debugger? You may
verify it in "Module" window. In VS2005, there is a new feature named
"Just
My Code" which is enabled by default. This means that VS2005 will not load
symbol for non-user code assemblies, such as all .Net BCL assemblies.
Below
is the rule for "your code":
1. If the code is compiled optimized, it is not your code
2. If you don't have symbols, it is not your code
You may also verify if your assembly is optimized and identified as
"User-Code" in "Module Window" in VS2005. Below link contains more
information regarding JMC feature:
"Is 'Just my Code' for you?"
http://blogs.msdn.com/greggm/archive/2004/07/29/201315.aspx

Once you find your plug-in assembly is identified as non-User Code, you
should disable the JMC feature from Tools | Options | Debugging "Enable
Just My
Code" check box.(the VS2005 IDE maybe need close&re-open to enable the
setting). This tells VS2005 load symbol for non-user code.

Finally, if your plug-in source code is not in VS project, you may use the
trick below to debug at source code level:
"How To: Debug Into File References "
http://weblogs.asp.net/okloeten/archive/2003/11/03/35418.aspx

#3, Yes, after building, the linker/compiler will generate a pdb file for
the assembly by default, and the linker/compiler will embed the absolute
path to this symbol file in the assembly so that debugger can parse this
symbol path and find the pdb file for loading.

#4, We have several ways of debugging .Net application. Regarding advanced
Net debugging, I assume you are interested in using SOS.dll to debug the
Net internal data structure and flow. Below are some good articles
regarding SOS.dll debugging:
"SOS: It's Not Just an ABBA Song Anymore"
http://msdn.microsoft.com/msdnmag/issues/03/06/Bugslayer/default.aspx
"Drill Into .NET Framework Internals to See How the CLR Creates Runtime
Objects"
http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/
"Investigating Memory Issues"
http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/

In VS debugger side, I recommend Mike Stall's blog, he is Microsoft VS
debugger developer:
http://blogs.msdn.com/jmstall/default.aspx

Finally, the best book on .Net debugging side is John Robbins' wonderful
book <Debugging Applications for Microsoft .NET and Microsoft Windows>.
John has just released the new version for .Net2.0 although I haven't read
it yet, see links below:
http://www.amazon.com/Debugging-Applications-Microsoft-NET-Windows/dp/073561
5365
http://www.microsoft.com/mspress/books/8650.aspx

Hope this helps and feel free to feedback, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Jeffrey Tan[MSFT]]

Hi PhNimx,

Thanks for your feedback and further information.

#1, Oh, it seems that your project is mixed with unmanaged MFC, managed C++
and managed C# code. I am not experienced in this interop area, anyway, I
will try my best to help you.

#2, Yes, normally IL level is the lowest in .Net. <codebase> will not help
in this case, because the CLR will always probe the GAC before touching the
app.config file.
Yes, VS.net2003 also supports the symbol server feature in an undocumented
way. You may right click "My Computer"->Choose "Properties"->Advanced
tabpage->Environment Variables->Click "New" button->input the environment
with name "_NT_SYMBOL_PATH" and value
"SRV*f:\localsymbols*http://msdl.microsoft.com/download/symbols".

This is the same environment as windbg uses. You need to restart your
VS.net2003 IDE to force the VS.net2003 debugger to recognize the setting.
Also, there is no Just My Code setting in VS.net2003, once you have setup
the symbol server, VS.net2003 will probe the symbol path after you pressed
F5.
Note: the symbol loading may cause some delay during debugging, this is
because VS.net2003 uses early symbol loading(while windbg uses delay symbol
loading). You may open "Output" window in VS.net2003 to verify symbol
loading process, you should see "Symbols loaded" text for each module, like
below:

'DefaultDomain': Loaded
'c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll', Symbols loaded.
'DataGridTest': Loaded
'G:\Program\winform\2006\11-28\DataGridTest\bin\Debug\DataGridTest.exe',
Symbols loaded.
'DataGridTest.exe': Loaded
'c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\s
ystem.windows.forms.dll', Symbols loaded.
'DataGridTest.exe': Loaded
'c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll',
Symbols loaded.
'DataGridTest.exe': Loaded
'c:\windows\assembly\gac\system.data\1.0.5000.0__b77a5c561934e089\system.dat
a.dll', Symbols loaded.
'DataGridTest.exe': Loaded
'c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\system.
drawing.dll', Symbols loaded.
'DataGridTest.exe': Loaded
'c:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml.
dll', Symbols loaded.

Using "Module" window is another way to verify the symbol loading status.
So the answer is: you may use VS.net2003 for managed debugging and system
assemblies symbol loading with _NT_SYMBOL_PATH environment variable.
However, VS2005 has better support.

#3, For the class library assembly resides in GAC, you may take the PDB
file that was created in your bin\release directory and place it in the
same directory as the compiled Assembly in GAC(usually
%WINDIR%\assembly\GAC\%Assembly Name%\%Version%). Then the debugger will
load the pdb file for this GAC assembly.

#4, yes, you may first launching any application without debugger and then
use VS.net2003 to attach to this application process for debugging. It
should be Ok. The key point is the debug type: managed only or mixed mode
debugging(interop debugging). I have never debugged interop debugging yet.

#5, I seldom do interop/mixed mode debugging, so I can say very few on this
topic. I know the Microsoft VS debugger developer Mike Stall writes an
interop debugging blogs in the link below:
http://blogs.msdn.com/jmstall/archive/tags/Interop+_2800_mixed-mode_2900_/de
fault.aspx

Yes, as you can see, there are some limitations during interop debugging.

If I have missed anything or you have anything unclear, please feel free to
tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

How about this issue now? Does my further reply make sense to you? If you
still have anything unclear or need any help, please feel free to tell me,
thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.