6

我有以下场景：通过 IDE 和构建脚本构建应用程序。构建脚本用于初始设置（获取依赖项、设置环境）、生成二进制文件和持续集成过程。我希望二进制文件在构建时将月份和日期作为 AssemblyFileVersion，并在修订时使用 svn 修订。这会导致 AssemblyInfo.cs 在每个修订版上都发生变化，从而在源代码控制日志中产生大量噪音。我可以忽略这些文件，但作为设置的一部分，我需要重新生成这些文件。

我想知道是否有人有任何其他想法，或者您在这种情况下会做什么。

4

5 回答 5

6

现在，我确定了一个受 Andy White 回答启发的解决方案：

  • AssemblyInfo.cs 由来自http://msbuildtasks.tigris.org/的AssemblyInfo任务生成，并保存在源代码控制树之外。
  • 版本是 [major].[minor].[month][day].[svn revision]。主要和次要是手动设置的，其他由构建脚本管理。社区任务包包括获取工作副本 svn 修订版和日期所需的两项任务。

不足之处：

  • 当有人签出新副本时，必须运行构建脚本的设置目标，否则 Visual Studio 将抱怨缺少文件。这是我想在将来消除的问题。
于 2009-03-27T16:46:19.020 回答
5

我认为 AssemblyInfo.cs 的一个常见做法是在构建过程中动态生成它，而不是保留一个静态文件。

通过生成，您可以使用任何您想要的任意/可配置的设置。

我相信 NAnt 有一个<asminfo>为此目的的任务。我猜 MSBuild 也有类似的东西。或者您可以编写一个自定义文件生成脚本并使用它将自定义 AssemblyInfo.cs 推入您的构建中。

于 2009-03-27T00:24:44.947 回答
1

我们仅在 RTM/RTW/GA/(Whatever:) 发布构建后更新主干上的 AssemblyInfo。

我们的 Nightly/Beta/RC/QA/(Whatever:) 构建只需将更新的 AssemblyInfo.cs的副本（来自 CI 服务器上的工作副本）复制到相应的分支或标签中。我们使用 Subversion，您可以在具有未提交更改的工作副本上进行分支/标记。

这使我们能够在分支或标签中为 Nightly/Beta 构建保留正确版本的 AssemblyInfo，并且仅在最终版本发生后才触摸主干中的 AssemblyInfo。构建服务器有一个开关，告诉它在这种类型的构建中将其提交到主干。

FWIW，我们从 MSBuild 脚本驱动它，为每个项目类型设置的属性使用不同的值，从我们的构建服务器 (CruiseControl.NET) 传递。

[编辑] 另请注意，开发人员的 AssemblyInfo 版本没有更新（除非他们手动更改它），因此他们不会在每次构建时收到修改后的 AssemblyInfo 的噪音。我们让开发人员控制Major.Minor，构建服务器控制Build，我们将 Revision for QA 留给他们自己的系统（因为无论如何它都会被 WiX/MSI 忽略）。

于 2009-03-27T00:50:59.923 回答
0

如果您不将更改后的 AssemblyInfo.cs 重新检查到源代码管理中，那么为什么会有噪音？

我建议对整个构建使用单个 AssemblyFileVersion 值，并且您可以签入包含该版本的单个文件，和/或使用版本号标记构建。这样，您就不会觉得需要签入多个修改过的 AssemblyInfo.cs 文件。

于 2009-03-27T00:25:24.743 回答
0

我们还使用生成步骤来创建 AssemblyInfo.[cs|vb] 文件，尽管我们只是使用文件的模板副本作为源，然后使用一个小的 Perl 脚本来解析该模板、替换版本字符串并生成最终输出。

这个系统的问题是 VB 项目似乎不断地加载 AssemblyInfo 文件，这意味着项目在第一次加载时会出错，甚至在 PreBuild 步骤可以运行以创建 AssemblyInfo.vb 文件之前。我们还没有找到解决这个问题的方法——如果有人有见识，我很想听听......

于 2009-05-21T14:51:40.077 回答