C rotura # interface, ABI

Question

Supongamos que tenemos el class X en la versión 1 de la A.dll montaje:

class X {
    SomeType Property { set; get; }
}

y después en la versión 2 de la A.dll montaje:

class X {
    SomeType Property { set; get; }
    SomeType OtherProperty { set; get; }
}

Ahora supongamos que tenemos una segunda asamblea que B.dll cargas A.dll y usos X. ¿La adición de la propiedad OtherProperty romper el ABI? Se B.dll dejar de usar A.dll / X? Si no es así, sería del orden de las declaraciones alguna diferencia? Si las propiedades habían sido virtual, que se había hecho ninguna diferencia?

Creo que realmente estoy preguntando: ¿cuáles son las reglas generales ABI? Sé que cambiando las interfaces después de que hayan sido publicados es una cosa mala, pero realmente me gustaría ser capaz de añadir propiedades en algunos casos, sin la adición de subclases.

Answer 1

Adición de propiedades debería estar bien.

Un caso que se rompa es si, por ejemplo, añadir algo a la mitad de una enumeración numerada automáticamente. Por ejemplo, si usted tiene este código en su biblioteca:

enum Foo
{
   Bar,
   Qux
}

y lo cambia a esto:

enum Foo
{
   Bar,
   Baz,
   Qux
}

A continuación, también tendrá que volver a compilar cualquier código como el siguiente:

if (foo == Foo.Qux)
{
    //  ...
}

Answer 2

The JIT compiler will spackle a lot of this over, also the source of the error message if the change was breaking.

You are however playing a very dangerous game called DLL Hell. The problem is not that they don't recompile their code, it is when they do. They will, eventually. If then there's a subtle mistake, somebody ran an old version of your installer, copied the wrong file, etcetera then all hell breaks loose. The code won't run and they'll have an impossible job figuring out why. This will happen long after you made the change, you won't have any way to guess what went wrong either and cannot help them.

Don't mess around with this, bump up [AssemblyFileVersion] and [AssemblyVersion]. Yes, they'll have to recompile when you change the latter one. Or use <bindingRedirect>, which is fine too, now there's a traceable record of it.

Btw: this happened in the .NET Framework too. WaitHandle.WaitOne(int) got added in a service pack but without an [AssemblyVersion] change. Programmers targeted .NET 2.0 but their code wouldn't run when the target machine had the original 2.0 installed. Very painful.

Answer 3

It won't break compatibility if is just used by the assembly B. But it will break if the assembly B defines a class which implements the interface, because that class doesn't implement the newly introduced property.