Maintaining backward compatibility with assemblies installed into the GAC

[Kevin Buchan]

I have lived with the pain of maintaining Binary Compatibility with
COM for a long time. I *thought* I had read that this was largely a
thing of the past with .Net... as long as you didn't do anything
crazy.

Here's my situation:
I am writing an assembly with a single utility class that is used by
several of my applications. I would like to install this class into
the GAC rather than deploy to each application's directory.

I have everything installing into the GAC and life is good.

However, I discovered how convenient it would be if one of the methods
had an overload that took some additional, optional information. I
loaded up my solution, added the new method, changed the guts of the
old method to forward its parameters and to provide default values for
the new params in the new procedure and compiled.

What I *expected* was that I could delete the old class from the GAC,
overwrite the old DLL, and re-install it into the GAC. I thought,
since the old method had the same signature, that the app would just
keep working. Instead, it complained of not being able to find the
old DLL.

Can someone point me to an article that explains the correct way to
extend/enhance a DLL that is deployed into the GAC, please?

Surely I am not back to the world of super strict interface contracts
and having to version every DLL even if it can still be called the
same way it once could.

Thanks!

-Kevin Buchan
(e-mail address removed)

 

[Marina]

What was the version of your DLL? Did it change?

The deal with strongly singed assemblies, is that references to them include
the version of the DLL being referenced. Meaning, if at runtime a DLL with
that precise version cannot be found, you have a problem. Even if the
interface remained the same, and it was just a bug fix - the version must be
the version that the other component was compiled with. If the version
changed, the client component needs to be recompiled with the newer version
of your strong assembly.

 

[Kevin Buchan]

OK, that's very helpful. That's exactly what happened.

My version scheme was set up as "1.0.*". I was certain that I had
read somewhere that as long as the 'major' and 'minor' parts of the
version number remained the same that the assembly would be picked up
by anything that uses it. I thought that the 'revision' and 'build'
numbers were only to be informative to the development and testing
teams, but didn't affect applications that reference the library.

I will test. I sincerely hope that I can at least change the build
number.

You've been a big help.


-Kevin Buchan
(e-mail address removed)