此外,还有关于 "AssemblyInformationalVersion" 属性的问题?
我找到了这篇支持 Microsoft 知识库(KB)文章,提供一些帮助: 如何使用程序集版本和程序集文件版本。
[assembly: AssemblyVersion(Foo.StaticVersion.Bar)]
我有一个项目,只有一个文件声明了这个字符串:
namespace Foo
{
public static class StaticVersion
{
public const string Bar= "3.0.216.0"; // 08/01/2008 17:28:35
}
}
我的自动化构建过程仅通过从数据库中获取最新版本并递增倒数第二个数字来更改该字符串。
仅当功能集发生重大更改时,我才更改主要构建号。
我根本不更改文件版本。
该 KB 文章提到了最重要的区别:文件版本仅用于显示目的,而程序集版本在 .NET 加载行为中发挥着重要作用。
如果更改程序集版本号,则程序集的标识已经发生了变化。开发人员需要重新构建以引用您的新版本(除非您设置了一些自动版本控制“策略”),并且在运行时,只有与版本号匹配的程序集才会被加载。
在我的环境中,这很重要,因为我们需要一个正在增加的、高度可见的版本号,以进行审计,但我们不想强制开发人员重新构建或在生产中拥有多个版本。对于向后兼容的小改变,我们更新文件版本而不是程序集版本。
文件版本仅用于显示目的,而程序集版本在.NET加载行为中扮演重要角色。
不完全正确。 当您在先前版本上升级现有版本时,文件版本对于Windows Installer也很重要。
我的当前应用程序中,每个VS项目都有指向“AssemblyBuildInfo”源文件的链接,该文件具有以下属性:
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyCompany("Acme Corporationy")]
[assembly: AssemblyCopyright("Copyright © 2009 Acme Corporation")]
这种方式,我的解决方案中的所有程序集都共享相同的版本和公司信息(这意味着如果我必须更改它,我仅更改一次)。通过排除文件版本(即FileVersion),它会自动设置为程序集版本(即AssemblyVersion)。
@Adam:你每次构建时都更改文件版本吗?你是否使用版本控制(SYN或VSS)并使用该信息将源代码链接回二进制文件?
似乎让程序集版本保持不变是有道理的,即“2.0.0.0”。这对应于产品的部署。
文件版本更改以匹配来自源代码控制的修订版本。“2.0.?? .revision”这将提供从特定dll(或exe)到构建它的源代码的链接。
我保持它们不变。但是,我没有多文件程序集,这时 AssemblyVersion 号码就变得很重要了。我使用微软风格的日期编码来表示我的构建号,而不是自动递增(我不认为某个东西被构建的次数非常重要)。