我们正在开发一个包含多个物理层上的组件的应用程序，共享许多程序集以及每个层独有的一些程序集。
我想知道发布热修复程序的典型版本控制策略是什么，或者只是应用程序的几个组件。
我们的问题跟踪软件包含整个产品的版本号。如果当前版本是 1.4.5 并且需要修补程序，则修补程序的问题将针对 1.4.6 发布。受 1.4.6 修复影响的所有程序集的版本均为 1.4.6。如果我们只分发这些文件，我们最终会得到一些 1.4.5 版本的文件和一些 1.4.6 版本的文件。
一个解决方案可能是将整个应用程序重新构建并发布为 1.4.6，但这需要重新部署多台机器上的多个组件，并导致实际上没有更改的组件不必要的停机时间。
人们针对这个问题采取了哪些策略？接受某些文件将具有不同的版本号只是一个问题吗？在过去，我发现这会导致与客户（1 级）支持团队的混淆。
你提出了一个有趣的问题。
这实际上是您需要做出的一个政策决定，以决定您的部署和版本控制策略，并考虑各种因素的权衡（您已经注意到其中一些因素，例如客户的困惑）。
您可以做的其中一件事是将各个层的发布和版本控制分离，这将允许您在一个层内具有一致的版本控制，同时减少修补程序部署开销。您还需要将通用程序集分解为单独的包和版本，也可以独立进行。
这可能是矫枉过正，因此另一种方法是使您的版本控制更容易掌握。例如，您可以保留部分版本号以指示修补程序。例如，如果 1.4.5.0 是正式版本，则修补程序将是 1.4.5.1，这很容易理解为 1.4.5 正式版本的一部分。
您还可以使用其他程序集版本，例如AssemblyInformationalVersion为您的用户存储版本信息。（查看我的博客文章，了解有关AssemblyInformationalVersion.NET 中的程序集版本控制的更多详细信息。）