AssemblyVersion,AssemblyFileVersion和AssemblyInformationalVersion之间有什么区别？

有三个程序集版本属性.有什么区别？如果我使用AssemblyVersion并忽略其余部分可以吗？

---

MSDN说:

AssemblyVersion:

指定要归属的程序集的版本.

AssemblyFileVersion:

指示编译器使用Win32文件版本资源的特定版本号.Win32文件版本不需要与程序集的版本号相同.

AssemblyInformationalVersion:

定义程序集清单的其他版本信息.

---

这是使用装配属性的最佳做法的后续行动？

1> Rémy van Dui..：

---

的AssemblyVersion

引用装配的其他装配体的外观.如果此数字更改,其他程序集必须更新其对程序集的引用!这AssemblyVersion是必需的.

我使用的格式为:major.minor.这将导致:

[assembly: AssemblyVersion("1.0")]

的AssemblyFileVersion

用于部署.您可以为每个部署增加此数量.它由安装程序使用.使用它来标记具有相同AssemblyVersion但由不同构建生成的程序集.

在Windows中,可以在文件属性中查看它.

如果可能,让它由MSBuild生成.AssemblyFileVersion是可选的.如果没有给出,则使用AssemblyVersion.

我使用的格式为:major.minor.revision.build,其中我使用修订版进行开发阶段(Alpha,Beta,RC和RTM),服务包和热修复.这将导致:

[assembly: AssemblyFileVersion("1.0.3100.1242")]

AssemblyInformationalVersion

装配的产品版本.这是您与客户交谈或在您的网站上显示时使用的版本.这个版本可以是一个字符串,比如' 1.0 Release Candidate '.

代码分析会抱怨它(CA2243) - 向微软报告(未在VS2013中修复).

这AssemblyInformationalVersion是可选的.如果没有给出,则使用AssemblyFileVersion.

我使用格式:major.minor [revision as string].这将导致:

[assembly: AssemblyInformationalVersion("1.0 RC1")]

---

