We have several common libs. Ideally we want them all to use the latest version of a dll even if they have been compiled against an older different version (assume the latest version is backward compatible)
e.g we have:
Project dll
Common controls dll
Logging dll
Database access dll
Project and common controls reference v2 of database dll. Logging however references v1.
If different versions are referenced in different components how does VS pick which one to use?
Do we have to recompile v1 dll to use the latest database (v2) or can we get this to pick up automatically?
Is it possible to force a particular version to be used?
Thanks,
Alex
By default, for versioned DLLs I believe VS will force an exact match. If you look in the properties of the reference, however, you'll find a property called "Specific Version". Set that to "false" and it will match later versions.
I don't have the full version of VS with me to find an appropriate MSDN link, unfortunately.
In addition, you can use the assemblyBinding element in app.config.
There are actually two scenarios here - using strong names/GAC, or not using strong names.
If you're using strong names, and installing the components into the GAC, then .Net will want to use the version of the component that the client was referencing when it was compiled. So in your example it would be quite possible for Project to reference database V2, while Logging referenced database V1, because the DLLs can be stored in parallel in the GAC. So if you actually want Logging to use V2 instead of V1, you will need to modify configuration files to say that "a reference to V1 should be pointed on to V2". There are different places to do this - app file, machine file etc.
If you're not using strong names, then .Net will by default use the version of the DLL that's in the same folder as the client. So suppose you deploy Project, CommonControls and Logging in the same folder as database V2. Then even if Logging was built against database V1, it will attempt to use the component in the same folder, ie database V2. As long as V2 can supply the same public classes and methods that Logging wants to use, it will work fine.
In my environment - where all our applications are internal - we don't use the GAC. We just deploy all the files that the application needs into a single folder. When you have a lot of common components, it would just be a nightmare to keep the configuration files in synch.
This is all very different to COM, where all applications picked up the currently registered copy of the DLL (assuming V1 and V2 were binary compatible).
I came across this site which has a couple of suggestions:
http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/
To get a specific version apparently you have to edit web.config or app.config?
"Finally, take a look at your csproj file using notepad (or unload the project in Visual Studio to be able to open it as text). When you add references using Visual Studio you will get a assembly reference with both version number and public key and this can give you some trouble when you upgrade a vendor assembly to a newer version."
http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/
If you have the source, you could use project references instead of dll references. That way you would always get the latest.
