Understanding DLL Versioning in .NET 1.1 versus .NET 3.5?

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.

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.

Is this property supported in . NET 1.1? If not that would probably explain the difference in what seems to be going on.

– Achilles Jul 28 '10 at 15:46 Does that help? – Mitchel Sellers Jul 28 '10 at 15:50 It does. Thanks for the help.

– Achilles Jul 28 '10 at 15:55 So how does the newer version dll work in a deployed application where one of it's dependencies is an older version than the one it was compiled against? – Achilles Jul 28 '10 at 16:06 If it was compiled against version 1.0, and you put version 0.9 in the directory it will fail.As in my last example above. – Mitchel Sellers Jul 28 '10 at 17:38.

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 don't 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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.