GAC DLL Update

Question

I have a DLL API referenced by several third-party applications.

Some of these applications want to have two ways in terms of updates. 1) I want the latest things 2) Do not update my direct binaries, which are often

It was suggested that you migrate the DLL to the GAC and write another DLL, which is just a wrapper for the DLL in the GAC (which third-party applications will then reference). This allows business logic (the part that will change frequently) to be updated in the GAC, and the DLL wrapper should only be updated when new features are available.

GAC is designed to store versions of a DLL with a version. Thus, the DLL wrapper will refer to a specific version of the DLL API. How difficult is it to update the GAC DLL so that links to it are not broken, but the binary content is different?

Is it as simple as not changing the version of the GAC DLL when updating?

Thanks.

Answer 1

You can create an updated assembly, sign it, and forward it to the GAC so that applications referencing this assembly do not notice the difference. You need to specify all parts of the version number (that is, the version number as 1.2.3.4, and not 1.2.3. * In the AasemblyInfo.cs file) and use the same sn key. Then the link to the version will not be broken. And you can update your DLL as needed.

Answer 2

How difficult is it to update the GAC DLL so that links to it are not broken, but the binary content is different?

You cannot do this directly. You can only put signed DLLs in the GAC. When you create an application against a signed DLL, the compiler takes a hash of the contents of the DLL and places it in the application. When the .NET runtime loads the application, it checks this hash against a valid copy of the DLL. If this DLL does not match the one you built with, .NET throws an exception.

A way around this:

• Implement a versioning scheme for your GAC DLL. It can be as simple as always increasing the version number when creating.
• In your app.config add the <bindingRedirect> element

Basically, the binding redirection says: "If you are looking for DLLs with version numbers ranging from 1.x to 1.y, look at version 1.z instead."

Edit: There are ways to verify the integrity of a .NET.NET name , but I recommend developing an application around the standard strong name mechanism before trying to get around it.

Answer 3

I use the Windows installer to deploy my assemblies in the GAC. From a service point of view, it is important to understand the difference between:

[AssemblyVersion]

and

[AssemblyFileVersion]

The former is considered part of a strong name / binding contract, while the latter is not. In addition, the latter is considered by the Windows installer in terms of deciding whether to overwrite the file or not during the upgrade.

Botton line: If your changes to the assembly do not violate the interfaces or cause any regression of behavior, you can keep AssemblyVersion the same and increase AssemblyFileVersion and redeploy.

This is how the .NET Framework Service Packs work, because Microsoft should be able to maintain base class libraries without breaking applications that have existing SN references.

Answer 4

Links may include version information or a link to any version. This is determined by the author of the application that references your DLL. Of course, you can send the updated DLL as having the same version as in the GAC, but all version information is to allow all parties to properly handle updates. Therefore, you may need to clarify your task.