Question

我有一个在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。

如何避免此类问题？我希望能够检测到此类问题并停止构建和发布周期，并能够让开发人员评估他是否应该回滚更改或增加主要版本。