如何在多模块/客户场景中管理程序集版本？
我需要一些有关管理程序集和版本及其源代码控制的指导。
首先，介绍一下该应用程序的背景。该应用程序是一个 ERP 类型的系统，多个客户可以运行各种模块；其中一些 标准和/或其中一些专门为客户定制的。每个模块实现特定的业务功能或其变体。 理由是这些模块可以轻松互换/定制，而不会影响其他模块或需要重建。
该应用程序基于应用程序外壳、应用程序核心以及运行时加载的模块。所有客户都使用 应用程序外壳和核心，然后是任意数量的模块。目前我有大约 70 多个模块。
应用程序核心由 2 个程序集组成。第一个是服务/业务逻辑、数据访问层、数据对象等。 第二个是所有基本 UI 表单、对话框等。
每个模块都作为自己的程序集实现（作为解决方案中的 VS 项目）。这些项目中的每一个都参考了 2 个核心 组件。这些模块程序集在应用程序启动时在运行时加载。因此，要更改模块，只需 更换组件。主应用程序外壳创建应用程序核心类实例。
现在的场景是这样的： - 当我更改模块时，其程序集版本会发生变化。
当我更改核心组装方法的实现（即不更改任何类签名）时，我不需要 重建依赖模块，因此它们的版本保持原样。但是，核心程序集版本会受到影响。
当我向核心类添加属性或方法时，我也不需要重建依赖模块及其版本 保持原样。同样，核心程序集版本会受到影响。
但是，当我更改核心类的签名时，我需要重建所有依赖程序集。我应该碰撞每个模块吗 在这种情况下是版本吗？
版本控制
由于每个模块都是一个单独的项目，因此它们在 VSS 树中都有不同的根元素。那么我应该给每个模块贴上标签吗 节点的版本？
管理版本依赖性的最佳方法是什么？ Excel？
此外，每个客户的部署现在都是一个版本（带有编号），但带有一组模块，每个模块都有各自的程序集版本。 我到底如何跟踪这个？
我很感激有关版本控制的任何建议/评论，但也很感激必须管理此模块目录的哲学
I need some guidance on managing assemblies and versions and the source control thereof.
First, a little background on the application. The app is an ERP-type system where several customers can run various modules; some of them
standard and/or some of them customised specifically for the customer. Each module implements a particular business function or variation thereof.
The rationale is that these modules can be interchanged / customised easily without affecting other modules or requiring a rebuild.
The application is based on an application shell, an application core and then the run-time loaded modules. All the customers use the
application shell and core and then any number of modules. Currently I have about 70+ modules.
The application core consists of 2 assemblies. The first being the services/business logic, data access layers, data objects, etc.
The second is all the base UI forms, dialogs, etc.
The modules are each implemented as an assembly of their own (as a VS project in the solution). Each of these projects reference the 2 core
assemblies. These module assemblies are loaded at runtime when the application starts up. So, to change a module, one can simply
replace the assembly. The main application shell creates the application core class instances.
Now the scenario is this:
- When I change a module, its assembly version gets bumped.
When I change the implementation of a core assembly method (i.e. do not change any class signatures), then I dont need a
rebuild of the dependent modules and therefore their versions remain as is. However, the core assembly version gets bumped.When I add a property or method to a core class, then I also dont need a rebuild of the dependent modules and therefore their versions
remain as is. Again, core assembly version gets bumped.However, when I change the signature of a core class, I need a rebuild of all the dependent assemblies. Should I bump each module
version in this case?
Version control
Seeing that each module is a separate project, they each have a different root element in the VSS tree. So should I label each module
node with the version?
What is the best way to manage the version dependencies? Excel?
Also, each customer's deployment is now a release (with a number), but with a set of modules, each having their respective assembly versions.
How the hell do I keep track of this?
I would appreciate any suggestions / comments about the versioning but also the philosophy of having to manage this catalog of modules
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
第 1 步 - 停止使用 VSS 并使用真正的版本控制系统，例如 Subversion、Mercurial 或 Git，这样您可以有效地使用分支和标签。当涉及到管理不同的设置和依赖项时，这将有很大帮助。
第 2 步 - 遵循语义版本控制指南，并对每个模块或版本化项目执行此操作。这将为依赖于特定模块的其他元素提供一种简单的方法来确定其依赖模块之一的下一个版本的范围
通常，模块的版本应该仅根据语义版本控制指南进行更改，它们完全专注于模块的外部 API 的变化。因此，如果依赖模块的版本发生变化，但我们正在处理的模块的外部 API 没有变化，您将增加补丁版本号（例如。
1.12.5 -> 1.12.6)如果您在版本控制系统中使用标签和分支（每个部署版本一个），您将能够轻松跟踪什么依赖于什么，因为它记录在版本控制历史记录中。在不同的分支机构拥有不同的客户可以为您提供所需的所有灵活性，并且您无需跟踪任何额外的内容，因此没有额外的开销。
Step 1 - Stop using VSS and use a real version control system like Subversion, Mercurial, or Git that allows you to effectively use branches and tags. This will help a ton when it comes to managing different setups and dependencies.
Step 2 - Follow the Semantic Versioning guidelines, and do it for each module or versioned item. This will give your other elements that depend on a particular module an easy way to determine the scope the next version of one of their dependent modules
In general, a module's version should only change according to the semantic versioning guidelines, which are entirely focused on how the module's external API changes. So, if a dependent module's version changes, but there are no changes to the external API of the module we are dealing with, you would bump the patch version number (eg.
1.12.5 -> 1.12.6)If you use tags and branches in your version control system, one for each deployed version, you will be able to easily keep track of what depends on what because it's recorded in the version control history. Having different customers on different branches gives you all the flexibility you need, and you don't have to track anything extra, so no extra overhead.