不幸的是[Version Class](http://msdn.microsoft.com/en-us/library/system.version.aspx)定义了`major.minor [.build [.revision]]`而不是`major.minor. revision.build`所以在给定的答案中,如果您使用类属性或`System.Reflection.Assembly.GetExecutingAssembly().GetName().Version`来检测构建和修订号,那么构建和修订号将被交换.

---

@thinkOfaNumber您对版本类的权利,但这是Microsoft的版本控制方式.我个人认为最后没有构建数字是很奇怪的,这就是为什么我只把我的格式作为一个例子,基于[语义版本](http://semver.org/spec/v2.0.0.html).您可以自由地使用Microsoft方式或您自己的方式.

---

应该注意,对于`AssemblyInformationalVersion`,如果省略,则使用`AssemblyFileVersion`.**然后**`AssemblyVersion`如果两个都省略.

---

对于AssemblyFileVersion,"如果可能,让它由MSBuild生成" - 为什么？你刚才解释了手动控制它的一个很好的理由:)

---

今天(2013年5月21日)VS2010中仍然存在AssemblyInformationalVersion格式的警告,并且您的链接已经死亡.

---

@RémyvanDuijkeren我同意,我也喜欢使用语义版本控制,但很难与定义的`Version`类混合,除非你不使用微软的定义,你的程序集的其他用户可能会期望.[备注](http://msdn.microsoft.com/en-us/library/system.version(v = vs.110).aspx)sate"构建号的差异代表同一来源的重新编译. "

---

Visual Studio在其引用属性中显示两个版本:Version和RuntimeVersion.这与这里列出的版本有什么关系？是否自动插入RuntimeVersion？

2> Daniel Fortu..：

---

在.NET中对程序集进行版本控制可能是一个令人困惑的前景,因为目前至少有三种方法可以为程序集指定版本.

以下是三个与主要版本相关的程序集属性:

// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]

按照惯例,版本的四个部分称为主要版本,次要版本,构建和修订.

的AssemblyFileVersion是为了唯一地识别的构建个别组件

通常,您将手动设置Major和Minor AssemblyFileVersion以反映程序集的版本,然后在每次构建系统编译程序集时增加Build和/或Revision.AssemblyFileVersion应该允许您唯一地标识程序集的构建,以便您可以将其用作调试任何问题的起点.

在我当前的项目中,我们让构建服务器将源代码控制存储库中的变更列表编号编码为AssemblyFileVersion的Build和Revision部分.这允许我们直接从程序集映射到其源代码,用于构建服务器生成的任何程序集(无需在源代码管理中使用标签或分支,或手动保留已发布版本的任何记录).

此版本号存储在Win32版本资源中,在查看程序集的Windows资源管理器属性页时可以看到.

CLR不关心也不检查AssemblyFileVersion.

本AssemblyInformationalVersion是用来代表整个产品的版本

AssemblyInformationalVersion旨在允许整个产品的一致版本控制,其可能包含许多独立版本的程序集,可能具有不同的版本控制策略,并且可能由不同的团队开发.

"例如,产品的2.0版本可能包含多个程序集; 其中一个程序集标记为1.0版,因为它是一个新的程序集,并未在同一产品的1.0版本中发布.通常,您可以设置此版本号的主要部分和次要部分,以表示产品的公共版本.然后,每次打包完整产品及其所有组件时,都会增加构建和修订部分." - Jeffrey Richter,[CLR通过C#(第二版)] p.57

CLR不关心也不检查AssemblyInformationalVersion.

这AssemblyVersion是CLR唯一关心的版本(但它关心整个版本AssemblyVersion)

CLR使用AssemblyVersion绑定到强名称程序集.它存储在构建程序集的AssemblyDef清单元数据表中,并存储在引用它的任何程序集的AssemblyRef表中.

这非常重要,因为这意味着当您引用强名称程序集时,您将紧密绑定到该程序集的特定AssemblyVersion.整个AssemblyVersion必须与绑定成功完全匹配.例如,如果在构建时引用强名称程序集的1.0.0.0版本,但只有该程序集的1.0.0.1版本在运行时可用,则绑定将失败!(然后,您必须使用程序集绑定重定向来解决此问题.)

关于整个AssemblyVersion是否必须匹配的困惑.(是的,它确实.)

围绕整个AssemblyVersion是否必须完全匹配以便加载程序集存在一些混淆.有些人错误地认为只有大会版本的主要部分和次要部分必须匹配才能使约束成功.这是一个明智的假设,但它最终是不正确的(从.NET 3.5开始),并且为您的CLR版本验证这一点很简单.只需执行此示例代码即可.

在我的机器上,第二个程序集加载失败,并且融合日志的最后两行使得它非常清楚原因:

.NET Framework Version: 2.0.50727.3521
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
Successfully loaded assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
Assembly binding for  failed:
System.IO.FileLoadException: Could not load file or assembly 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, 
PublicKeyToken=0b3305902db7183f' or one of its dependencies. The located assembly's manifest definition 
does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f'

=== Pre-bind state information ===
LOG: User = Phoenix\Dani
LOG: DisplayName = Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
 (Fully-specified)
LOG: Appbase = [...]
LOG: Initial PrivatePath = NULL
Calling assembly : AssemblyBinding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
LOG: Attempting download of new URL [...].
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

我认为这种混淆的根源可能是因为微软原本打算对完整AssemblyVersion的这种严格匹配稍微宽松一点,只匹配Major和Minor版本部分:

"当加载程序集时,CLR将自动找到与所请求程序集的主要/次要版本匹配的最新安装服务版本." - Jeffrey Richter,[CLR通过C#(第二版)] p.56

这是1.0 CLR的Beta 1中的行为,但是此功能在1.0版本之前被删除,并且未能在.NET 2.0中重新浮出水面:

"注意:我刚刚描述了你应该如何看待版本号.不幸的是,CLR不会以这种方式处理版本号.[在.NET 2.0中],CLR将版本号视为不透明值,如果程序集依赖于另一个程序集的1.2.3.4版,则CLR仅尝试加载版本1.2.3.4(除非绑定重定向已到位) ).但是, Microsoft计划在未来版本中更改CLR的加载程序,以便为给定的主要/次要版本的程序集加载最新的构建/修订版本.例如,在CLR的未来版本上,如果加载程序试图找到程序集的版本1.2.3.4并且版本1.2.5.0存在,则加载程序会自动获取最新的服务版本.这对CLR的装载机来说是一个非常受欢迎的改变 - 我不能等待." - Jeffrey Richter,[CLR来自C#(第二版)] p.164(强调我的)

由于这一变化仍未实施,我认为可以安全地假设微软已经对此意图进行了回溯,现在改变这一点可能为时已晚.我试图在网上搜索以了解这些计划发生了什么,但我找不到任何答案.我仍然想深究它.

所以我给Jeff Richter发了电子邮件并直接问他 - 我想如果有人知道发生了什么事,那就是他.

他在一个星期六的早上12小时内回复,并澄清说.NET 1.0 Beta 1加载器确实实现了这种"自动前滚"机制,可以获取最新的可用构建版本和修订版本,但这种行为是在.NET 1.0发布之前恢复.它后来打算恢复它,但它没有在CLR 2.0发布之前完成.然后是Silverlight,它优先考虑了CLR团队,所以这个功能进一步推迟了.与此同时,CLR 1.0 Beta 1时代的大多数人都已经离开了,所以尽管已经付出了很多艰苦的努力,但这不太可能见到白昼.

目前的行为似乎仍然存在.

我与Jeff的讨论也值得注意,只有在删除'自动前滚'机制后才添加AssemblyFileVersion - 因为在1.0 Beta 1之后,对AssemblyVersion的任何更改都是对客户的一次重大改变,那时候无处安全存储您的内部版本号.AssemblyFileVersion是安全的避风港,因为它永远不会被CLR自动检查.也许它更清楚,有两个单独的版本号,具有不同的含义,而不是试图在AssemblyVersion的Major/Minor(破坏)和Build/Revision(非破坏)部分之间进行分离.

底线:仔细想想你何时改变你的想法 AssemblyVersion

道德观点是,如果您正在运送其他开发人员将要引用的程序集,则需要非常小心何时(并且不)更改这些程序集的AssemblyVersion.对AssemblyVersion的任何更改都意味着应用程序开发人员要么必须针对新版本重新编译(更新那些AssemblyRef条目),要么使用程序集绑定重定向来手动覆盖绑定.

请勿更改用于向后兼容的服务版本的AssemblyVersion.

不要改变的AssemblyVersion的,你知道的断裂变化的释放.

再看看mscorlib上的版本属性:

// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]

请注意,它是AssemblyFileVersion,其中包含所有有趣的服务信息(它是此版本的Revision部分,告诉您正在使用的Service Pack),同时AssemblyVersion已修复为无聊的旧版2.0.0.0.对AssemblyVersion的任何更改都会强制引用mscorlib.dll的每个.NET应用程序针对新版本重新编译!

---

很好的答案.我认为你提出的最重要的一点 - 以及MS应该明确推荐的 - 是对AssemblyVersion进行更改**当且仅当**新版本破坏向后兼容性时.

3> Bob King..：

---

AssemblyVersion几乎保持.NET的内部,而AssemblyFileVersionWindows是看到的.如果您转到位于目录中的程序集的属性并切换到版本选项卡,AssemblyFileVersion那么您将看到顶部的内容.如果按版本对文件进行排序,则这就是Explorer使用的内容.

在AssemblyInformationalVersion"产品版本"和地图,就是要纯粹"以人使用".

AssemblyVersion当然是最重要的,但我也不会跳过AssemblyFileVersion.如果您不提供AssemblyInformationalVersion,编译器会通过剥离版本号的"revision"部分并离开major.minor.build来为您添加它.

4> Scott Dorman..：

---

AssemblyInformationalVersion而AssemblyFileVersion当你通过查看文件属性查看通过Windows资源管理器文件中的"版本"的信息被显示.这些属性实际上被编译到VERSION_INFO由编译器创建的资源中.

AssemblyInformationalVersion是"产品版本"值.AssemblyFileVersion是"文件版本"值.

的AssemblyVersion是特定于.NET组件,并且用于由.NET组件装载器知道在运行时加载/与之结合的组件的版本.

其中,.NET唯一需要的是AssemblyVersion属性.不幸的是,当它不加选择地改变时,它也会导致大多数问题,特别是如果你强烈命名你的程序集.

5> KCD..：

---

为了使这个问题保持最新,值得强调的AssemblyInformationalVersion是NuGet使用它并反映包版本,包括任何预发布后缀.

例如,使用asp.net core dotnet-cli打包的1.0.3.*的AssemblyVersion

dotnet pack --version-suffix ci-7 src/MyProject

生成1.0.3-ci-7版本的软件包,您可以使用以下方法进行反射检查:

CustomAttributeExtensions.GetCustomAttribute(asm);

6> 小智..：

---

值得注意的是其他一些事情:

1)如生成的程序集文件的Windows资源管理器属性对话框中所示,有两个名为"文件版本"的位置.在对话框的标题中看到的那个显示AssemblyVersion,而不是AssemblyFileVersion.

在"其他版本信息"部分中,还有另一个名为"文件版本"的元素.您可以在此处查看作为AssemblyFileVersion输入的内容.

2)AssemblyFileVersion只是纯文本.它不必符合AssemblyVersion所做的编号方案限制( <65K,例如).它可以是3.2..,如果你愿意的话.您的构建系统必须填写令牌.

而且,它不受AssemblyVersion的通配符替换.如果您在AssemblyInfo.cs中只有一个值"3.0.1.*",那么这正是将在其他版本信息 - >文件版本元素中显示的内容.

3)我不知道安装程序使用除数字文件版本号之外的其他东西的影响.