.net AssemblyVersion、AssemblyFileVersion 和 AssemblyInformationalVersion 之间有什么区别？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/64602/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?
提问by Jakub ?turc
There are three assembly version attributes. What are differences? Is it ok if I use AssemblyVersionand ignore the rest?
有三个程序集版本属性。什么是差异？如果我使用AssemblyVersion并忽略其余部分可以吗？
MSDN says:
MSDN 说：
Specifies the version of the assembly being attributed.
Instructs a compiler to use a specific version number for the Win32 file version resource. The Win32 file version is not required to be the same as the assembly's version number.
Defines additional version information for an assembly manifest.
指定要归因的程序集的版本。
指示编译器使用 Win32 文件版本资源的特定版本号。Win32 文件版本不需要与程序集的版本号相同。
定义程序集清单的附加版本信息。
This is a follow-up to What are the best practices for using Assembly Attributes?
回答by Rémy van Duijkeren
AssemblyVersion
汇编版本
Where other assemblies that reference your assembly will look. If this number changes, other assemblies have to update their references to your assembly! Only update this version, if it breaks backward compatibility. The AssemblyVersionis required.
引用您的程序集的其他程序集将在哪里查看。如果这个数字发生变化，其他程序集必须更新它们对您的程序集的引用！仅更新此版本，如果它破坏了向后兼容性。将AssemblyVersion是必需的。
I use the format: major.minor. This would result in:
我使用格式：major.minor。这将导致：
[assembly: AssemblyVersion("1.0")]
If you're following SemVerstrictly then this means you only update when the majorchanges, so 1.0, 2.0, 3.0, etc.
如果您严格遵循SemVer，那么这意味着您仅在发生重大变化时才进行更新，例如1.0、2.0、3.0等。
AssemblyFileVersion
程序集文件版本
Used for deployment. You can increase this number for every deployment. It is used by setup programs. Use it to mark assemblies that have the same AssemblyVersion, but are generated from different builds.
用于部署。您可以为每次部署增加此数字。它由安装程序使用。使用它来标记具有相同AssemblyVersion，但从不同版本生成的程序集。
In Windows, it can be viewed in the file properties.
在 Windows 中，可以在文件属性中查看。
The AssemblyFileVersion is optional. If not given, the AssemblyVersion is used.
AssemblyFileVersion 是可选的。如果未给出，则使用 AssemblyVersion。
I use the format: major.minor.patch.build, where I follow SemVerfor the first three parts and use the buildnumber of the buildserver for the last part (0 for local build). This would result in:
我使用格式：major.minor.patch.build，前三个部分我遵循SemVer，最后一部分使用 buildserver 的 buildnumber（0 表示本地构建）。这将导致：
[assembly: AssemblyFileVersion("1.3.2.254")]
Be aware that System.Versionnames these parts as major.minor.build.revision!
请注意System.Version将这些部分命名为major.minor.build.revision!
AssemblyInformationalVersion
汇编信息版本
The Product version of the assembly. This is the version you would use when talking to customers or for display on your website. This version can be a string, like '1.0 Release Candidate'.
程序集的产品版本。这是您在与客户交谈或在您的网站上显示时使用的版本。这个版本可以是一个字符串，比如“ 1.0 Release Candidate”。
The AssemblyInformationalVersionis optional. If not given, the AssemblyFileVersion is used.
该AssemblyInformationalVersion是可选的。如果未给出，则使用 AssemblyFileVersion。
I use the format: major.minor[.patch] [revision as string]. This would result in:
我使用格式：major.minor[.patch] [revision as string]。这将导致：
[assembly: AssemblyInformationalVersion("1.0 RC1")]
回答by Daniel Fortunov
Versioning of assemblies in .NET can be a confusing prospect given that there are currently at least three ways to specify a version for your assembly.
鉴于目前至少有三种方法可以为您的程序集指定版本，因此 .NET 中程序集的版本控制可能是一个令人困惑的前景。
Here are the three main version-related assembly attributes:
以下是三个与版本相关的主要程序集属性：
// 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")]
By convention, the four parts of the version are referred to as the Major Version, Minor Version, Build, and Revision.
按照惯例，版本的四个部分被称为Major Version、Minor Version、Build和Revision。
The AssemblyFileVersionis intended to uniquely identify a build of the individual assembly
的AssemblyFileVersion是为了唯一地识别的构建个别组件
Typically you'll manually set the Major and Minor AssemblyFileVersion to reflect the version of the assembly, then increment the Build and/or Revision every time your build system compiles the assembly. The AssemblyFileVersion should allow you to uniquely identify a build of the assembly, so that you can use it as a starting point for debugging any problems.
通常，您将手动设置 Major 和 Minor AssemblyFileVersion 以反映程序集的版本，然后在每次构建系统编译程序集时增加 Build 和/或 Revision。AssemblyFileVersion 应该允许您唯一标识程序集的构建，以便您可以将其用作调试任何问题的起点。
On my current project we have the build server encode the changelist number from our source control repository into the Build and Revision parts of the AssemblyFileVersion. This allows us to map directly from an assembly to its source code, for any assembly generated by the build server (without having to use labels or branches in source control, or manually keeping any records of released versions).
在我当前的项目中，我们让构建服务器将源代码控制存储库中的更改列表编号编码到 AssemblyFileVersion 的构建和修订部分。这允许我们直接从程序集映射到其源代码，对于构建服务器生成的任何程序集（无需在源代码管理中使用标签或分支，或手动保留已发布版本的任何记录）。
This version number is stored in the Win32 version resource and can be seen when viewing the Windows Explorer property pages for the assembly.
此版本号存储在 Win32 版本资源中，可以在查看程序集的 Windows 资源管理器属性页时看到。
The CLR does not care about nor examine the AssemblyFileVersion.
CLR 不关心也不检查 AssemblyFileVersion。
The AssemblyInformationalVersionis intended to represent the version of your entire product
本AssemblyInformationalVersion是用来代表整个产品的版本
The AssemblyInformationalVersion is intended to allow coherent versioning of the entire product, which may consist of many assemblies that are independently versioned, perhaps with differing versioning policies, and potentially developed by disparate teams.
AssemblyInformationalVersion 旨在允许对整个产品进行一致的版本控制，该产品可能由许多独立版本控制的程序集组成，可能具有不同的版本控制策略，并且可能由不同的团队开发。
“For example, version 2.0 of a product might contain several assemblies; one of these assemblies is marked as version 1.0 since it's a new assembly that didn't ship in version 1.0 of the same product. Typically, you set the major and minor parts of this version number to represent the public version of your product. Then you increment the build and revision parts each time you package a complete product with all its assemblies.” — Jeffrey Richter, [CLR via C# (Second Edition)] p. 57
“例如，一个产品的 2.0 版可能包含多个程序集；其中一个程序集标记为 1.0 版，因为它是同一产品的 1.0 版中未提供的新程序集。通常，您设置此版本号的主要和次要部分来代表您的产品的公共版本。然后，每次将完整产品及其所有组件打包时，都会增加构建和修订部分。” — Jeffrey Richter，[CLR via C#（第二版）] p. 57
The CLR does not care about nor examine the AssemblyInformationalVersion.
CLR 不关心也不检查 AssemblyInformationalVersion。
The AssemblyVersionis the only version the CLR cares about (but it cares about the entire AssemblyVersion)
该AssemblyVersion是唯一的版本有关CLR的关心（但关心整个AssemblyVersion）
The AssemblyVersion is used by the CLR to bind to strongly named assemblies. It is stored in the AssemblyDef manifest metadata table of the built assembly, and in the AssemblyRef table of any assembly that references it.
CLR 使用 AssemblyVersion 绑定到强命名程序集。它存储在构建的程序集的 AssemblyDef 清单元数据表中，以及引用它的任何程序集的 AssemblyRef 表中。
This is very important, because it means that when you reference a strongly named assembly, you are tightly bound to a specific AssemblyVersion of that assembly. The entire AssemblyVersion must be an exact match for the binding to succeed. For example, if you reference version 1.0.0.0 of a strongly named assembly at build-time, but only version 1.0.0.1 of that assembly is available at runtime, binding will fail! (You will then have to work around this using Assembly Binding Redirection.)
这非常重要，因为这意味着当您引用强命名程序集时，您将与该程序集的特定 AssemblyVersion 紧密绑定。整个 AssemblyVersion 必须完全匹配才能成功绑定。例如，如果您在构建时引用了强命名程序集的 1.0.0.0 版，但在运行时只有该程序集的 1.0.0.1 版可用，则绑定将失败！（然后，您必须使用Assembly Binding Redirection解决此问题。）
Confusion over whether the entire AssemblyVersionhas to match. (Yes, it does.)
关于是否整个AssemblyVersion必须匹配的困惑。（是的，它确实。）
There is a little confusion around whether the entire AssemblyVersion has to be an exact match in order for an assembly to be loaded. Some people are under the false belief that only the Major and Minor parts of the AssemblyVersion have to match in order for binding to succeed. This is a sensible assumption, however it is ultimately incorrect (as of .NET 3.5), and it's trivial to verify this for your version of the CLR. Just execute this sample code.
对于整个 AssemblyVersion 是否必须完全匹配才能加载程序集，存在一些混淆。有些人错误地认为只有 AssemblyVersion 的 Major 和 Minor 部分必须匹配才能成功绑定。这是一个合理的假设，但它最终是不正确的（从 .NET 3.5 开始），并且为您的 CLR 版本验证这一点很简单。只需执行此示例代码。
On my machine the second assembly load fails, and the last two lines of the fusion log make it perfectly clear why:
在我的机器上，第二次组装加载失败，融合日志的最后两行清楚地说明了原因：
.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.
I think the source of this confusion is probably because Microsoft originally intended to be a little more lenient on this strict matching of the full AssemblyVersion, by matching only on the Major and Minor version parts:
我认为这种混乱的根源可能是因为 Microsoft 最初打算通过仅匹配 Major 和 Minor 版本部分来对完整 AssemblyVersion 的这种严格匹配更加宽容：
“When loading an assembly, the CLR will automatically find the latest installed servicing version that matches the major/minor version of the assembly being requested.” — Jeffrey Richter, [CLR via C# (Second Edition)] p. 56
“加载程序集时，CLR 将自动找到与所请求程序集的主要/次要版本相匹配的最新安装的服务版本。” — Jeffrey Richter，[CLR via C#（第二版）] p. 56
This was the behaviour in Beta 1 of the 1.0 CLR, however this feature was removed before the 1.0 release, and hasn't managed to re-surface in .NET 2.0:
这是 1.0 CLR 的 Beta 1 中的行为，但是此功能在 1.0 版本之前已被删除，并且尚未在 .NET 2.0 中重新出现：
“Note: I have just described how you should think of version numbers. Unfortunately, the CLR doesn't treat version numbers this way. [In .NET 2.0], the CLR treats a version number as an opaque value, and if an assembly depends on version 1.2.3.4 of another assembly, the CLR tries to load version 1.2.3.4 only (unless a binding redirection is in place). However, Microsoft has plans to change the CLR's loader in a future version so that it loads the latest build/revision for a given major/minor version of an assembly. For example, on a future version of the CLR, if the loader is trying to find version 1.2.3.4 of an assembly and version 1.2.5.0 exists, the loader with automatically pick up the latest servicing version. This will be a very welcome change to the CLR's loader — I for one can't wait.” — Jeffrey Richter, [CLR via C# (Second Edition)] p. 164 (Emphasis mine)
“注意：我刚刚描述了您应该如何看待版本号。不幸的是，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 via C#（第二版）] p. 164（强调我的）
As this change still hasn't been implemented, I think it's safe to assume that Microsoft had back-tracked on this intent, and it is perhaps too late to change this now. I tried to search around the web to find out what happened with these plans, but I couldn't find any answers. I still wanted to get to the bottom of it.
由于此更改仍未实施，我认为可以安全地假设 Microsoft 已经回溯了此意图，现在更改它可能为时已晚。我试图在网上搜索以了解这些计划发生了什么，但我找不到任何答案。我仍然想深入了解它。
So I emailed Jeff Richter and asked him directly — I figured if anyone knew what happened, it would be him.
所以我给 Jeff Richter 发了电子邮件，直接问他——我想如果有人知道发生了什么，那就是他。
He replied within 12 hours, on a Saturday morning no less, and clarified that the .NET 1.0 Beta 1 loader did implement this ‘automatic roll-forward' mechanism of picking up the latest available Build and Revision of an assembly, but this behaviour was reverted before .NET 1.0 shipped. It was later intended to revive this but it didn't make it in before the CLR 2.0 shipped. Then came Silverlight, which took priority for the CLR team, so this functionality got delayed further. In the meantime, most of the people who were around in the days of CLR 1.0 Beta 1 have since moved on, so it's unlikely that this will see the light of day, despite all the hard work that had already been put into it.
他在 12 小时内回复了，同样是在星期六早上，并澄清说 .NET 1.0 Beta 1 加载器确实实现了这种“自动前滚”机制，可以获取程序集的最新可用构建和修订版本，但这种行为是在 .NET 1.0 发布之前恢复。后来打算恢复它，但在 CLR 2.0 发布之前它没有实现。然后是 Silverlight，它优先考虑 CLR 团队，因此此功能进一步延迟。与此同时，在 CLR 1.0 Beta 1 时代的大多数人都已经离开了，所以尽管已经付出了所有的辛勤工作，但它不太可能看到曙光。
The current behaviour, it seems, is here to stay.
目前的行为似乎将继续存在。
It is also worth noting from my discussion with Jeff that AssemblyFileVersion was only added after the removal of the ‘automatic roll-forward' mechanism — because after 1.0 Beta 1, any change to the AssemblyVersion was a breaking change for your customers, there was then nowhere to safely store your build number. AssemblyFileVersion is that safe haven, since it's never automatically examined by the CLR. Maybe it's clearer that way, having two separate version numbers, with separate meanings, rather than trying to make that separation between the Major/Minor (breaking) and the Build/Revision (non-breaking) parts of the AssemblyVersion.
从我与 Jeff 的讨论中还值得注意的是，仅在删除“自动前滚”机制后才添加了 AssemblyFileVersion — 因为在 1.0 Beta 1 之后，对 AssemblyVersion 的任何更改对您的客户来说都是一个重大更改，然后无处可安全地存储您的内部版本号。AssemblyFileVersion 就是那个避风港，因为 CLR 永远不会自动检查它。也许这样更清楚，有两个独立的版本号，具有不同的含义，而不是试图在 AssemblyVersion 的主要/次要（破坏性）和构建/修订（非破坏性）部分之间进行分离。
The bottom line: Think carefully about when you change your AssemblyVersion
底线：仔细考虑何时改变你的 AssemblyVersion
The moral is that if you're shipping assemblies that other developers are going to be referencing, you need to be extremely careful about when you do (and don't) change the AssemblyVersion of those assemblies. Any changes to the AssemblyVersion will mean that application developers will either have to re-compile against the new version (to update those AssemblyRef entries) or use assembly binding redirects to manually override the binding.
寓意是，如果您要发布其他开发人员将要引用的程序集，则需要非常小心何时更改（和不更改）这些程序集的 AssemblyVersion。对 AssemblyVersion 的任何更改都意味着应用程序开发人员要么必须针对新版本重新编译（以更新那些 AssemblyRef 条目），要么使用程序集绑定重定向来手动覆盖绑定。
- Do notchange the AssemblyVersion for a servicing release which is intended to be backwards compatible.
- Dochange the AssemblyVersion for a release that you know has breaking changes.
- 不要更改旨在向后兼容的服务版本的 AssemblyVersion。
- 不要改变的AssemblyVersion的释放，你知道有重大更改。
Just take another look at the version attributes on mscorlib:
再看看 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")]
Note that it's the AssemblyFileVersion that contains all the interesting servicing information (it's the Revision part of this version that tells you what Service Pack you're on), meanwhile the AssemblyVersion is fixed at a boring old 2.0.0.0. Any change to the AssemblyVersion would force every .NET application referencing mscorlib.dll to re-compile against the new version!
请注意，它是包含所有有趣服务信息的 AssemblyFileVersion（它是该版本的 Revision 部分，它告诉您您使用的是哪个 Service Pack），同时 AssemblyVersion 被固定在一个无聊的旧 2.0.0.0。对 AssemblyVersion 的任何更改都会强制每个引用 mscorlib.dll 的 .NET 应用程序针对新版本重新编译！
回答by Bob King
AssemblyVersionpretty much stays internal to .NET, while AssemblyFileVersionis what Windows sees. If you go to the properties of an assembly sitting in a directory and switch to the version tab, the AssemblyFileVersionis what you'll see up top. If you sort files by version, this is what's used by Explorer.
AssemblyVersion几乎保留在 .NET 内部，而AssemblyFileVersionWindows则是这样。如果您转到位于目录中的程序集的属性并切换到版本选项卡，这AssemblyFileVersion就是您将在顶部看到的内容。如果按版本对文件进行排序，这就是资源管理器所使用的。
The AssemblyInformationalVersionmaps to the "Product Version" and is meant to be purely "human-used".
该AssemblyInformationalVersion映射到“产品版本”，其目的是纯粹“以人使用”。
AssemblyVersionis certainly the most important, but I wouldn't skip AssemblyFileVersion, either. If you don't provide AssemblyInformationalVersion, the compiler adds it for you by stripping off the "revision" piece of your version number and leaving the major.minor.build.
AssemblyVersion当然是最重要的，但我也不会跳过AssemblyFileVersion。如果您不提供AssemblyInformationalVersion，编译器会通过剥离版本号的“修订”部分并保留major.minor.build 来为您添加它。
回答by Scott Dorman
AssemblyInformationalVersionand AssemblyFileVersionare displayed when you view the "Version" information on a file through Windows Explorer by viewing the file properties. These attributes actually get compiled in to a VERSION_INFOresource that is created by the compiler.
AssemblyInformationalVersionAssemblyFileVersion当您通过 Windows 资源管理器查看文件属性查看文件的“版本”信息时，会显示和。这些属性实际上被编译成VERSION_INFO由编译器创建的资源。
AssemblyInformationalVersionis the "Product version" value. AssemblyFileVersionis the "File version" value.
AssemblyInformationalVersion是“产品版本”值。AssemblyFileVersion是“文件版本”值。
The AssemblyVersionis specific to .NET assemblies and is used by the .NET assembly loader to know which version of an assembly to load/bind at runtime.
这AssemblyVersion是特定于 .NET 程序集的，由 .NET 程序集加载器用于了解在运行时加载/绑定哪个版本的程序集。
Out of these, the only one that is absolutely required by .NET is the AssemblyVersionattribute. Unfortunately it can also cause the most problems when it changes indiscriminately, especially if you are strong naming your assemblies.
其中，.NET 唯一绝对需要的是AssemblyVersion属性。不幸的是，当它不加选择地更改时，它也可能导致最多的问题，尤其是当您对程序集进行强命名时。
回答by KCD
To keep this question current it is worth highlighting that AssemblyInformationalVersionis used by NuGet and reflects the package versionincluding any pre-release suffix.
为了使这个问题保持最新，值得强调的AssemblyInformationalVersion是 NuGet 使用并反映包括任何预发布后缀在内的包版本。
For example an AssemblyVersion of 1.0.3.* packaged with the asp.net core dotnet-cli
例如 1.0.3.* 的 AssemblyVersion 与 asp.net 核心 dotnet-cli 打包在一起
dotnet pack --version-suffix ci-7 src/MyProject
Produces a package with version 1.0.3-ci-7 which you can inspect with reflection using:
生成一个版本为 1.0.3-ci-7 的包，您可以使用反射检查它：
CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);
回答by DavidM
It's worth noting some other things:
值得注意的是其他一些事情：
1) As shown in Windows Explorer Properties dialog for the generated assembly file, there are two places called "File version". The one seen in the header of the dialog shows the AssemblyVersion, not the AssemblyFileVersion.
1) 如生成的程序集文件的 Windows 资源管理器属性对话框中所示，有两个地方称为“文件版本”。在对话框的标题中看到的那个显示的是 AssemblyVersion，而不是 AssemblyFileVersion。
In the Other version information section, there is another element called "File Version". This is where you can see what was entered as the AssemblyFileVersion.
在其他版本信息部分，还有一个称为“文件版本”的元素。您可以在此处查看作为 AssemblyFileVersion 输入的内容。
2) AssemblyFileVersion is just plain text. It doesn't have to conform to the numbering scheme restrictions that AssemblyVersion does (<build> < 65K, e.g.). It can be 3.2.<release tag text>.<datetime>, if you like. Your build system will have to fill in the tokens.
2) AssemblyFileVersion 只是纯文本。它不必符合 AssemblyVersion 所做的编号方案限制（例如，<build> < 65K）。如果您愿意，它可以是 3.2.<release tag text>.<datetime>。您的构建系统必须填写令牌。
Moreover, it is not subject to the wildcard replacement that AssemblyVersion is. If you just have a value of "3.0.1.*" in the AssemblyInfo.cs, that is exactly what will show in the Other version information->File Version element.
此外，它不受 AssemblyVersion 的通配符替换的影响。如果您在 AssemblyInfo.cs 中只有“3.0.1.*”值，这正是将在其他版本信息->文件版本元素中显示的内容。
3) I don't know the impact upon an installer of using something other than numeric file version numbers, though.
3) 不过，我不知道使用数字文件版本号以外的其他内容对安装程序的影响。
回答by linquize
When a assembly' s AssemblyVersion is changed, If it has strong name, the referencing assemblies need to be recompiled, otherwise the assembly does not load! If it does not have strong name, if not explicitly added to project file, it will not be copied to output directory when build so you may miss depending assemblies, especially after cleaning the output directory.
当程序集的 AssemblyVersion 更改时，如果它具有强名称，则需要重新编译引用程序集，否则程序集不会加载！如果它没有强名称，如果没有明确添加到项目文件中，则构建时不会将其复制到输出目录，因此您可能会错过依赖的程序集，尤其是在清理输出目录之后。
