我想尽可能多地收集有关.NET/CLR中API版本控制的信息,特别是API更改如何破坏客户端应用程序.首先,让我们定义一些术语:
API更改 - 类型的公开可见定义的更改,包括其任何公共成员.这包括更改类型和成员名称,更改类型的基本类型,从类型的已实现接口列表添加/删除接口,添加/删除成员(包括重载),更改成员可见性,重命名方法和类型参数,添加默认值对于方法参数,在类型和成员上添加/删除属性,以及在类型和成员上添加/删除泛型类型参数(我错过了什么吗？).这不包括成员团体的任何变化,或私人成员的任何变化(即我们不考虑反射).
二进制级别中断 - 一种API更改,导致针对旧版本API编译的客户端程序集可能无法加载新版本.示例:更改方法签名,即使它允许以与之前相同的方式调用(即:void返回类型/参数默认值重载).
源级别中断 - 一种API更改,导致编写现有代码以针对旧版本的API进行编译,可能无法使用新版本进行编译.然而,已经编译的客户端程序集像以前一样工作.示例:添加一个新的重载,这可能导致前一个明确的方法调用不明确.
源级安静语义更改 - 一种API更改导致编写的现有代码针对旧版API进行编译,从而悄然改变其语义,例如通过调用不同的方法.但是,代码应该继续编译而不会出现警告/错误,以前编译的程序集应该像以前一样工作.示例:在现有类上实现新接口,导致在重载解析期间选择不同的重载.
最终目标是尽可能地对尽可能多的破坏和静默语义API更改进行编目,并描述破坏的确切影响,以及哪些语言受其影响并且不受其影响.扩展后者:虽然一些变化普遍影响所有语言(例如,向接口添加新成员将破坏任何语言中该接口的实现),但有些需要非常特定的语言语义才能进入游戏以获得休息.这通常涉及方法重载,并且通常涉及与隐式类型转换有关的任何事情.似乎没有任何方法可以在这里定义"最小公分母",即使对于符合CLS的语言(即至少符合CLI规范中定义的"CLS使用者"规则的那些语言) - 尽管我会很感激,如果有人在这里纠正我错了 - 所以这必须按语言去语言.那些最感兴趣的东西自然就是开箱即用的.NET:C#,VB和F#; 但其他人,如IronPython,IronRuby,Delphi Prism等也是相关的.它的角落越多,它就越有趣 - 删除成员之类的东西是不言而喻的,但是例如方法重载,可选/默认参数,lambda类型推断和转换运算符之间的微妙交互可能会非常令人惊讶有时.
举几个例子来启动这个:
种类:源级休息
受影响的语言:C#,VB,F#
更改前的API:
public class Foo
{
public void Bar(IEnumerable x);
}
更改后的API:
public class Foo
{
public void Bar(IEnumerable x);
public void Bar(ICloneable x);
}
示例客户端代码在更改之前工作并在其之后中断:
new Foo().Bar(new int[0]);
种类:源级休息.
受影响的语言:C#,VB
语言不受影响:F#
更改前的API:
public class Foo
{
public static implicit operator int ();
}
更改后的API:
public class Foo
{
public static implicit operator int …我有一个提供API的程序集,并由一些其他程序集使用.我需要验证较新版本的API dll是否仍然与使用旧版API的旧程序集兼容.
我发现了几个问同样的问题,但没有解决问题的答案:
建议的工具只能比较两个程序集,并说明API中是否存在可能的重大更改,但如果最新的API确实破坏了使用它的旧程序集,则不会.我想找一个工具或编写一个能够检查每个旧dll是否可以使用我的新API dll的测试.
至于API的变化,我更有可能只扩展它,但即使它仍然可以破坏旧程序集中的代码.这些变化的一些例子可以在这里找到:
现在,我看到的唯一解决方案是使用最新的API编译旧程序集的源代码,但我想只使用程序集并将它们作为单元测试的一部分添加.有什么更好的方法可以处理吗？
编辑:
我正在寻找一种能够自动验证.net程序集之间向后兼容性的过程的工具.(命令行或者也有一些api)