pdb files for assemblies in GAC?

  • Thread starter Thread starter Mark
  • Start date Start date
M

Mark

Hi...

I didn't see any pdb files actually in the gac directory hierarchy. Is
there anything wrong with putting the pdb files in the gac directory?

Thanks
Mark
 
Hi Mark,

I do not think I understand you completely. Can you describe your scenario
and question in more details? Are you performing debugging with VS debugger
or windbg?

I wonder why not use the symbol store to cache the pdb symbol files for
debugging. For example, you may input the following symbol path in the VS
debugger or windbg.
"srv*C:\LocalSymbols*http://msdl.microsoft.com/download/symbols"

Then, you may place any of your private pdb files in C:\LocalSymbols.
During debugging, the debugger will look up this directory and load the pdb
files automatically for you. 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.
 
Hi Jeffrey...

The question stems from a pile of legacy considerations. I inherited a
build system that produces msi installers with Wix projects. The author of
the Wix projects constructed them to inject our assemblies directly into the
GAC (no shadowcopy or original location to remember), then it drops the .pdbs
with the other files in our install directory.

The installer doesn't know about or expect the destination machine to have
_NT_SYMBOL_PATH defined nor does it expect any other symbol file convention
to be set up.

As an experiment, after the assemblies got put in the gac, I tried copying
the .pdb file to the same file folder in the gac. When I attached the
debugger, I saw that it loaded the symbols from the gac location.

So it got me wondering about a) why the gac doesn't also handle pdbs and b)
what problems there might be from dropping the files there.

I suppose the more canonical approach would be to define _NT_SYMBOL_PATH and
put the symbol files there.

Thanks
Mark


"Jeffrey Tan[MSFT]" said:
Hi Mark,

I do not think I understand you completely. Can you describe your scenario
and question in more details? Are you performing debugging with VS debugger
or windbg?

I wonder why not use the symbol store to cache the pdb symbol files for
debugging. For example, you may input the following symbol path in the VS
debugger or windbg.
"srv*C:\LocalSymbols*http://msdl.microsoft.com/download/symbols"

Then, you may place any of your private pdb files in C:\LocalSymbols.
During debugging, the debugger will look up this directory and load the pdb
files automatically for you. 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.
Click to expand...
 
Hi Mark,

Thanks for the detailed feedback.

I think the behavior is by design. The debugger needs a way to find the pdb
files during debugging. If all the pdb files are placed in the installation
directory while the actual assemblies are loaded from the GAC, how can the
debugger know where to find the pdb symbol files? The debugger will only
assume the pdb files are in the same folder as the assembly.

Using _NT_SYMBOL_PATH is a way to tell the debugger where to look for the
pdb symbol files, another way is placing the pdb at the same folder as the
assembly in GAC. Actually, in VS2005, you may just place all the assemblies
in a directory cache and then set this cache folder path in the
Tools->Options->Debugging->Symbols dialog. This will tell the VS debugger
where to find the pdb files for all the modules/assemblies in the debuggee
process.

Hope it helps.

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.
 
Back
Top