我期待为即将开展的项目实施每日构建。
但在此之前，我需要知道如何正确版装配。
我有以下问题：
答案 0 :(得分：8)
我们使用以下步骤用相同的版本号标记产品中的所有组件：
将所有程序集链接到 AssemblyInfoCommon.cs包含 版本号信息：见here 举个例子。
生成AssemblyInfoCommon.cs文件作为构建的一部分 使用（在我们的例子中）NAnt asminfo任务，Cruise Control .NET和SVN修订标签
在我们的例子中，我们不使用*版本。所有已部署的版本都构建在构建服务器上。我们不担心桌面上的版本号。
答案 1 :(得分：2)
答案实际上取决于您要使用程序集版本号完成的操作。如果您正在进行ClickOnce部署并希望独立下载更新的程序集，则需要对每个程序集进行独立版本化 - 否则，我认为使程序集版本与软件版本号匹配通常会很好。在更复杂的场景中，您可能需要另一种策略。
我以前公司使用的方案是major.minor.revision.build - 所以在产品的1.0版中，每个程序集的程序集版本和程序集文件版本是1.0.0.1129（例如）。这样可以轻松匹配哪些程序集是软件版本的一部分，直至内部版本号。我们使用预编译搜索完成了此操作，并在每个AssemblyInfo.cs文件中替换，以使用我们的自动构建过程提供的版本号替换令牌。
答案 2 :(得分：0)
因此每个程序集应该具有相同的版本，通常是发行版本的组合，即3.4 +构建号，它是表示在构建服务器上编译发布的次数的序列。修订是相关的，因为它演示了您为该版本创建的构建数。你可以用两种方式之一来做到这一点。第一种方式是，如果您计划发布即3.4，那么当您开始处理该版本时，那么这是您的主要版本号，而您的次要版本号随着构建而增加。另一种方法是严格控制构建版本，因为当您准备执行QA / Regression版本时，您将主要版本设置为3.4，并将次要版本号保留为0.您可以通过这种方式严格控制直到你释放。这样，您可以通过次要版本号控制服务包编号。希望这会有所帮助。
答案 3 :(得分：0)
我通常会同意所有程序集都应具有相同的版本号;但是，我会对此提出一个警告。如果其中一个程序集在此项目之外的其他位置使用，或者如果它被认为是自己的项目，则它应该具有自己的版本号。它也应该被移出该解决方案并进入它自己的解决方案。我提到这一点的唯一原因是我见过许多场合，人们有一个在其他几个地方使用的集会，但主要是在一个地方，他们试图保持版本的直线。这样做是个坏主意。我认为单一责任原则也适用于解决方案/项目层面。
就编号而言，我同意Guy Starbuck（major.minor.revision.build）。这就是我一直这样做的方式，而且一直运作良好。
答案 4 :(得分：0)
我们有一个大型应用程序（数百个程序集），频繁发布（大约每月一次）。我们选择了“给每个组件提供相同的版本”，但它一直是我的一个例子，即1个版本的程序集与另一个版本的程序集完全不兼容，尽管这些程序集的接口很少（如果有的话）发生变化。
如果您遇到这种情况，那么您可能会分别从版本控制程序集中受益 - 每次更新程序集时，只有在实际想要破坏程序集绑定的情况下才会增加版本号（例如，如果接口发生更改，或者如果您希望防止某人意外使用以前的版本，那么这些更改是非常重要的。）