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) Don't update my direct binaries that often
There has been the thought of moving the DLL into the GAC and writing another DLL that is simply the wrapper for the DLL in the GAC (which the 3rd party apps would then reference). This allows the business logic (the part that would change frequently) to be updated in the GAC and the wrapper DLL would only need to be updated when new functions were made available.
The GAC is intended to keep versioned DLLs. So the wrapper DLL would have a reference to a specific version of the API DLL. How difficult is it to update the GAC DLL so that the references to it don't break but the binary contents differs?
Is this as simple as not changing GAC DLL versions when updating?
Thanks.
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.
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:
- 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.
- 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.
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.
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.
