关于msbuild：管理构建版本的最佳构建过程解决方案

我用几个独立的应用程序运行一个相当复杂的项目。但是，它们使用了几个共享组件。所以我有一个看起来像下面的源代码树。

• 我的项目
  • 应用A
  • 共享的1
  • 共享的2
  • 应用B
  • 应用C

所有应用程序都有自己的MSBuild脚本，该脚本可生成项目及其所需的所有共享资源。我还在CruiseControl控制的持续集成构建服务器上运行这些构建。

部署应用程序后，会将它们部署在多台服务器上以分配负载。这意味着跟踪每个不同服务器上部署的构建/修订版本非常重要(我们需要在DLL版本中拥有当前版本，例如" 1.0.0.68")。

同样重要的是，能够重新创建一个修订版本/内部版本，以便在某些事情无法按预期进行时回滚(是的，发生了……)。今天，我们正在使用SourceSafe进行源代码控制，但是如果我们能提出充分的理由(SS到目前为止，实际上对我们来说还可以)，则有可能改变。

我们尝试遵循的另一个原则是，只有我们进一步部署的集成服务器才能构建和测试这些代码。

" CrusieControl构建标签"解决方案

我们对于解决上述问题有一些想法。首先是让持续集成服务器构建并在本地部署项目并对其进行测试(现在可以这样做)。您可能知道CruiseControl的成功构建会生成一个构建标签，而我想我们可以以某种方式使用它来设置可执行文件的DLL版本(因此，构建标签35会创建一个类似" 1.0.0.35"的DLL)？想法也是使用此构建标签来标记整个源代码树。然后，我们可能可以通过该标签签出并稍后重新创建构建。

标记整个树的原因不仅是要包括实际的应用程序代码(位于源树中的一个位置)，还包括所有共享项(位于树中不同位置)。因此，成功构建"应用程序A"将以标签" ApplicationA35"标记整个树。

但是，在尝试重新创建此版本并在部署之前设置DLL版本时可能会出现问题，因为我们将无法再使用CruiseControl生成的版本标签。如果所有CrusieControl构建标签在所有项目中都是唯一的，我们只能使用数字进行标记，但事实并非如此(应用程序A和B都可以同时位于构建35上)，因此我们必须在标签。因此，SourceSafe标签为" Application35"。一旦构建了构建35，我该如何重新创建构建34并将DLL版本号设置为1.0.0.34？

"修订号"解决方案

有人告诉我，例如Subversion在每次签入时都会为整个源代码树创建一个修订号-是这种情况吗？ SourceSafe有类似的东西吗？如果正确的话，那就是获取最新的修订版本号并在CruiseControl服务器上构建。然后可以使用修订号来设置DLL版本号(例如" 1.0.0.5678")。我想如果需要的话，我们可以为Subversion获得这个特定的修订版，然后该版本将包括该应用程序和所有共享项，以便能够从过去重新创建特定的版本。这项工作是否可行，也可以使用SourceSafe来实现吗？

总结

因此，两个主要要求是：

能够跟踪内部版本号和已部署DLL的内部版本号/修订号。

能够重建以前的修订/版本，在该可执行文件上设置旧的构建/版本号(符合要求1)。

那么您将如何解决呢？您首选的方法是什么？如何解决(或者您有完全不同的想法？)？ **请提供详细答案。 **

额外的问题修订号和内部版本号有什么区别？何时真正需要两者？

---

您的方案在VSS中是合理且可以实现的(尽管我建议您考虑使用替代方案，但VSS确实是过时的产品)。

对于您的" CI"构建-您需要进行版本控制，以查看具有"版本"任务的MSBuild社区任务项目。通常，您在源代码树中将有一个" Version.txt"，并且在开发人员控制Major.Minor.Release.Revision数字时，MSBuild任务将增加" Release"数字(这是我的客户想要的)。如果愿意，可以使用修订。

然后，您将具有" FileUpdate"任务来编辑具有该版本的AssemblyInfo.cs文件，并且您的EXE和" DLL"将具有所需的版本。

最后，VSSLabel任务将适当地标记所有文件。

对于" Rebuild"构建-您将修改" Get"以从该Label获取文件，显然不执行" Version"任务(因为您正在选择要构建的版本)，然后FileUpdate任务将使用该版本号。

奖励问题：

这些都是"您想如何使用它们"-我将使用内部版本号，以及内部版本号，这就是我要增加的内容。如果您使用的是CI，则将有很多构建-绝大部分都不打算在任何地方进行部署。

主要和次要是不言而喻的-但是我一直将修订版本用作"修补程序"指示器。我打算发布一个" 1.3"版本-实际上是一个带有1.3.1234.0版本的产品。在1.4上工作时-我发现一个错误-需要1.3.2400.1的热修复。然后当1.4准备好时-会说1.4.3500.0

---

使CC.net标签成功构建

将解决方案中的每个项目链接到一个公共的solutioninfo.cs文件，该文件包含程序集和文件版本属性(从每个项目中删除assemblyinfo.cs)

在构建具有巡航控制功能之前，请运行ccbuild regex替换(来自msbuild社区任务)，以使用cc.net生成标签更新版本信息(作为参数传递给msbuild任务)

建立解决方案，运行测试，FX cop等

(可选)还原解决方案信息文件

结果是cc.net发布的内部版本中的所有程序集都具有与源代码存储库中的标签一致的相同版本号。

---

我需要比回应更多的空间，因为评论直接允许...

Thanks! Good answer! What would be the
difference, what would be better
solving this using SubVersion for
example?Richard Hallgren (15 hours
ago)

VSS的问题与该示例无关(尽管我认为"标签"功能的实施效率不高...)

这是VSS的一些问题

1)基本上不可能分支
2)通常不使用共享结帐(我知道有一些成功的人)
3)效果非常差-极端地是"聊天"
4)除非您的存储库非常小-否则它是完全不可靠的，对于大多数商店来说，这是一个定时的炸弹。

对于4-问题是，VSS是通过将整个存储库在文件系统中表示为"平面文件"来实现的。当存储库超过一定大小(我相信是4GB，但我对该数字不确定)时，您就有机会"腐败"。随着规模的增加，腐败的可能性会越来越大，直到它几乎可以确定为止。

因此，请查看您的存储库大小-如果您正在使用千兆字节-我强烈建议您开始计划更换VSS。

无论如何，" VSS Sucks"的google命中了3万次。。。我想，如果您确实开始使用替代品，您将意识到这是值得的。

---

UppercuT可以通过自定义打包任务来完成所有这些工作，以拆分应用程序。要获得源代码的版本号，您可以考虑使用Subversion。

它也非常容易上手。

http://code.google.com/p/uppercut/

这里有一些很好的解释：UppercuT

---