Re: [Mono-devel-list] Assembly binary compatibility?
In general, adding or removing an override is not a breaking change. Finalize works by chaining to the parent using base.Finalize. calling a method on base will always say call my direct parent.Method. In the JIT we would in the debug build see: my direct parent has the finalize method so call that, but in the non-debug build see my direct parent doesn't have a finalizer, so lets try one in the parent of that class. Sadly, due to some limitations in System.Reflection, MCS does not implement this correctly. http://bugzilla.ximian.com/show_bug.cgi?id=26204 As you can tell, thats a pretty old bug ;-( Thanks for the explanation, Ben! What about other changes though? Is it safe to add public data member? Safe to add a public method? Safe to add a private method or data member? Basically, what I'd like to find is a list that details exactly what is and isn't binary compatible. Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 ZeroC, Inc.http://www.zeroc.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Assembly binary compatibility?
On Wed, 2005-05-04 at 17:01 +1000, Michi Henning wrote:
In general, adding or removing an override is not a breaking change.
Finalize works by chaining to the parent using base.Finalize. calling a
method on base will always say call my direct parent.Method. In the
JIT we would in the debug build see: my direct parent has the finalize
method so call that, but in the non-debug build see my direct parent
doesn't have a finalizer, so lets try one in the parent of that class.
Sadly, due to some limitations in System.Reflection, MCS does not
implement this correctly.
http://bugzilla.ximian.com/show_bug.cgi?id=26204
As you can tell, thats a pretty old bug ;-(
Thanks for the explanation, Ben! What about other changes though?
Is it safe to add public data member?
Yes, with the exception of stuff that is passed to pinvoke -- there the
standard rules of C apply.
Safe to add a public method?
If the method is `abstract' (or if it is part of an interface) -- no.
Otherwise, yes.
However, you do have a risk of introducing source incompat. Imagine
this:
lib v1:
public class X {
public int A (object foo) { return 1; }
}
App v1:
int x = myX.A (my string)
lib v2:
public class X {
public void A (string foo) {}
public int A (object foo) { return 1; }
}
If you compile app v1 with lib v1, the A call will bind to the object
function. However, when compiled with v2, it will bind to the string
one, because that is a better overload. However, this overload returns
void, creating a compile error.
If you run the binary of app v1 compiled with lib v1 on lib v2, it will
still be bound to the object overload.
Safe to add a private method or data member?
Private method -- always. Data member, same rules as public (C rules
apply for pinvoke).
Basically, what I'd like to find is a list that details exactly what is and
isn't binary compatible.
Any change in your program that makes the IL of an app compiled with the
old version invalid is breaking. So, the real answer is look at the
spec, if you make a change that does something 'illegal' then it is
breaking.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Assembly binary compatibility?
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.
--
Michi Henning Ph: +61 4 1118-2700
ZeroC, Inc.http://www.zeroc.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Assembly binary compatibility?
On Wed, 2005-05-04 at 09:25 +1000, Michi Henning wrote: 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. In general, adding or removing an override is not a breaking change. Finalize works by chaining to the parent using base.Finalize. calling a method on base will always say call my direct parent.Method. In the JIT we would in the debug build see: my direct parent has the finalize method so call that, but in the non-debug build see my direct parent doesn't have a finalizer, so lets try one in the parent of that class. Sadly, due to some limitations in System.Reflection, MCS does not implement this correctly. http://bugzilla.ximian.com/show_bug.cgi?id=26204 As you can tell, thats a pretty old bug ;-( -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
