.net – Updating a DLL in the GAC

apidllgacnet

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.

Best Answer

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.

This is the style that Microsoft tends to use in their examples.

It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.

C# – Should ‘using’ directives be inside or outside the namespace

There is actually a (subtle) difference between the two. Imagine you have the following code in File1.cs:

// File1.cs
using System;
namespace Outer.Inner
{
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Now imagine that someone adds another file (File2.cs) to the project that looks like this:

// File2.cs
namespace Outer
{
    class Math
    {
    }
}

The compiler searches Outer before looking at those using directives outside the namespace, so it finds Outer.Math instead of System.Math. Unfortunately (or perhaps fortunately?), Outer.Math has no PI member, so File1 is now broken.

This changes if you put the using inside your namespace declaration, as follows:

// File1b.cs
namespace Outer.Inner
{
    using System;
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Now the compiler searches System before searching Outer, finds System.Math, and all is well.

Some would argue that Math might be a bad name for a user-defined class, since there's already one in System; the point here is just that there is a difference, and it affects the maintainability of your code.

It's also interesting to note what happens if Foo is in namespace Outer, rather than Outer.Inner. In that case, adding Outer.Math in File2 breaks File1 regardless of where the using goes. This implies that the compiler searches the innermost enclosing namespace before it looks at any using directive.

Best Answer

Related Solutions

C# – the difference between String and string in C#

This is the style that Microsoft tends to use in their examples.

C# – Should ‘using’ directives be inside or outside the namespace

Related Topic