Debug + GAC

[Jozsef Bekes]

Hi,

I am trying to debug an application installed on our test machine. The
problem is that for keeping the given directory structure we need to use the
GAC for some dlls, that means that those dll get loaded from the GAC
directory when debugging. My experience is that although the absolute path
of the pdb file is written into the dll, the symbols do not get loaded - I
guess because the debugger cannot find the pdb files. Do you have any
suggestions on how I should handle this problem?

Thank you,
Jozsef

 

[Dmytro Lapshyn [MVP]]

Hi,

I remember I was able to overcome this by blatantly copying the PDB files to
the GAC sub-folder where the assembly itself resides.
You might need to use cmd.exe and the COPY command to do that, as the GAC
has its own Explorer view.

 

[Johann Blake]

Jozef,

For debugging purposes, do not put those dlls that belong in the GAC
into the GAC. You cannot debug DLLs that are stored in the GAC. After
debugging, then install them into the GAC. As long as a DLL is in the
GAC, you will not be able to see your symbols or even step into any
code. I have had enough experience with that issue.

Best Regards
Johann Blake

 

[Johann Blake]

Yeah, I remember doing this as well now that you mention it, only I
didn't use the COPY command because the name of the directory is rather
long and complicated due to the GUID in the directory name. Instead, I
used a freeware program that lets you view the directories on your hard
drive as is, and as a result you can see the GAC as a directory and
not the way Explorer exposes it.

Best Regards
Johann Blake

 

[Nick Malik [Microsoft]]

Just to add to Johann's response:

Don't debug in the GAC. It's as simple as that.

Why are you debugging on a test machine anyway? Test machines are for
testing. Dev machines are for debugging. Get the bug to repro in a non-gac
environment and debug it there.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Richard Blewett [DevelopMentor]]

Thats all very well until you need to debug in the GAC ;-)

For example, if you are trying to debug a .NET component that is being called from a BizTalk Orchestration. In that case you have to put the .pdb file in the same physical directory as the component so you have to put it in the physical GAC directory.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Just to add to Johann's response:

Don't debug in the GAC. It's as simple as that.

Why are you debugging on a test machine anyway? Test machines are for
testing. Dev machines are for debugging. Get the bug to repro in a non-gac
environment and debug it there.

 

[Nick Malik [Microsoft]]

Just to add to Johann's response:

Thats all very well until you need to debug in the GAC ;-)

For example, if you are trying to debug a .NET component that is being
called from a BizTalk Orchestration. In that case you have to put the .pdb
file in the same physical directory as the component so you have to put it
in the physical GAC directory.

or you write a multi-threaded unit test harness that calls your component
directly in the dev environment. I've debugged BTS components. I'm not
crazy enough to debug them in the GAC.

I appreciate that putting the PDB file in the GAC directory works. Fine. In
my humble opinion, it is an unnecessary hack employed by people who didn't
plan their project to include sufficient time to test, didn't test their
apps sufficiently to catch defects on the dev environment, and didn't
instrument their apps well enough to pinpoint the actual behavior that they
need to reproduce.


--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Richard Blewett [DevelopMentor]]

Granted about instrumentation.

You have to be very careful with unit test environments to make sure that they configure *everything* the way that the code will actually be driven in reality - personally I like to do a sanity check - on a dev machine that the way I've configured the test environment actually matches the real world that the code will live in. So I also test under the real conditions and then, sometimes, its useful to be able to attach a debugger to work out whats happening different than you expected

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Thats all very well until you need to debug in the GAC ;-)

For example, if you are trying to debug a .NET component that is being
called from a BizTalk Orchestration. In that case you have to put the .pdb
file in the same physical directory as the component so you have to put it
in the physical GAC directory.

or you write a multi-threaded unit test harness that calls your component
directly in the dev environment. I've debugged BTS components. I'm not
crazy enough to debug them in the GAC.

I appreciate that putting the PDB file in the GAC directory works. Fine. In
my humble opinion, it is an unnecessary hack employed by people who didn't
plan their project to include sufficient time to test, didn't test their
apps sufficiently to catch defects on the dev environment, and didn't
instrument their apps well enough to pinpoint the actual behavior that they
need to reproduce.