我只是想知道如何使用Visual Studio(2005)自动增加文件的构建(和版本?)
如果我查找C:\Windows\notepad.exe的属性，版本选项卡给出“文件版本:5.1.2600.2180”。我想在我的dll的版本中也得到这些很酷的数字，而不是版本1.0.0.0，让我们面对它有点沉闷。
我尝试了一些东西，但它似乎没有开箱即用的功能，或者可能我只是在错误的地方(像往常一样)。
我主要工作与网络项目....
我看了两个:
http://www.codeproject.com/KB/dotnet/Auto_Increment_Version.aspx http://www.codeproject.com/KB/dotnet/build_versioning.aspx
我不敢相信花这么大力气做一件事是标准做法。
编辑: 据我所知，它在VS2005中不工作(http://www.codeproject.com/KB/dotnet/AutoIncrementVersion.aspx)
当前回答
如何获取版本{major}.{year}.1{date}.1{time}
这个有点实验性，但我喜欢。灵感来自Jeff Atwood @ CodingHorror(链接)。
结果的版本号变成1.2016.10709.11641(意思是2016-07-09 16:41)，这允许
可怜的男人零填充(愚蠢的前导1) 嵌入到版本号中的近乎人类可读的本地DateTime 对于真正重大的突破性更改，不要使用Major版本。
在项目中添加一个新项，选择General -> Text Template，将其命名为CustomVersionNumber，并(如果适用)在Properties/AssemblyInfo.cs中注释出AssemblyVersion和AssemblyFileVersion。
然后，在保存该文件或构建项目时，这将重新生成一个.cs文件，该文件位于已创建的.tt文件下的子项。
<#@ template language="C#" #>
<#@ assembly name="System.Core" #>
<#@ import namespace="System.Linq" #>
//
// This code was generated by a tool. Any changes made manually will be lost
// the next time this code is regenerated.
//
using System.Reflection;
<#
var date = DateTime.Now;
int major = 1;
int minor = date.Year;
int build = 10000 + int.Parse(date.ToString("MMdd"));
int revision = 10000 + int.Parse(date.ToString("HHmm"));
#>
[assembly: AssemblyVersion("<#= $"{major}.{minor}.{build}.{revision}" #>")]
[assembly: AssemblyFileVersion("<#= $"{major}.{minor}.{build}.{revision}" #>")]
其他回答
我用Visual Studio 2019尝试了这一点，但它不起作用。 在较新的VS版本中，至少确定性标志阻止了自动更新。但是改变了第14行 您的项目名。csproj到<Deterministic>false</Deterministic> . csproj到<Deterministic>false</Deterministic> . csproj到 并将版本号字符串更改为“1.0”。*”并没有帮到我。
所以我做了一个小vbs脚本来完成这项工作。 它将版本号更改为(主要版本)。(小版本)。[一][dayofyear])。(增量)。
将脚本复制到一个文件夹中，并将以下内容放入pre-compile build-commandline:
"Path-to-this-script\UpdateVersion.vbs" "$(ProjectDir)"
(包括报价和填写您机器的真实路径) 和你完成了。
在这里获取: https://github.com/abtzero/VS_UpdateVersion.git
如何获取版本{major}.{year}.1{date}.1{time}
这个有点实验性，但我喜欢。灵感来自Jeff Atwood @ CodingHorror(链接)。
结果的版本号变成1.2016.10709.11641(意思是2016-07-09 16:41)，这允许
可怜的男人零填充(愚蠢的前导1) 嵌入到版本号中的近乎人类可读的本地DateTime 对于真正重大的突破性更改，不要使用Major版本。
在项目中添加一个新项，选择General -> Text Template，将其命名为CustomVersionNumber，并(如果适用)在Properties/AssemblyInfo.cs中注释出AssemblyVersion和AssemblyFileVersion。
然后，在保存该文件或构建项目时，这将重新生成一个.cs文件，该文件位于已创建的.tt文件下的子项。
<#@ template language="C#" #>
<#@ assembly name="System.Core" #>
<#@ import namespace="System.Linq" #>
//
// This code was generated by a tool. Any changes made manually will be lost
// the next time this code is regenerated.
//
using System.Reflection;
<#
var date = DateTime.Now;
int major = 1;
int minor = date.Year;
int build = 10000 + int.Parse(date.ToString("MMdd"));
int revision = 10000 + int.Parse(date.ToString("HHmm"));
#>
[assembly: AssemblyVersion("<#= $"{major}.{minor}.{build}.{revision}" #>")]
[assembly: AssemblyFileVersion("<#= $"{major}.{minor}.{build}.{revision}" #>")]
将递增(DateTime)信息放入AssemblyFileVersion属性，该属性的优点是不破坏任何依赖关系。
基于Boog的解决方案(不适合我，也许是因为VS2008?)，你可以结合使用一个预构建事件生成一个文件，添加该文件(包括其版本属性)，然后使用一种方法再次读取这些值。这是. .
Pre-Build-Event:
echo [assembly:System.Reflection.AssemblyFileVersion("%date:~-4,4%.%date:~-7,2%%date:~-10,2%.%time:~0,2%%time:~3,2%.%time:~-5,2%")] > $(ProjectDir)Properties\VersionInfo.cs
将生成的VersionInfo.cs文件(Properties子文件夹)包含到项目中
返回日期(年到秒)的代码:
var version = assembly.GetName().Version;
var fileVersionString = System.Diagnostics.FileVersionInfo.GetVersionInfo(assembly.Location).FileVersion;
Version fileVersion = new Version(fileVersionString);
var buildDateTime = new DateTime(fileVersion.Major, fileVersion.Minor/100, fileVersion.Minor%100, fileVersion.Build/100, fileVersion.Build%100, fileVersion.Revision);
不太舒服…此外，我不知道它是否会创建大量的强制重建(因为文件总是在变化)。
例如，如果每隔几分钟/小时才更新VersionInfo.cs文件(通过使用临时文件，然后在检测到足够大的更改时复制/覆盖真正的VersionInfo.cs)，您可以使其更加智能。我曾经非常成功地做到过。
每次构建时，它都会自动增加最低有效位数。
我不知道如何更新其他的，但你至少应该已经看到了……
如其他文章所述，在AssemblyInfo中的版本号中或在项目属性下设置*并不适用于所有版本的Visual Studio / . net。
Afaik，它在2005年的比赛中不起作用(但在2003年和2008年的比赛中不起作用)。对于VS 2005，你可以使用以下方法:在编译时自动增加Visual Studio 2005版本的构建和修订号。
But be aware that changing the version number automatically is not recommended for strong-named assemblies. The reason is that all references to such an assembly must be updated each time the referenced assembly is rebuilt due to the fact that strong-named assembly references are always a reference to a specific assembly version. Microsoft themselves change the version number of the .NET Framework assemblies only if there are changes in interfaces. (NB: I'm still searching for the link in MSDN where I read that.)
