AssemblyInfo.cs 是否应该放在版本控制中？答案

【问题标题】：Should AssemblyInfo.cs be placed in version control?AssemblyInfo.cs 是否应该放在版本控制中？
【发布时间】：2010-11-01 23:22:03
【问题描述】：

我有一个使用 CruiseControl 的自动构建系统。我正在使用 SvnRevisionLabeller 来获取要使用的版本字符串。有了这个字符串，我可以使用 nant 来更新 AssemblyInfo.cs，这样当我构建它时，它就有了正确的构建字符串。我也可以使用这个 CC 标签来标记 subversion 存储库。

所以一切都对齐了
- CCNet 构建标签
- 可执行文件（程序集信息）
- 版本控制（subverson 标签）

现在我遇到的问题是，如果我想尝试从存储库重建旧映像。由于 AssemblyInfo.cs 不受版本控制，而是一个生成的文件，所以当我现在尝试构建时，版本控制信息将与使用 CruiseControl 构建此版本的存储库时不同。我希望能够生成完全相同的图像，无论它是在 CC 构建期间还是在以后从 Subversion 签出时构建的。

我知道这通常不被推荐，但我是否应该在每次构建后签入 assemblyInfo.cs 文件，以便在随后从 svn 签出构建时使用正确的版本信息？

谢谢，利亚姆

【问题讨论】：

标签： svn version-control cruisecontrol.net assemblyinfo

【解决方案1】：

我总是将其签入。事实上，我相信这是 Team System Source Control 的默认行为。

【讨论】：

我正在使用 Subversion 和 CrusieControl.NET。我使用 NAnt 脚本构建。我所读到的是 AssemblyInfo.cs 是在构建过程中生成的输出。所以构建顺序是：- CCNET（SVN 由签入@say 存储库版本 100 触发）称为 msbuild 的 NAnt 称为 assemblyinfo.cs 是在构建之后创建的我现在签入 assemblyInfo.cs 吗？如果签入存储库，则版本号为 101。因此，我的 AssemblyInfo.cs 与构建版本匹配的目标没有实现。我该怎么做？
我相信您不想检查 AssemblyInfo.cs 的原因是您的 CI 系统正在生成它。使用包括 TFS 构建服务器的方式在内的正常构建，AssemblyInfo.cs 会被签入，并且不会为每个构建生成。

【解决方案2】：

要么根本不版本 AssemblyInfo.cs，要么将它们的“开发者版本”放入存储库并在构建后让 CruiseControl.Net svn-revert 它们（我这样做是为了方便在开发者工作站上构建可从从 CruiseControl.Net 下载的“官方”文件中熄灭）。

至于稍后重现相同的构建标签 - 您已经必须通过手动调用 MSBuild / NAnt 来进行重建，只需将 CCNetLabel 设置为适当的值传递给它，您将获得与构建相同的程序集版本从 CruiseControl.Net 调用（MSBuild：/p:CCNetLabel=1.4.2.333，NAnt：-D:CCNetLabel=1.4.2.333）。

【讨论】：

【解决方案3】：

我使用一个 CommonAssemblyInfo.cs 文件，我在每个项目中都添加了一个链接。

我在此文件中的唯一属性是 AssemblyFileVersion，并且每次构建时 CC.Net / Msbuild 都会更新版本。

确保任何包含 CommonAssemblyInfo.cs 的项目在 AssemblyInfo.cs 中没有重复的属性。

如果您查看 CC.Net 源代码，您会看到它们是如何构建配置的。

【讨论】：

【解决方案4】：

我们有一个 MSBuild 脚本，可以在构建之前生成所有需要的 AssemblyInfo.cs 文件。这样我也可以在程序集版本中使用 SVN 修订号。 AssemblyInfo.cs 文件不会检入 SVN（它们被忽略，以免打扰人们），而是在构建之前生成（无论是自动构建脚本还是来自 VS）。

我还提供了一个批处理文件来处理 AssemblyInfo.cs 文件的生成，这样开发人员就无需为细节而烦恼。

【讨论】：