Tracing into a project if it's installed in the GAC

[Carl Scarlett]

I have a VB.NET assembly (Needle) that has functions used in multiple
applications. When I am developing these applications, I have the Needle
project in my application's solution, and I reference the project file.

I started having problems once we wrote an installer that puts Needle into
the GAC. In order to create the deployable application, I had to put Needle
into the GAC on my development machine, remove it from the solution, and
reference the GAC location for Needle dll.

Now I want to be able to trace from my application into the Needle project,
and I can't figure out how to do this.

Currently, I've added the Needle project back into the solution and changed
the references back to it. This breaks our build process, which I'm not
happy about. However, in order to be able to trace into Needle, I also have
to remove it from the GAC on my development machine.

I've searched the web, newsgroups, and MSDN, and while I have found heaps of
information about putting assemblies in the GAC, adding it to the references
dialog, etc, I can't find any information on how to manage the development
process after this is done.

I suspect that I shouldn't put anything in the GAC on my development
machine, but this means that the (automated) install builder has to work
using different solution and project files to the ones I'm developing with
so that the references are correct. This is dangerous, because I'm
effectively developing different source to what ends up with the clients.

Please help!
Carl.

 

[Klaus H. Probst]

Use DEVPATH

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/ht
ml/cpconenablingruntimetosearchforassembliesinotherlocations.asp>

 

[Carl Scarlett]

I don't have a machine.config file. I think that's only for web
development, when I only develop client applications.

If not, how do I create a machine.config file? I've searched my entire hard
drive and can't find one!

 

[Klaus H. Probst]

Sure you do. It's under
%WINDIR%\Microsoft.NET\Framework\<YourVersion>\Config\

 

[Carl Scarlett]

Thanks.

(Bloody windows search. *grumble*)

Sure you do. It's under
%WINDIR%\Microsoft.NET\Framework\<YourVersion>\Config\


--
Klaus H. Probst, MVP
http://www.simulplex.net/



<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/ht

 

[Carl Scarlett]

Just to finalise this thread, I've found a solution that doesn't rely on
changing the machine.config file (which I didn't think was a good generic
solution).

Remember, the problem was that I wanted a single solution to develop and
build from, where some dlls were shared (GAC) and some were non-shared, and
I wanted to be able to trace across (step across) project boundaries on the
development PC without upsetting the (automated) build process on the same
solution.

1) Don't put your developed dlls in the GAC on your development machine.
This will make it impossible to trace into (step into) those dlls no matter
how you reference your projects.
2) When making rereferences in your solutions, make sure the dlls are in the
bin folders of the relevant projects and reference those, or alternatively
add the project to your solution and reference it. In that way, if you have
multiple solutions containing the same projects, at least they're all
compiling to the correct spot and you won't break references in other
solutions.
3) When building the install, put the shared assemblies in the GAC and the
non-shared assemblies in the program folder. The CLR will work out that a
reference isn't in the program folder (or any other folder in the path) and
use the one from the GAC.
4) If you want to test an install, or you're developing where you need to
put something in the GAC, realise that you will probably run into problems
tracing eventually and you'll have to un-gac them. I recommend using a
virtual machine if you want to install stuff in the gac, and leave your
prime development machine alone.

It's taken me a week to collect all the info and come to a point where I
feel I fully understand this. Hopefully this will help other developers out
there.

Carl.