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 ve
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.
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).
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.