Binary compatibility?

[Michi Henning]

Hi,

I'm interested in figuring out exactly what kind of change to an assembly
is binary compatible. I've browsed the doc a fair bit, but I can't find a
comprehensive list of what actually constitutes binary compatibility.
Could someone point me at an authoritative list?

One question in particular I am interested in. Consider an object such as this:

class SomeClass
{
// ...
public void destroy()
{
lock(this)
{
// Clean up some things here...
_destroyed = true;
}
}

#if DEBUG
~SomeClass()
{
if(!System.Environment.HasShutdownStarted)
{
lock(this)
{
if(!_destroyed)
{
System.Console.Error.WriteLine("SomeClass wasn't
destroyed!");
}
}
}
}
#endif

private bool _destroyed = false;
}

Note that the destructor simply checks whether destroy() was called before the
instance is collected and that this is required only for a debug build. In
order to
save the cost of acquiring the lock (and to avoid the cost of calling the
destructor
altogether), the entire destructor is made conditional.

Suppose I build the assembly without DEBUG defined and install it in the GAC.
I also compile a program that uses the assembly, but both the program and the
assembly are compiled *with* DEBUG defined. If I then later take the program
(but not the assembly) and run the program compiled *with* DEBUG against
the assembly compiled *without* DEBUG, will the program still work?

Cheers,

Michi.

 

[Mattias Sjögren]

I'm interested in figuring out exactly what kind of change to an assembly

is binary compatible. I've browsed the doc a fair bit, but I can't find a
comprehensive list of what actually constitutes binary compatibility.
Could someone point me at an authoritative list?

One question in particular I am interested in. Consider an object such as this:

class SomeClass

Changes to non-public classes will not break compatibility.

Suppose I build the assembly without DEBUG defined and install it in the GAC.
I also compile a program that uses the assembly, but both the program and the
assembly are compiled *with* DEBUG defined. If I then later take the program
(but not the assembly) and run the program compiled *with* DEBUG against
the assembly compiled *without* DEBUG, will the program still work?

For public classes, removing the finalizer is indeed a potentially
breaking change (unless the class is sealed). But unless you have
other classes derived from such a class, it doesn't matter and it
should work anyway.



Mattias

 

[Richard Blewett [DevelopMentor]]

Why would removing the finalizer be a breaking change?

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk


For public classes, removing the finalizer is indeed a potentially
breaking change (unless the class is sealed). But unless you have
other classes derived from such a class, it doesn't matter and it
should work anyway.

 

[Mattias Sjögren]

Why would removing the finalizer be a breaking change?

My bad, it isn't. I seemed to remember that removing an override
somewhere in the middle of the inheritance hierarchy would generate a
MissingMethodException when a derived class called the base method,
but clearly it doesn't and I guess that's a good thing.



Mattias