这种情况在实践中是非常罕见的，但当它发生时还是令人惊讶的。

添加新的非重载成员

Kind:源级中断或安静的语义更改。

受影响的语言:c#， VB

不受影响的语言:f#， c++ /CLI

更改前的API:

public class Foo
{
}

更改后的API:

public class Foo
{
    public void Frob() {}
}

被更改破坏的示例客户端代码:

class Bar
{
    public void Frob() {}
}

class Program
{
    static void Qux(Action<Foo> a)
    {
    }

    static void Qux(Action<Bar> a)
    {
    }

    static void Main()
    {
        Qux(x => x.Frob());        
    }
}

注:

这里的问题是由c#和VB中存在重载解析的lambda类型推断引起的。这里使用了一种有限形式的duck类型，通过检查lambda的主体对给定类型是否有意义来打破多个类型匹配的关系——如果只有一种类型产生可编译的主体，则选择该类型。

The danger here is that client code may have an overloaded method group where some methods take arguments of his own types, and others take arguments of types exposed by your library. If any of his code then relies on type inference algorithm to determine the correct method based solely on presence or absence of members, then adding a new member to one of your types with the same name as in one of the client's types can potentially throw inference off, resulting in ambiguity during overload resolution.

请注意，本例中的类型Foo和Bar在任何方面都没有关联，不是通过继承或其他方式。仅仅在一个方法组中使用它们就足以触发这种情况，如果这种情况发生在客户端代码中，则您无法控制它。

The sample code above demonstrates a simpler situation where this is a source-level break (i.e. compiler error results). However, this can also be a silent semantics change, if the overload that was chosen via inference had other arguments which would otherwise cause it to be ranked below (e.g. optional arguments with default values, or type mismatch between declared and actual argument requiring an implicit conversion). In such scenario, the overload resolution will no longer fail, but a different overload will be quietly selected by the compiler. In practice, however, it is very hard to run into this case without carefully constructing method signatures to deliberately cause it.

重命名接口

休息一下:源代码和二进制文件

受影响的语言:很可能全部，用c#测试。

更改前的API:

public interface IFoo
{
    void Test();
}

public class Bar
{
    IFoo GetFoo() { return new Foo(); }
}

API变更后:

public interface IFooNew // Of the exact same definition as the (old) IFoo
{
    void Test();
}

public class Bar
{
    IFooNew GetFoo() { return new Foo(); }
}

示例客户端代码，可以工作，但随后被破坏:

new Bar().GetFoo().Test(); // Binary only break
IFoo foo = new Bar().GetFoo(); // Source and binary break

具有可空类型参数的重载方法

类型:源级中断

受影响的语言:c#， VB

更改前的API:

public class Foo
{
    public void Bar(string param);
}

更改后的API:

public class Foo
{
    public void Bar(string param);
    public void Bar(int? param);
}

样例客户端代码在更改前工作，更改后失效:

new Foo().Bar(null);

例外:以下方法或属性之间的调用是模糊的。

这种情况在实践中是非常罕见的，但当它发生时还是令人惊讶的。

添加新的非重载成员

Kind:源级中断或安静的语义更改。

受影响的语言:c#， VB

不受影响的语言:f#， c++ /CLI

更改前的API:

public class Foo
{
}

更改后的API:

public class Foo
{
    public void Frob() {}
}

被更改破坏的示例客户端代码:

class Bar
{
    public void Frob() {}
}

class Program
{
    static void Qux(Action<Foo> a)
    {
    }

    static void Qux(Action<Bar> a)
    {
    }

    static void Main()
    {
        Qux(x => x.Frob());        
    }
}

注:

这里的问题是由c#和VB中存在重载解析的lambda类型推断引起的。这里使用了一种有限形式的duck类型，通过检查lambda的主体对给定类型是否有意义来打破多个类型匹配的关系——如果只有一种类型产生可编译的主体，则选择该类型。

The danger here is that client code may have an overloaded method group where some methods take arguments of his own types, and others take arguments of types exposed by your library. If any of his code then relies on type inference algorithm to determine the correct method based solely on presence or absence of members, then adding a new member to one of your types with the same name as in one of the client's types can potentially throw inference off, resulting in ambiguity during overload resolution.

请注意，本例中的类型Foo和Bar在任何方面都没有关联，不是通过继承或其他方式。仅仅在一个方法组中使用它们就足以触发这种情况，如果这种情况发生在客户端代码中，则您无法控制它。

The sample code above demonstrates a simpler situation where this is a source-level break (i.e. compiler error results). However, this can also be a silent semantics change, if the overload that was chosen via inference had other arguments which would otherwise cause it to be ranked below (e.g. optional arguments with default values, or type mismatch between declared and actual argument requiring an implicit conversion). In such scenario, the overload resolution will no longer fail, but a different overload will be quietly selected by the compiler. In practice, however, it is very hard to run into this case without carefully constructing method signatures to deliberately cause it.

添加具有默认值的参数。

中断类型:二进制级别的中断

即使调用源代码不需要更改，它仍然需要重新编译(就像添加常规参数一样)。

这是因为c#将参数的默认值直接编译到调用程序集中。这意味着如果您不重新编译，您将得到一个MissingMethodException，因为旧程序集试图调用带有较少参数的方法。

更改前的API

public void Foo(int a) { }

更改后的API

public void Foo(int a, string b = null) { }

之后被破坏的示例客户端代码

Foo(5);

客户端代码需要在字节码级别上重新编译为Foo(5, null)。被调用的程序集将只包含Foo(int, string)，而不是Foo(int)。这是因为默认参数值纯粹是一种语言特性，. net运行时对它们一无所知。(这也解释了为什么在c#中默认值必须是编译时常量)。

将显式接口实现转换为隐式接口实现。

打破:来源

受影响语言:所有

将显式接口实现重构为隐式接口实现在如何破坏API方面更为微妙。从表面上看，这似乎是相对安全的，然而，当与继承结合在一起时，它可能会导致问题。

更改前的API:

public class Foo : IEnumerable
{
    IEnumerator IEnumerable.GetEnumerator() { yield return "Foo"; }
}

API变更后:

public class Foo : IEnumerable
{
    public IEnumerator GetEnumerator() { yield return "Foo"; }
}

样例客户端代码在更改前工作，更改后被破坏:

class Bar : Foo, IEnumerable
{
    IEnumerator IEnumerable.GetEnumerator() // silently hides base instance
    { yield return "Bar"; }
}

foreach( var x in new Bar() )
    Console.WriteLine(x);    // originally output "Bar", now outputs "Foo"