Updating a DLL in the GAC

Question

I have an API DLL that several third party applications reference.

Some of these applications want things two ways in terms of updates. 1) I want the latest stuff 2) D

Answer 1

References can include version information or reference whatever version is available. This is determined by the author of the application that references your DLL. Of course, you can ship your updated DLL as having the same version as in the GAC, but the whole point of versioning stuff is to let all parties handle updates correctly. So you might need to refine your task.

Answer 2

I use Windows Installer to deploy my assemblies to the GAC. From a servicing perspective it's important to understand the difference between:

[AssemblyVersion]

and

[AssemblyFileVersion]

The former is considered as part of the strong name contract / binding while the latter is not. Additionally the latter is considered by Windows Installer in terms of deciding to overwrite the file or not during an upgrade.

Botton line: If your changes to the assembly doesn't break interfaces or cause any behavior regressions, you can keep the AssemblyVersion the same and increment AssemblyFileVersion and redeploy.

This is how .NET Framework Service Packs work as Microsoft has to be able to service the base class libraries without breaking applications that have existing SN references.

Answer 3

You can create an updated assembly, sign it and push it to the GAC so that the applications, which reference this assembly, won't notice the difference. You need to specify all parts of the version number (i.e. have the version number as 1.2.3.4 and not 1.2.3.* in AasemblyInfo.cs file) and use the same sn key. Then the version-specific reference won't be broken. And you'll be able to update your DLL as you need.

Answer 4

How difficult is it to update the GAC DLL so that the references to it don't break but the binary contents differs?

You can't do it directly. You can only put signed DLLs into the GAC. When you build your app against a signed DLL, the compiler takes a hash of the contents of the DLL and puts it in the app. When the .NET runtime loads the app, it checks this hash against the real copy of the DLL. If this DLL doesn't match the one you built with, .NET throws an exception.

The way to work around this is to:

1. Put in place a version numbering scheme for your GAC DLL. This can be as straightforward as always incrementing the version number when you do a build.
2. In your app.config, add a <bindingRedirect> element

In effect a binding redirect says, "if you're looking for a DLL with version numbers in the range 1.x to 1.y, look at version 1.z instead".

Edit: There are ways round the .NET strong name integrity check, but I recommend designing your application around the standard strong name mechanism before trying to circumvent it.