Should AssemblyInfo.cs be placed in version control?

拥有回忆 提交于 2019-12-02 17:36:24

Either don't version AssemblyInfo.cs at all, or put "developer version" of them into the repository and have CruiseControl.Net svn-revert them after build (I do the later so that builds made on developers workstations are easily extinguishable from the "official" ones downloaded from CruiseControl.Net).

As for reproducing the same build labels later - you already have to do the rebuild by calling MSBuild / NAnt by hand, simply pass to it CCNetLabel set to appropriate value and you'll get the same assembly versions generated as with the build invoked from CruiseControl.Net (MSBuild: /p:CCNetLabel=1.4.2.333 , NAnt: -D:CCNetLabel=1.4.2.333).

I use a CommonAssemblyInfo.cs file which I add a link to in every project.

The only attribute I have in this file is AssemblyFileVersion and have CC.Net / Msbuild update the version every build.

Make sure any project that includes CommonAssemblyInfo.cs doesn't have duplicate attributes in AssemblyInfo.cs.

If you check out the CC.Net source code you'll see that is how they have they're build configured.

I always have it checked in. In fact I believe this is the default behavior with Team System Source Control.

We have a MSBuild script that generates all the needed AssemblyInfo.cs files prior to the build. This way I can also use the SVN revision number in the assembly versions. The AssemblyInfo.cs files are not checked into SVN (they're ignored so that they don't bother people) but generated prior to building (doesn't matter whether it an automated build script or from VS).

I also supply a batch file to take care of the AssemblyInfo.cs files generation so that the developers don't need to bother with the details.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!