[Mono-devel-list] Assembly binary compatibility?

[Ben Maurer]

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