名称空间之外

源级中断/源级安静语义更改

由于vb中命名空间解析的工作方式。Net中，向库中添加名称空间会导致使用以前版本的API编译的Visual Basic代码不能使用新版本编译。

示例客户端代码:

Imports System
Imports Api.SomeNamespace

Public Class Foo
    Public Sub Bar()
        Dim dr As Data.DataRow
    End Sub
End Class

如果API的新版本添加了API . somenamespace。数据，则上述代码将无法编译。

使用项目级名称空间导入会变得更加复杂。如果上面的代码中省略了Imports System，但是在项目级别导入了System名称空间，那么代码仍然可能导致错误。

然而，如果Api在它的Api. somenamspace . data命名空间中包含一个类DataRow，那么代码将被编译，但dr将是System.Data.DataRow的一个实例，当使用旧版本的Api编译时，当使用新版本的Api编译时，则是Api. somenamspace . data .DataRow。

参数重命名

源代码级打破

改变参数的名称是vb.net从版本7(?)(。Net版本1?)和c#. Net版本4(。Net版本4)。

更改前的API:

namespace SomeNamespace {
    public class Foo {
        public static void Bar(string x) {
           ...
        }
    }
}

更改后的API:

namespace SomeNamespace {
    public class Foo {
        public static void Bar(string y) {
           ...
        }
    }
}

示例客户端代码:

Api.SomeNamespace.Foo.Bar(x:"hi"); //C#
Api.SomeNamespace.Foo.Bar(x:="hi") 'VB

参考参数

源代码级打破

添加具有相同签名的方法重写，只是其中一个参数是通过引用而不是通过值传递的，这将导致引用API的vb源代码无法解析该函数。Visual Basic没有办法(?)在调用点区分这些方法，除非它们有不同的参数名，所以这样的更改可能导致两个成员在vb代码中都不可用。

更改前的API:

namespace SomeNamespace {
    public class Foo {
        public static void Bar(string x) {
           ...
        }
    }
}

更改后的API:

namespace SomeNamespace {
    public class Foo {
        public static void Bar(string x) {
           ...
        }
        public static void Bar(ref string x) {
           ...
        }
    }
}

示例客户端代码:

Api.SomeNamespace.Foo.Bar(str)

从字段到属性更改

二进制级中断/源代码级中断

除了明显的二进制级中断外，如果通过引用将成员传递给方法，还可能导致源级中断。

更改前的API:

namespace SomeNamespace {
    public class Foo {
        public int Bar;
    }
}

更改后的API:

namespace SomeNamespace {
    public class Foo {
        public int Bar { get; set; }
    }
}

示例客户端代码:

FooBar(ref Api.SomeNamespace.Foo.Bar);

API的改变:

添加[Obsolete]属性(你已经提到了属性;然而，当使用warning-as-error时，这可能是一个破坏性的更改。)

二进制级别突破:

Moving a type from one assembly to another Changing the namespace of a type Adding a base class type from another assembly. Adding a new member (event protected) that uses a type from another assembly (Class2) as a template argument constraint. protected void Something<T>() where T : Class2 { } Changing a child class (Class3) to derive from a type in another assembly when the class is used as a template argument for this class. protected class Class3 : Class2 { } protected void Something<T>() where T : Class3 { }

源级安静语义更改:

添加/删除/更改Equals()， GetHashCode()或ToString()的覆盖

(不知道这些适合哪里)

部署变更:

添加/移除依赖/引用 将依赖项更新到新版本 在x86、Itanium、x64或anycpu之间更改“目标平台” 在不同的框架安装上构建/测试(例如，在.Net 2.0盒子上安装3.5允许调用需要.Net 2.0 SP2的API)

引导程序/配置更改:

添加/删除/更改自定义配置选项(即App.config设置) 随着IoC/DI在当今应用程序中的大量使用，有必要为依赖于DI的代码重新配置和/或更改引导代码。

更新:

