我有一个在Nuget提要中版本化的共享程序集。
通过手动选择一个新的版本号来管理该程序集的版本,以尝试估计是否需要主要版本,次要版本或修补程序版本。
作为配置项步骤,我想分析新版本的程序集是否破坏了与先前版本的兼容性。我特别指的是偷偷摸摸的不兼容性,它们不会更改API的名称(如果重新编译旧代码,它将对新的dll版本有效),但是会更改某些细节(如类型),从而呈现旧的签名和新的签名。在IL级别不兼容。
例如,当类似这样的方法时:
public ModuleConfigurator<T> Setup<T>() where T : IModule, new()
{
return new ModuleConfigurator<T>(this);
}
更改为:
public IModuleConfigurator<T> Setup<T>() where T : IModule, new()
{
return new ModuleConfigurator<T>(this);
}
如果引用了适当的接口,则IL兼容性将丢失:与版本1相比编译的项目在版本2上不起作用。即使相对于版本2重新编译相同的项目也可以。消费代码看起来将完全相似,并且简单的重新编译就足够了,但是程序集(新版本的依赖项和旧的消费代码)将不再能够协同工作。
现在,如果正确识别出这些版本具有重大更改并进行了相应编号,则这不是问题。
但是(手动)编号为1.1.6
和1.2.0
。
如何避免此类问题?我希望能够检测到此类问题并停止构建和发布周期,并能够让开发人员评估他是否应该回滚更改或增加主要版本。