Visual Studio References and versioning - how does it work?

Answer 1

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.

Answer 2

If you have the source, you could use project references instead of dll references. That way you would always get the latest.

Answer 3

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