我有以下情况: 应用程序是通过IDE和构建脚本构建的。构建脚本用于初始设置(获取依赖项,设置环境),生成二进制文件以及持续集成过程。 我希望二进制文件具有AssemblyFileVersion作为构建的月和日,以及修订版的svn修订版。这会导致AssemblyInfo.cs在每个修订版本上更改,这会在源代码管理日志中产生大量噪音。我可以忽略这些文件,但是作为设置的一部分,我需要重新生成这些文件。
我想知道是否有人有任何其他想法,或者你在这种情况下做了什么。
答案 0 :(得分:6)
现在我已经找到了安迪怀特回答的解决方案:
缺点:
答案 1 :(得分:5)
我认为AssemblyInfo.cs的一个常见做法是在构建过程中动态生成它,而不是保留静态文件。
通过生成,您可以使用任何您想要的任意/可配置设置。
我相信NAnt为此目的有<asminfo>
任务。我猜测MSBuild也有类似的东西。或者您可以编写自定义文件生成脚本并使用它将自定义AssemblyInfo.cs推送到您的构建中。
答案 2 :(得分:1)
我们只在RTM / RTW / GA /(Whatever :)发布版本之后在主干上更新AssemblyInfo。
我们的Nightly / Beta / RC / QA /(Whatever :)构建只需将已更新的AssemblyInfo.cs(来自CI服务器上的工作副本)的副本添加到相应的分支或标记中。我们使用Subversion,您可以使用未提交的更改在工作副本上进行分支/标记。
这允许我们在分支或标记中为Nightly / Beta版本保留正确版本的AssemblyInfo,并且在最终版本发布后仅触发trunk中的AssemblyInfo。构建服务器有一个开关,告诉它在这种类型的构建中将其提交给trunk。
FWIW,我们从MSBuild脚本驱动它,使用为每个项目类型设置的属性的不同值,从我们的构建服务器(CruiseControl.NET)传递。
[编辑]另请注意,开发人员的AssemblyInfo版本未更新(除非他们手动更改),因此他们不会在每次构建时获得修改后的AssemblyInfo的噪音。我们让开发人员控制 Major.Minor ,构建服务器控制 Build ,我们将Revision for QA链接到他们自己的系统(因为它无论如何被WiX / MSI忽略)
答案 3 :(得分:0)
如果你没有检查更改的AssemblyInfo.cs回到源代码管理中,那为什么会有噪音呢?
我建议对整个构建使用单个值的AssemblyFileVersion,并且您要么签入包含该版本的单个文件,和/或使用版本号标记构建。这样,您就不会觉得需要签入多个修改过的AssemblyInfo.cs文件。
答案 4 :(得分:0)
我们还使用生成步骤来创建AssemblyInfo。[cs | vb]文件,虽然我们只是使用该文件的模板副本作为源,然后使用一个小的Perl脚本来解析该模板,替换版本字符串,并生成最终输出。
这个系统的问题是VB项目似乎不断加载AssemblyInfo文件,这意味着项目在第一次加载时会出错,甚至在PreBuild步骤可以运行以创建AssemblyInfo.vb文件之前。我们还没有找到解决这个问题的方法 - 如果有人有洞察力,我很乐意听到它......