处理程序集版本的正确方法是什么？

我期待着为即将到来的项目实施每日构建。处理程序集版本的正确方法是什么？

但在此之前，我需要知道如何正确地版本程序集。

我有以下的忧虑：

如果每个装配有一个独立的版本号或他们都应该共享相同的版本？
我应该使用*版本进行构建和修订吗？
是否修订与日常构建相关？

来源

2009-09-10 Pierre-Alain Vigeant

我们邮票公司产品中的所有组件，使用以下步骤相同的版本号：

连接所有组件含有版本号信息的 AssemblyInfoCommon.cs：看here 为例。
生成AssemblyInfoCommon.cs文件作为构建的一部分（在我们的情况下）恶性asminfo任务，巡航控制.NET和SVN修订贴标机

在我们的例子中，我们不不使用*版本。所有部署的版本都构建在构建服务器上。我们不担心我们桌面上的版本号。

来源

2009-09-12 12:19:13

+1构建服务器的内部版本号。构建应该是可重复的，这意味着它们应该是脚本化的，并且在桌面上执行它们使得懒惰和“只知道”如何执行它变得容易，而不是经历创建构建脚本的麻烦。 – gregmac 2011-11-10 00:30:56

所以每件应具有相同的版本，这是通常的发行版的组合，即3.4 +的内部版本号是表示该版本已经编译生成服务器上的次数的序列。该修订是相关的，因为它显示了您为该版本创建的构建数量。你可以通过2种方式之一来实现这一点。第一种方法是，如果您计划发布3.4版，那么当您开始使用该版本时，那么这是您的主要版本号，并且您的次要版本号会随着版本的增加而增加。另一种方法是严格控制构建版本，当你准备好发布QA /回归时，你的主要版本设置为3.4，而你的次要版本号为0.你用这种方式严格控制事物直到你释放。这样您就可以通过次要版本号来控制您的服务包编号。希望这可以帮助。

来源

2009-09-10 00:41:19

答案真的取决于你想用程序集版本号来完成什么。如果您正在执行ClickOnce部署并希望独立下载更新的程序集，则需要使每个程序集都独立版本化 - 否则，我认为使程序集版本与软件版本号匹配通常很不错。在更复杂的情况下，您可能需要另一种策略。

我在以前的公司使用的方案是major.minor.revision.build - 因此在1.0版本的产品中，每个程序集的程序集版本和程序集版本都是1.0.0.1129（例如）。这样可以很容易地将哪些程序集作为哪个软件版本的一部分，直到构建编号。我们使用预编译搜索完成了这项工作，并在每个AssemblyInfo.cs文件中进行替换，以便用我们的自动构建过程提供的版本号来替换令牌。

来源

2009-09-10 00:42:10

我通常会同意所有程序集应该有相同的版本号;然而，我会对此做出一个警告。如果其中一个程序集在此项目之外的其他地方使用，或者如果它被认为是它自己的项目，它应该有它自己的版本号。它也可能被移出解决方案并进入它自己的解决方案。我提到这一点的唯一原因是我曾多次看到人们在其他几个地方使用过一个程序集，但主要集中在一个地方，他们试图保持版本的正确性。这样做不是个好主意。我认为单一职责原则也适用于解决方案/项目级别。

就编号而言，我同意Guy Starbuck（major.minor.revision.build）。这是我一直这样做的方式，它一直运行良好。

来源

2009-09-14 07:17:01

我们有一个大型应用程序（数百个程序集），频繁发布（约1个月）。我们去“为每个程序集提供相同的版本”，但是它对我来说是一个持续不断的来源，尽管事实上这些组件的接口很少（如果有的话）改变，但是1版本的程序集完全不兼容。

如果您遇到这种情况，那么您可能会从版本控制程序集中分别获益 - 每次更新程序集时，只打算在实际需要中断程序集绑定的情况下增加版本号（例如，如果界面更改，或者您想防止某人意外使用以前的版本，这些更改是非常重要的）。

来源

2009-09-17 23:07:06 Justin

处理程序集版本的正确方法是什么？

回答

相关问题