How to reference a dll without VStudio making a copy of it -- the original location is referenced

The scenario is like this: let's say you have a bunch of utility methods and classes all contained in one dynamic library (dll).  You use / reference that dll in many projects, but you also are frequently making changes to this dll (improvements, etc).  But with every change, you have to find each project using this dll and update them with the new one.  Not fun, not practical.  I would like to do this: when you go to "References" and "Add Reference", when you browse and add the dll, that VStudio just makes reference to the original folder location, not making a local copy into your xy or z project that's using it.  I'm wanting to avoid installing to the GAC, (for the reason just stated: "but you also are frequently making changes to this dll (improvements, etc)"; this is too fluctuating to add there just yet) ... but ... maybe that is the only way to do this?  By the way  --  I'm only talking about being in Debug mode, which also means, of course, staying on the same computer / harddrive, so the referenced dll location of course must remain valid (with the dll there where specified) -- in actual deployment, of course the dlls would have to ship along in the deployed project.  

Thanks
LVL 3
Sperling1Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

grayeCommented:
That's not really a practical idea...   besides, that problem is precisely why the GAC was created.
For example, the .Net Framework was designed to operate in 1 of 2 ways... either using "shared assemblies" - DLLs in the Global Assembly Cache (GAC) or by "private assemblies"-DLLs in the applications own directory (the side-by-side approach).  The side-by-side technique *requires* the the DLLs be in the same directory (or a directly below) the application's running directory.   The only way to override this is to write code to manually load DLLs (which seems a bit overkill to me)
Since a method already exists to share DLLs, I'd recommend that you use it.
Is there is specific reason for "going rogue"?
0
ToddBeaulieuCommented:
Have you tried unchecking the "copy local" option for references to this dll?

I don't see why you couldn't GAC it, really. Just throw a post-build event on the dll project and you'll never have to think about it again.
0
Sperling1Author Commented:
Graye, those are good points.  Those points may be right - but I had to ask.  No, I definitely am not looking for some 'overkill' route -- in that case I would go with GAC.  But this answers Todd's question too: one reason is that I've never entered anything in the Gac yet, other is I'm expecting this to change a lot on me.  

Todd: Where would I "uncheck" "copy local"??  Please tell me all the steps where I can see that.  Is it in Tools / Options?

0
C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

ToddBeaulieuCommented:
If you select an existing reference and go to its properties, there is a true/false (sorry, not a check) for "Copy Local". I've rarely used it, but I think it might do the trick for you. If you start to run into issues, you should really consider the GAC. It's painless, we promise!
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Sperling1Author Commented:
Wunderbar!  
Well done Todd, that exactly does the job.  I thought there was a simple, top level way of doing this.  I still should get used to the GAC, but I bet there are many times where this will be preferrable while in development.  Just a side note: C#3.0 in a Nutshell / Albaharis p 544-5 list some reasons why GAC is not ALWAYS preferrable.

Thanks again Todd!
0
grayeCommented:
BTW:  You're gonna have trouble when you switch to deploying the DLLs on a production machine.
0
Sperling1Author Commented:
graye:
Good point to keep in mind, thanks.
0
ToddBeaulieuCommented:
What touble are you referring to? As long as the library isn't being revisioned out of binding (major.minor), what is the issue?

btw - I wouldn't use this technique in any kind of team environment. You'd find missing DLLs all over the place. Team Build wouldn't pull down the DLL, either and would fail.

I'd probably put the dll in a common BIN folder, have the post-build stick a copy there (if you want auto-deployment to your other applications) and then build my references (with Copy Local) to THAT folder. That solves a ton of issues.
0
grayeCommented:
The .Net framework follows a strict set of rules on how an assembly find its referenced DLLs at runtime.   The rule are:
  1. Use exsiting bound assembly if any
  2. Use the GAC
  3. Probe for the file starting at the applications "root" directory
Obviously these rules don't apply to COM-based references
http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx
http://msdn.microsoft.com/en-us/library/15hyw9x3.aspx
This is why Visual Studio defaults to "Copy Local"... because the probing rules do not allow you to specific a directory outside the application's root.
0
ToddBeaulieuCommented:
Hmmm. I'm still not sure what the proposed problem is at deployment.

BTW - you can specifiy a specific location for an assembly using CodeBase.
0
grayeCommented:
Hummm... I thought <codeBase> was just for web applications... I'll have to check that out.
The <codeBase> feature will only allow you to specify a path outside the applications root, *if* you're using an assembly that is strongly-named...   Which follows the same rules as putting the assembly in the GAC.   And, if you're gonna do that, then why not just use the GAC and be done with it.
This *is* however, an alternate solution...   you could put all of the applications (and their reference private assemblies) into the same directory.   I could see how this would work fairly well over a network share
0
ToddBeaulieuCommented:
You know, I sign everything (Team Build), but I don't use the GAC. For a Team Project that makes use of common libraries, I put the compiled binaries into an EXT folder of that project. This allows me to push new versions of the common libraries only to those projects that are ready for it, acommodating breaking changes, as well as eliminating the need for regression testing of applications we don't want to touch.

As for CodeBase, I used that with interop assembly wrappers in the past. It's nothing more than a first-chance binding hint for Fusion.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.