C# .NET：AssemblyVersionAttribute 中的大修订号
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1188284/
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
.NET: Large revision numbers in AssemblyVersionAttribute
提问by Rasmus Faber
We have the convention of versioning our builds as [major].[minor].[micro].[revision], e.g. 2.1.2.33546.
我们有将我们的构建版本化为 [major].[minor].[micro].[revision] 的惯例，例如 2.1.2.33546。
Our build-script automatically updates an AssemblyInfo.cs file containing
我们的构建脚本会自动更新一个 AssemblyInfo.cs 文件，其中包含
[assembly: AssemblyVersion("x.y.z.w")]
in order to embed the version-number in the assembly.
为了在程序集中嵌入版本号。
But our Subversion-repository just reached revision #65535, which broke our build.
但是我们的 Subversion-repository 刚刚达到修订版 #65535，这破坏了我们的构建。
It turns out that each number in the version-number has a maximum value of 65534 (probably due to a Windows-restriction).
事实证明，版本号中的每个数字的最大值为 65534（可能是由于 Windows 限制）。
Have you encountered this problem? Any good solutions/workarounds?
你遇到过这个问题吗？任何好的解决方案/解决方法？
We like the scheme of embedding the revision-number and we obviously can't just reset our Subversion-server :-)
我们喜欢嵌入修订号的方案，我们显然不能只是重置我们的 Subversion-server :-)
采纳答案by Michael Stum
A bit more Background information:
更多背景信息：
Why are build numbers limited to 65535?
As this is unlikely to get changed, your options are:
由于这不太可能改变，您的选择是：
- Take the Revision Modulo 65535, which means you are back to 1
- Use the Micro-Field in your version number to split the version number by dividing the revision by 1000. That means your version could be 1.0.65.535
- Do not store the SVN Revision in the AssemblyVersion, but instead in the AssemblyInformationalVersion. That way your Application can still access it for display purposes, although you can't use Windows Explorer anymore to quickly check the SVN Revision
- Do not store the SVN Revision in the AssemblyVersion, but instead in the AssemblyProduct or AssemblyDescription fields. Again, that way your Application can still access it, but also Explorer will now show it in the Property Sheet.
- 以 Revision Modulo 65535 为例，这意味着您又回到了 1
- 使用版本号中的 Micro-Field 通过将修订版除以 1000 来拆分版本号。这意味着您的版本可能是 1.0.65.535
- 不要将 SVN 修订版存储在 AssemblyVersion 中，而是存储在AssemblyInformationalVersion 中。这样您的应用程序仍然可以出于显示目的访问它，尽管您不能再使用 Windows 资源管理器来快速检查 SVN 修订版
- 不要将 SVN 修订版存储在 AssemblyVersion 中，而是存储在 AssemblyProduct 或 AssemblyDescription 字段中。同样，这样您的应用程序仍然可以访问它，而且资源管理器现在将在属性表中显示它。
回答by Marc Gravell
One option might be to just use the [AssemblyFileVersion]; this still raises a warning, but it'll build, at least:
一种选择可能是只使用[AssemblyFileVersion]; 这仍然会引发警告，但至少会构建：
[assembly: AssemblyFileVersion("1.0.0.80000")]
回答by OregonGhost
According to MSDN, the components of the AssemblyVersionAttribute version number are limited to UInt16.MaxValue - 1by the assembly meta data, i.e. you can't store larger numbers in an assembly file. The file version, as Marc Gravell suggests, might be enough for you, depending on who will read your version number.
根据 MSDN，AssemblyVersionAttribute 版本号UInt16.MaxValue - 1的组件受程序集元数据的限制，即您不能在程序集文件中存储更大的数字。正如 Marc Gravell 所建议的，文件版本对您来说可能就足够了，这取决于谁会阅读您的版本号。
回答by Bradley Grainger
We decided to use the same convention, and due to the limitations of Windows version numbers we chose to drop the "micro" part of our version numbers in order to preserve the revision number. Our version numbers are now [major].[minor].[revision / 10000].[revision % 10000], so the assemblies built from revision 65535 have the version 2.01.6.5535.
我们决定使用相同的约定，并且由于 Windows 版本号的限制，我们选择删除版本号的“微”部分以保留修订号。我们的版本号现在是[major].[minor].[revision / 10000].[revision % 10000]，因此从修订版 65535 构建的程序集具有版本 2.01.6.5535。