对不起，我没有意识到这是打破我的唯一原因是我在模板约束中使用它们。

当我发现它时，这一点非常不明显，特别是考虑到接口的相同情况。这根本不是一个休息，但我决定把它包括在内，这是足够令人惊讶的:

将类成员重构为基类

Kind:不休息!

受影响的语言:无(即没有损坏)

更改前的API:

class Foo
{
    public virtual void Bar() {}
    public virtual void Baz() {}
}

更改后的API:

class FooBase
{
    public virtual void Bar() {}
}

class Foo : FooBase
{
    public virtual void Baz() {}
}

在整个更改过程中保持工作的示例代码(即使我预计它会中断):

// C++/CLI
ref class Derived : Foo
{
   public virtual void Baz() {{

   // Explicit override    
   public virtual void BarOverride() = Foo::Bar {}
};

注:

C++/CLI is the only .NET language that has a construct analogous to explicit interface implementation for virtual base class members - "explicit override". I fully expected that to result in the same kind of breakage as when moving interface members to a base interface (since IL generated for explicit override is the same as for explicit implementation). To my surprise, this is not the case - even though generated IL still specifies that BarOverride overrides Foo::Bar rather than FooBase::Bar, assembly loader is smart enough to substitute one for another correctly without any complaints - apparently, the fact that Foo is a class is what makes the difference. Go figure...

添加重载方法以终止默认参数的使用

中断类型:源级安静语义更改

由于编译器将缺少默认参数值的方法调用转换为调用端具有默认值的显式调用，因此提供了与现有编译代码的兼容性;将为之前编译的所有代码找到具有正确签名的方法。

另一方面，不使用可选参数的调用现在被编译为对缺少可选参数的新方法的调用。这一切仍然正常工作，但是如果被调用的代码位于另一个程序集中，那么调用它的新编译代码现在依赖于该程序集中的新版本。部署调用重构代码的程序集而不部署重构代码所在的程序集将导致“方法未找到”异常。

更改前的API

  public int MyMethod(int mandatoryParameter, int optionalParameter = 0)
  {
     return mandatoryParameter + optionalParameter;
  }    

更改后的API

  public int MyMethod(int mandatoryParameter, int optionalParameter)
  {
     return mandatoryParameter + optionalParameter;
  }

  public int MyMethod(int mandatoryParameter)
  {
     return MyMethod(mandatoryParameter, 0);
  }

仍然可以工作的示例代码

  public int CodeNotDependentToNewVersion()
  {
     return MyMethod(5, 6); 
  }

在编译时依赖于新版本的示例代码

  public int CodeDependentToNewVersion()
  {
     return MyMethod(5); 
  }

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

打破:来源

受影响语言:所有

将显式接口实现重构为隐式接口实现在如何破坏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"

这可能是一个不太明显的“添加/删除接口成员”的特殊情况，我认为它应该根据我接下来要发布的另一个情况单独进入。所以:

将接口成员重构为基接口

Kind:源级和二进制级都中断

受影响的语言:c#， VB, c++ /CLI, f#(用于源代码中断;二进制语言自然会影响任何语言)

更改前的API:

interface IFoo
{
    void Bar();
    void Baz();
}

更改后的API:

interface IFooBase 
{
    void Bar();
}

interface IFoo : IFooBase
{
    void Baz();
}

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

class Foo : IFoo
{
   void IFoo.Bar() { ... }
   void IFoo.Baz() { ... }
}

被二进制级别的更改破坏的示例客户端代码;

(new Foo()).Bar();

注:

对于源级中断，问题是c#， VB和c++ /CLI在接口成员实现的声明中都要求精确的接口名称;因此，如果成员被移动到基接口，代码将不再编译。

二进制中断是由于接口方法在生成的IL中完全限定为显式实现，并且接口名称也必须是准确的。

在可用的情况下，隐式实现(即c#和c++ /CLI，但不是VB)在源代码和二进制级别上都可以很好地工作。方法调用也不会中断。