views:

99

answers:

3

I'm using VS2005 (haven't moved to 2008 because I'm still using some legacy tools) and have a question about the way project references work.

If I make a project reference to a project that has been deployed to the GAC, VS will use the assembly in the GAC. This is annoying when I have older code in the GACed assembly and I am making code changes and doing quick tests against them - I have to either GAC the new code every time, or remove the assembly from the GAC so VS can't get it from there.

Is there a way to defeat this behavior?

A: 

Copy the reference locally.

Jason Watts
This doesn't appear to work. I cleaned out the bin directory, set Copy Local to true, rebuilt and confirmed that the referenced assembly is in the bin/Debug directory along with the project assembly. The referenced assembly is still loaded from the GAC.
+1  A: 

Can't you just change the reference, pointing to the DLL directly? Better yet, if you changing your DLL, use the Project as reference instead of the GAC DLL?

wtaniguchi
The project is referenced directly. Pointing to the DLL directly would defeat the point of doing so.
A: 

The best way around this is a two step proces.

1.) In your GAC'ed DLL upgrade the minor version number. (1.0 to 1.1) 2.) Update the project reference to copy local, and use the new version number.

This "SHOULD" get it working, but with the GAC it isn't always 100%.

You could go the route of a policy file, to stop the GAC from loading....but that gets way more complex.

Mitchel Sellers
Thanks, I figured it had to do with versioning. It looks like as long as Copy Local is true, VS will always use the newest version it can find. It looks like if it finds the same version number in the GAC and locally, it just uses the one in the GAC.
Nick - I'll toss one more wrench in the works...if you have a policy file in place, that cal all go out the window as well.....
Mitchel Sellers