Understanding DLL Versioning in .NET 1.1 versus .NET 3.5

Is dll versioning implemented differently in .NET 1.1 versus .NET 3.5? It seems I can mix and match older and new versions of dependent dll's in deployed applications using .NET 1.1 but leads to problems when doing the same mixing a matching开发者_JS百科 with dll's running in deployed .NET 3.5 applications.

A lot of this is dictated based on the "useSpecificVersion" property that can be set on your reference. The general rule of thumb is that you can use a NEWER version of a referenced DLL, just not an older version.

If you have "UseSpecificVersion" set to true, it will force the application to use that version, and ONLY that version of the referenced DLL. This is a feature that has been in .NET all along.

Use Specific Version Example

If you build dll X with a reference to version 01.01.00.00 of Referenced assembly Y. Any use with a version other than 01.01.00.00 of assembly Y will result in a failure.

Standard Example

If you build a dll X with a reference to version 01.01.00.00 of Referenced assembly Y, you can use version 01.01.00.00 or later without issue.

• 01.01.00.00 - Works
• 01.01.01.00 - Works
• 01.05.00.00 - Works
• 01.00.01.00 - Fails, as it is a previous version.

I don’t think it has really changed, but you can read about it in MSDN.

You cannot mix and match older and new versions because the older ones are going to be a problem.

Say you have:

abc.exe 1.0, that has references to XYZ.DLL and ZZZ.DLL both 1.0 as well.

If you recompile ZZZ.DLL and make it 1.1, abc.exe should continue to work and will load the DLL if it’s present in it’s load path.

However, if you copy ZZZ.DLL v0.9, abc.exe will fail to load that dll, because it’s older.

Bear in mind that if XYZ.DLL also has references to ZZZ.DLL, then the same rules apply.

On the other hand, you can always install the DLLS in the GAC and have different versions available. That way, when you load the assembly, if it’s in the GAC, .NET will try to find the “correct one”, but will fall back to whatever it can use, provided it’s a higher version.

Perhaps I have misunderstood Mitchel Seller's response, but it appears to make an incorrect assumption of what 'useSpecificVersion' is all about. I have refreshed my memory on this through some simple tests, but they are targeting .net 3.5 as I cannot target 1.1 in VS2010.

It appears that people believe that by setting 'useSpecificVersion' in the property-grid of Visual Studio, the .net RUNTIME will allow DLLs to be substituted with newer assembly versions... This is incorrect.

Nothing (custom assembly binding excluded) will change the fact that if your 'dependency' is strongly named, _that_exact_version_ must be present to the application at runtime, or your will receive exceptions relating to assembly-not-found/type-load-exception.

"useSpecificVersion" is purely a compile time option. It allows Visual Studio to substitute the given DLL to ensure it can resolve references to get a successful compile. It is actully used heavily for Visual Studio's multi-targeting capabilities.

Just to give you a simple example...

Notice how if you add a project reference to some DLL, you dont get the 'useSpecificVersion' option in your property-grid - that is because you have specified an explicit project. However, if you add a reference from the "Add References" dialog, then what you are saying is, "add a reference that is supplied from some installed product". Then you do have the option of setting "useSpecificVersion" to false.

Lets pretend that you have installed NLog 1.0 via an MSI, and that has put NLog.dll into your Add References dialog (this is done with a registry entry). If you set 'useSpecificVersion' to False, then you uninstall NLog.msi (version 1.0) which removes the DLL from your hard drive, Visual Studio will complain for a moment, by putting an exclamation mark on the reference (you have to CLEAN your project though, or VS will just grab the DLL from your build folder). But, because the reference has been saved to the project file with "useSpecificVersion false", if you then install NLog.msi (version 2.0)... and rebuild (you might need to restart VS), Visual Studio will locate the version 2 NLog dll, and be quite happy with using it - the little yellow exclamation mark will disappear. This works in both directions, from higher version numbers, to lower, and lower to higher. Leaving "useSpecificVersion" as "True" would prevent Visual Studio from performing this substitution.

As you can see, this behavior has nothing to do with what actually happens at runtime... .NET will still expect the EXACT version (unless you have configured some assembly version redirection in the app.config) that it was compiled against.

Keeping "useSpecificVersion" as "True" will ensure that a developer is required to have the correct version of dependency libraries installed on their system to get a successful build.

We use DevExpress libraries, of which newer versions are frequently released, and we would never want "useSpecificVersion False" on their references, because we need to make sure that every developer has the correct version of DevExpress installed when they are working on the product. Without that, they could inadvertently start using DevExpress features that have either been deprecated (by having an older version installed), or not yet introduced (by having a newer version) in the version that we actually intend to deploy.