Binary Compatibility equivalent in .NET ?

[Jimi]

I have a client that insists that there be some sort of binary
compatibility equivalent in the .NET assemblies I'm producing
(converted from VB6 code). I understand their concern: while you
don't *need* binary compatibility since you can just plunk in newer
versions of assemblies (unlike in COM where the entire mess had to be
recompiled if you didn't use binary compatibility), you might want
some way to warn or prevent developers from making changes that may
break an app using the assembly. I think this was the other main
advantage of binary compatibility - it prevented thoughtless breaking
changes thrown in all over the place.

Any ideas?

 

[Jonathan Allen]

You can create an interface for all public classes. Put the interfaces in a
separate assembly, which is tightly controlled. If the programmer wants to
make a breaking change, he will need to get permission from the person who
controls the interface assembly.

Jonathan Allen

 

[Scott M.]

Unlike with COM, a .NET project that has a reference to another assembly
also has a reference to that assembly's version. If a new version of the
assembly show up, it does not mean that the .NET application will
immediately begin using it. This control over versioning is what the Global
Assembly Cache and the .NET Framework Security and Configuration tools are
all about.

 

[Jimi]

Thanks Jonathon and Scott, but I what I'm really looking for is an way
to at least warn programmers *before* they save a breaking change.
With binary compatibility this is what happens - a developer has no
excuse and can't say "gee - I didn't know I'd be breaking
compatibility". Yes, it's true that you can have release versions
and the assembly with the breaking change doesn't get used until the
correct version is referenced, but still once you want to get
everyone on the latest version, you have a breaking change.

With the interface suggested by Jonathon - fine, you either get
permission or the same developer may control that (I'm thinking small
shops here), you still can get away with reckless breaking changes.

So the real crux is: is there a tool within .NET or a third-party tool
that imposes the automatic discipline of binary compatibility?

 

[Jon Skeet [C# MVP]]

Thanks Jonathon and Scott, but I what I'm really looking for is an way
to at least warn programmers *before* they save a breaking change.
With binary compatibility this is what happens - a developer has no
excuse and can't say "gee - I didn't know I'd be breaking
compatibility". Yes, it's true that you can have release versions
and the assembly with the breaking change doesn't get used until the
correct version is referenced, but still once you want to get
everyone on the latest version, you have a breaking change.

With the interface suggested by Jonathon - fine, you either get
permission or the same developer may control that (I'm thinking small
shops here), you still can get away with reckless breaking changes.

You could still get away with reckless breaking changes if the compiler
warned you. If you don't have sufficient discipline to know that
changing anything in the interface assembly is a potentially breaking
change (and when you're changing just the interface, it's pretty
obvious when something is a breaking change) then there's not a lot of
hope that a tool is going to help anyway.

 

[Scott M.]

If I have a working project and then change one of my references to
reference a new version of an assembly that my project uses and all of a
sudden, my project breaks, wouldn't I know that I have referenced an
assembly with a breaking change?

Conceptually, you have a good point, but in .NET reality, it just doesn't
come up as an issue since one of the whole points of .NET versioning is that
you can't just "slip" in a new version of an assembly and have the project
begin to use it. Projects are "tied" to specific assembly versions unless
the project admin. wants to specifically change the version that is being
targeted.

 

[Jimi]

Yeah - I guess the interface idea is pretty good, but the first thing
my client is gonna say is "what! we need interfaces for everything
now!?". Is there a tool which will provide the same warnings as
binary compatibility did without having to extract the interfaces for
about half a million lines of code?

 

[Jimi]

Scott M.wrote:
If I have a working project and then change one of my references to

reference a new version of an assembly that my project uses and all of a
sudden, my project breaks, wouldn't I know that I have referenced an

assembly with a breaking change?

Conceptually, you have a good point, but in .NET reality, it just doesn't
come up as an issue since one of the whole points of .NET versioning is that
you can't just "slip" in a new version of an assembly and have the project
begin to use it. Projects are "tied" to specific assembly versions unless
the project admin. wants to specifically change the version that is being
targeted.

The point is to provide the wakeup call to the person *coding* the
breaking change so that they may rethink and not break compatibility,
not the person whose project breaks when they reference the new
assembly. By the time the breaking change affects other projects,
it's too late - this was one of the main advantages of binary
compatibility.

So, in summary, I guess I have to tell my client to either forget
about it or tell them there is a very expensive way to do it - create
interfaces for absolutely everything.