我们希望将一些与基础设施相关的代码（主要是扩展方法或小帮助程序类）提取到单独的NuGet包中。
这些包绝不包含与任何一项服务相关的业务逻辑。
但是，当我们最终在包之间建立依赖关系的层次结构时，我们可能会因版本控制而遇到麻烦：
Service1通过引用的包B间接引用包Av1.1和间接引用Av2.0。
ServiceN直接通过引用包C引用Av1.5和Av1.3包。
NuGet不支持并行版本，每个项目只使用一个版本。版本控制的这个问题与单片应用程序相关，尽管可能的集成问题显然更少。
有一些想法，例如不提取公共代码并让它在服务之间重复，或者只是不更改包的版本，强制每个服务使用相同的版本。
是否有关于服务之间代码重用的良好建议，哪些与版本控制相符？
答案 0 :(得分：1)
在这种情况下，使用semantic versioning可以减少或消除团队在不同版本的内部库之间移动时遇到的重大变更。语义版本控制的核心概念是主要版本增量表示添加向后不兼容的更改（例如删除或更改公共API中方法的签名）。相比之下，在同一主要版本中的不同次要版本或补丁版本之间不得发生这种向后不兼容的更改。遵循这些约定，您的团队应该能够避免内部库彼此不兼容的问题（在同一主要版本中）。 Obsolete属性在这里也是您的朋友，用于标记将在下一个主要版本中删除的代码。
一旦您的团队为您的库使用语义版本控制，项目就可以（通常）安全地引用同一个程序集的不同版本，就像您的示例中的第二个一样。这些不同的版本可以unified通过绑定重定向来使用该程序集的相同版本（通常是两者的较高版本）。如果您使用的是Visual Studio 2013或更高版本，如果使用库的项目文件中存在this tag，则可以自动生成和更新这些内容。对于您的第一个示例，如果Av2.0和Av1.1具有不兼容的API，则使用Nuget将允许您更新到Av2.0，测试该版本，并在某些内容无法正常工作时进行回滚。 / p>
根据工作中的个人经验，我强烈建议使用Nuget和语义版本控制而不是复制粘贴代码或将所有内部库保留在同一个程序集版本中。复制代码通常被视为bad practice（请参阅this answer）。永远不更改程序集的版本号使得很难在不对其进行反编译的情况下判断该程序集文件中的代码是什么。