我需要一些关于管理程序集和版本及其源代码控制的指导。
首先，关于应用程序的一些背景知识。该应用程序是一个ERP类型的系统，其中几个客户可以运行各种模块;他们中有一些 标准和/或其中一些专门为客户定制。每个模块实现特定的业务功能或其变体。 理由是这些模块可以轻松互换/定制，而不会影响其他模块或需要重建。
该应用程序基于应用程序shell，应用程序核心，然后是运行时加载的模块。所有的客户都使用 应用程序shell和核心，然后任意数量的模块。目前我有大约70多个模块。
应用程序核心由2个程序集组成。第一个是服务/业务逻辑，数据访问层，数据对象等。 第二个是所有基本UI表单，对话框等。
每个模块都是作为自己的程序集实现的（作为解决方案中的VS项目）。每个项目都参考了2个核心 组件。应用程序启动时，将在运行时加载这些模块程序集。因此，要更改模块，可以简单地进行 更换组件。主应用程序shell创建应用程序核心类实例。
现在的情况如下： - 当我更换模块时，其装配版本会受到撞击。
当我更改核心汇编方法的实现（即不更改任何类签名）时，我不需要 重建依赖模块，因此它们的版本保持原样。但是，核心组件版本受到了冲击。
当我向核心类添加属性或方法时，我也不需要重建依赖模块，因此他们的版本 保持原样。同样，核心组件版本也受到了冲击。
但是，当我更改核心类的签名时，我需要重建所有依赖程序集。我应该碰撞每个模块吗？ 在这种情况下的版本？
版本控制
看到每个模块都是一个单独的项目，它们在VSS树中各有一个不同的根元素。所以我应该标记每个模块 具有版本的节点？
管理版本依赖项的最佳方法是什么？的Excel？
此外，每个客户的部署现在都是一个版本（带有编号），但有一组模块，每个模块都有各自的组件版本。 我该怎么跟踪这个？
我将非常感谢有关版本控制的任何建议/意见，以及必须管理此模块目录的理念
答案 0 :(得分：0)
第1步 - 停止使用VSS并使用Subversion，Mercurial或Git等真正的版本控制系统，以便您有效地使用分支和标记。在管理不同的设置和依赖关系时，这将有助于 ton 。
第2步 - 遵循Semantic Versioning指南，为每个模块或版本化项目执行此操作。这将为依赖于特定模块的其他元素提供一种简单的方法来确定范围其依赖模块之一的下一版本
通常，模块的版本只应根据语义版本控制准则进行更改，这些准则完全侧重于模块的 外部API 的更改方式。因此，如果依赖模块的版本发生变化，但我们正在处理的模块的外部API没有变化，那么您将碰到补丁版本号（例如1.12.5 -> 1.12.6）
如果您在版本控制系统中使用标签和分支，每个部署版本都有一个标签和分支，您将能够轻松跟踪取决于什么，因为它记录在版本控制历史记录中。在不同的分支机构拥有不同的客户可以为您提供所需的所有灵活性，而且您无需追踪任何额外的内容，因此无需额外的开销。