C# 程序集命名和版本控制的最佳实践？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/199823/
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
Best practices for assembly naming and versioning?
提问by Gulzar Nazim
I am looking out for some good practices on naming assemblies and versioning them. How often do you increment the major or minor versions?
我正在寻找一些关于命名程序集和对其进行版本控制的良好实践。您多久增加一次主要或次要版本？
In some cases, I have seen releases going straight from version 1.0 to 3.0. In other cases, it seems to be stuck at version 1.0.2.xxxx.
在某些情况下，我看到版本直接从 1.0 版升级到 3.0 版。在其他情况下，它似乎卡在 1.0.2.xxxx 版本。
This will be for a shared assembly used in multiple projects across the company. Looking forward to some good inputs.
这将用于在整个公司的多个项目中使用的共享程序集。期待一些好的输入。
采纳答案by Gulzar Nazim
Some good information from this articleon Suzanne Cook's blog on MSDN (posted 2003-05-30):
来自MSDN 上 Suzanne Cook 博客的这篇文章的一些很好的信息（2003 年 5 月 30 日发布）：
When to Change File/Assembly Versions
First of all, file versions and assembly versions need not coincide with each other. I recommend that file versions change with each build. But, don't change assembly versions with each build just so that you can tell the difference between two versions of the same file; use the file version for that. Deciding when to change assembly versions takes some discussion of the types of builds to consider: shipping and non-shipping.
Non-Shipping Builds
In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This avoids strongly-named assembly loading problems due to version mismatches. Some people prefer using publisher policy to redirect new assembly versions for each build. I recommend against that for non-shipping builds, however: it doesn't avoid all of the loading problems. For example, if a partner x-copies your app, they may not know to install publisher policy. Then, your app will be broken for them, even though it works just fine on your machine.But, if there are cases where different applications on the same machine need to bind to different versions of your assembly, I recommend giving those builds different assembly versions so that the correct one for each app can be used without having to use LoadFrom/etc.
Shipping Builds
As for whether it's a good idea to change that version for shipping builds, it depends on how you want the binding to work for end-users. Do you want these builds to be side-by-side or in-place? Are there many changes between the two builds? Are they going to break some customers? Do you care that it breaks them (or do you want to force users to use your important updates)? If yes, you should consider incrementing the assembly version. But, then again, consider that doing that too many times can litter the user's disk with outdated assemblies.When You Change Your Assembly Versions
To change hardcoded versions to the new one, I recommend setting a variable to the version in a header file and replacing the hardcoding in sources with the variable. Then, run a pre-processor during the build to put in the correct version. I recommend changing versions right after shipping, not right before, so that there's more time to catch bugs due to the change.
何时更改文件/程序集版本
首先，文件版本和程序集版本不需要彼此一致。我建议文件版本随每次构建而变化。但是，不要在每次构建时更改程序集版本，只是为了区分同一文件的两个版本；为此使用文件版本。决定何时更改程序集版本需要对要考虑的构建类型进行一些讨论：运输和非运输。
非
出货版本 一般来说，我建议在出货版本之间保持非出货组件版本相同。这避免了由于版本不匹配而导致的强命名程序集加载问题。有些人更喜欢使用发布者策略为每个构建重定向新的程序集版本。但是，我建议不要将其用于非运输构建：它并不能避免所有加载问题。例如，如果合作伙伴 x 复制您的应用程序，他们可能不知道安装发布商政策。然后，您的应用程序将被他们破坏，即使它在您的机器上运行良好。但是，如果同一台机器上的不同应用程序需要绑定到不同版本的程序集，我建议为这些构建提供不同的程序集版本，以便每个应用程序都可以使用正确的程序集版本，而不必使用 LoadFrom/etc。
发布版本
至于为发布版本更改该版本是否是一个好主意，这取决于您希望绑定如何为最终用户工作。您希望这些构建是并排的还是就地的？两个版本之间有很多变化吗？他们会破坏一些客户吗？您是否关心它是否会破坏它们（或者您是否想强制用户使用您的重要更新）？如果是，您应该考虑增加程序集版本。但是，再一次考虑，这样做太多次会使用户的磁盘上堆满过时的程序集。更改程序集版本时
要将硬编码版本更改为新版本，我建议在头文件中为版本设置一个变量，并将源代码中的硬编码替换为该变量。然后，在构建期间运行预处理器以放入正确的版本。我建议在发布后立即更改版本，而不是在发布之前更改版本，以便有更多时间来捕捉由于更改而导致的错误。
回答by andy
One way to define your versioning is to give semantic meaning to each portion:
定义版本控制的一种方法是为每个部分赋予语义含义：
- Go from N.x to N+1.0 when compatibility breaks with the new relase
- Go from N.M to N.M+1 when new features are added which do not break compatibility
- Go from N.M.X to N.M.X+1 when bug fixes are added
- 当与新版本的兼容性中断时，从 Nx 转到 N+1.0
- 当添加不破坏兼容性的新功能时，从 NM 到 N.M+1
- 添加错误修复后，从 NMX 转到 NMX+1
The above is just an example -- you'd want to define the rules that make sense for you. But it is very nice for users to quickly tell if incompatibilities are expected just by looking at the version.
上面只是一个例子——你想定义对你有意义的规则。但是对于用户来说，仅通过查看版本就可以快速判断是否存在不兼容问题，这非常好。
Oh, and don't forget to publish the rules you come up with so people know what to expect.
哦，别忘了发布您提出的规则，以便人们知道会发生什么。
回答by Scott Dorman
The first thing I would recommend is to become familiar with the differences between the Assembly version and the File version. Unfortunately, .NET tends to treat these as the same when it comes to the AssemblyInfo files in that it usually only puts AssemblyVersion and allows the FileVersion to default to the same value.
我建议的第一件事是熟悉程序集版本和文件版本之间的差异。不幸的是，当涉及到 AssemblyInfo 文件时，.NET 倾向于将它们视为相同的，因为它通常只放置 AssemblyVersion 并允许 FileVersion 默认为相同的值。
Since you said this is a shared assembly, I'm assuming you mean it's shared at a binary level (not by including the project in the various solutions). If that's the case you want to be very deliberate about changing the Assembly version as that is what .NET uses to strong name the assembly (to allow you to put it in the GAC) and also makes up the "assembly full name". When the assembly version changes, it can have breaking changes for the applications that use it without adding assembly redirect entries in the app.config file.
既然你说这是一个共享程序集，我假设你的意思是它是在二进制级别共享的（不是通过将项目包含在各种解决方案中）。如果是这种情况，您需要非常慎重地更改程序集版本，因为这是 .NET 用来对程序集进行强命名（以允许您将其放入 GAC）并构成“程序集全名”的内容。当程序集版本更改时，它可能会对使用它的应用程序进行重大更改，而无需在 app.config 文件中添加程序集重定向条目。
As for naming, I think it depends on what your company naming rules are (if any) and the purpose of the library. For exmaple, if this library provides "core" (or system level) functionality that isn't specific to any particular product or line of business, you could name it as:
至于命名，我认为这取决于您公司的命名规则（如果有的话）和库的目的。例如，如果此库提供不特定于任何特定产品或业务线的“核心”（或系统级）功能，您可以将其命名为：
CompanyName.Framework.Core
if it's part of a larger library, or simply
如果它是更大图书馆的一部分，或者只是
CompanyName.Shared
CompanyName.Core
CompanyName.Framework
As far as when to increment version numbers, it's still rather subjective and depends on what you consider each portion of the build number to represent. The default Microsoft scheme is Major.Minor.Build.Revision, but that doesn't mean you can't come up with your own definitions. The most important thing is to be consistent in your strategy and make sure that the definitions and rules make sense across all of your products.
至于何时增加版本号，它仍然是相当主观的，取决于您认为内部版本号的每个部分代表什么。默认的 Microsoft 方案是 Major.Minor.Build.Revision，但这并不意味着您无法提出自己的定义。最重要的是在您的策略中保持一致，并确保定义和规则在您的所有产品中都有意义。
In almost every version scheme I've seen the first two portions are Major.Minor. The major version number usually increments when there are large changes and/or breaking changes, while the minor version number usually increments to indicate that something changed which did was not a breaking change. The other two numbers are considerably more subjective and can be the "build" (which is often times a serial date value or a sequentially updating number that changes each day) and the "revision" or patch number. I've also seen them reversed (giving Major.Minor.Revision.Build) where build is a sequentially incrementing number from an automated build system.
在我见过的几乎所有版本方案中，前两部分都是 Major.Minor。主要版本号通常会在发生较大更改和/或重大更改时增加，而次要版本号通常会增加以表明发生的更改不是重大更改。其他两个数字要主观得多，可以是“构建”（通常是序列日期值的时间或每天更改的顺序更新数字）和“修订版”或补丁号。我还看到它们颠倒过来（给出 Major.Minor.Revision.Build），其中 build 是来自自动构建系统的按顺序递增的数字。
Keep in mind that the assembly major and minor versions are used as the type library version number when the assembly is exported.
请记住，在导出程序集时，程序集主要版本和次要版本用作类型库版本号。
Finally, take a look at some of these resources for more information:
最后，查看其中一些资源以获取更多信息：
http://msdn.microsoft.com/en-us/library/51ket42z.aspx
http://msdn.microsoft.com/en-us/library/51ket42z.aspx
http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx
http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx
回答by Bil Simser
Semantic Versioning has a set of guidelines and rules as to how to apply this (and when). Very simple to follow and it just works.
语义版本控制有一套关于如何（以及何时）应用的指导方针和规则。非常容易遵循，它只是有效。
