Sperling1
asked on
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
Thanks
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.
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.
ASKER
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?
Todd: Where would I "uncheck" "copy local"?? Please tell me all the steps where I can see that. Is it in Tools / Options?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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!
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!
BTW: You're gonna have trouble when you switch to deploying the DLLs on a production machine.
ASKER
graye:
Good point to keep in mind, thanks.
Good point to keep in mind, thanks.
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.
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.
The .Net framework follows a strict set of rules on how an assembly find its referenced DLLs at runtime. The rule are:
http://msdn.microsoft.com/ en-us/libr ary/yx7xez cf.aspx
http://msdn.microsoft.com/ en-us/libr ary/15hyw9 x3.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.
- Use exsiting bound assembly if any
- Use the GAC
- Probe for the file starting at the applications "root" directory
http://msdn.microsoft.com/
http://msdn.microsoft.com/
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.
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.
BTW - you can specifiy a specific location for an assembly using CodeBase.
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
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
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.
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.
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"?