The AssemblyVersion and AssemblyFileVersion attributes are the built-in way of handling version numbers for .NET assemblies. While the framework provides the ability to have the least significant parts of a version number (build and revision, in Microsoft terms) automatically determined, I find the method for this pretty weak, and no doubt have many others.
AssemblyVersion和AssemblyFileVersion属性是处理.NET程序集版本号的内置方法。虽然框架提供了自动确定版本号(构建和修订,在Microsoft术语中)中最不重要部分的能力,但我发现这种方法相当薄弱,毫无疑问还有许多其他方法。
So I'd like to ask, what ways have been determined to do the best job of having version numbers that better reflect the actual version of a project? Do you have a pre-build script that sets part of the version to the date and time, or repository version for your working copy of a project? Do you just use the automatic generation provided by the framework? Or something else? What's the best way to manage assembly/file versioning?
所以我想问一下,有哪些方法可以确保最好地使用更好地反映项目实际版本的版本号?您是否有预构建脚本将版本的一部分设置为日期和时间,或者是项目工作副本的存储库版本?您是否只使用框架提供的自动生成?或者是其他东西?管理汇编/文件版本控制的最佳方法是什么?
8 个解决方案
#1
5
On my current project, we use the Subversion revision number as the least significant (build) part of the version number, and we use a Nant script to create the project AssemblyInfo file. We use the same version number for both the AssemblyVersion and AssemblyFileVersion attributes. (The other three parts are major.minor.point, where major.minor will be incremented every time there's a database schema change, and point is incremented for each release.)
在我当前的项目中,我们使用Subversion修订版号作为版本号的最不重要(构建)部分,并且我们使用Nant脚本来创建项目AssemblyInfo文件。我们对AssemblyVersion和AssemblyFileVersion属性使用相同的版本号。 (其他三个部分是major.minor.point,其中major.minor将在每次数据库模式更改时递增,并且每个版本的点都会递增。)
We started out with the build number being simply incremented, but that required that the version file be checked in for every build, and caused conflicts when merging. When that proved unworkable, we started using CruiseControl.NET to generate the build number, but that made it difficult to reproduce specific builds manually. Eventually we went to the current (Subversion-revision) scheme.
我们开始时只是增加了构建号,但是这需要为每个构建签入版本文件,并在合并时引起冲突。当证明不可行时,我们开始使用CruiseControl.NET生成内部版本号,但这使得难以手动重现特定版本。最终我们进入了当前的(Subversion-revision)计划。
Note: Unfortunately with .NET, it is not possible to perfectly recreate a build from a past revision, because the .NET compilers encode the current timestamp into the object file when compiling. Every time you compile the same code, you get a different object file.
注意:遗憾的是,使用.NET时,无法从过去的修订中完美地重新构建构建,因为.NET编译器在编译时将当前时间戳编码到目标文件中。每次编译相同的代码时,都会得到一个不同的目标文件。
#2
9
I see many posts here about using the subversion revision number as a component of the assembly version. Beware: the 4 version numbers available in windows (a.b.c.d) are each limited to 16 bit (max = 65535). The subversion revision number can easily exceed this limit, especially if you host multiple projects in the same repository.
我在这里看到很多关于使用subversion版本号作为程序集版本的组件的帖子。注意:Windows中可用的4个版本号(a.b.c.d)每个都限制为16位(最大值= 65535)。 subversion版本号很容易超过此限制,尤其是在同一存储库中托管多个项目时。
#3
4
At a previous job, where we used Subversion, I had a nant script run about ccnet to extract the repository version and used that as the final number.
在我们之前使用Subversion的工作中,我有一个关于ccnet的nant脚本来提取存储库版本并将其用作最终编号。
At this job, we use VSS (shutter), so that's not really an option, so we have a policy of updating it manually, with the following guidelines:
在这项工作中,我们使用VSS(快门),因此这不是一个真正的选择,所以我们有一个手动更新它的政策,遵循以下准则:
- Major : significant ( > 25%) changes or addition in functionality or interface.
- Minor : small changes or additions in functionality or interface.
- Build : minor changes that break the interface.
- Revision: fixes to a build which do not change the interface.
主要:功能或界面的重大(> 25%)变化或添加。
次要:功能或界面中的小改动或添加。
构建:破坏界面的微小更改。
修订:修复了不会更改界面的构建。
We also keep the Assembly & the File versions in sync. The Assembly version can be easily read programmatically, while the file version can be displayed as a column in Details mode in Windows Explorer.
我们还使Assembly和File版本保持同步。可以通过编程方式轻松读取程序集版本,而文件版本可以在Windows资源管理器的“详细信息”模式下显示为列。
#4
3
Our build scripts inject the changeset number from TFS into the version. That way we know exactly what checkins are in the build.
我们的构建脚本将TFS中的变更集编号注入到版本中。这样我们就可以准确地知道构建中的签名。
#5
3
We have our CruiseControl.NET build server embed the perforce changelist number into the AssemblyFileVersion — this lets us track back to the source code for any assembly built by the build server. (We always build from the main branch.)
我们的CruiseControl.NET构建服务器将perforce变更列表编号嵌入到AssemblyFileVersion中 - 这使我们可以追溯到构建服务器构建的任何程序集的源代码。 (我们总是从主要分支建立。)
For assemblies that customers will be referencing we leave the AssemblyVersion constant unless there are breaking changes, in which case we increment the version to ensure that customer code gets re-built against the new version.
对于客户将引用的程序集,我们将AssemblyVersion保持不变,除非发生重大更改,在这种情况下,我们会增加版本以确保客户代码可以针对新版本重新构建。
#6
2
We use the versioning from subversion and have the buildscripts update the assembly version info, so source checkins control versioning.
我们使用来自subversion的版本控制,并让buildscripts更新程序集版本信息,因此源checkins控制版本控制。
#7
2
We tend to embed the release (or build) date into the assembly. For example if built today the version would be "2008.10.06" (the build script updates it).
我们倾向于将发布(或构建)日期嵌入到程序集中。例如,如果今天构建版本将是“2008.10.06”(构建脚本更新它)。
#8
1
The AssemblyVersionAttribute is part of an assembly's identity. Changing that means it is a different assembly and programs linking to that assembly need to be recompiled/linked or a version policy need to be applied. We didn't find that apealing so we choose to only increase the AssemblyFileVersion for each hotfix and only change the AssemblyVersion for each major release. We are aware that this decision brings back some of the win32 dll hell. We increase the AssemblyFileVersion for each build and label/tag the version control system with that version so we know from what source the binary came.
AssemblyVersionAttribute是程序集标识的一部分。更改这意味着它是一个不同的程序集,链接到该程序集的程序需要重新编译/链接或需要应用版本策略。我们没有找到apealing所以我们选择只为每个修补程序增加AssemblyFileVersion,并且只更改每个主要版本的AssemblyVersion。我们知道这个决定带回了一些win32 dll地狱。我们为每个构建增加了AssemblyFileVersion,并使用该版本标记/标记版本控制系统,以便我们知道二进制文件的来源。
#1
5
On my current project, we use the Subversion revision number as the least significant (build) part of the version number, and we use a Nant script to create the project AssemblyInfo file. We use the same version number for both the AssemblyVersion and AssemblyFileVersion attributes. (The other three parts are major.minor.point, where major.minor will be incremented every time there's a database schema change, and point is incremented for each release.)
在我当前的项目中,我们使用Subversion修订版号作为版本号的最不重要(构建)部分,并且我们使用Nant脚本来创建项目AssemblyInfo文件。我们对AssemblyVersion和AssemblyFileVersion属性使用相同的版本号。 (其他三个部分是major.minor.point,其中major.minor将在每次数据库模式更改时递增,并且每个版本的点都会递增。)
We started out with the build number being simply incremented, but that required that the version file be checked in for every build, and caused conflicts when merging. When that proved unworkable, we started using CruiseControl.NET to generate the build number, but that made it difficult to reproduce specific builds manually. Eventually we went to the current (Subversion-revision) scheme.
我们开始时只是增加了构建号,但是这需要为每个构建签入版本文件,并在合并时引起冲突。当证明不可行时,我们开始使用CruiseControl.NET生成内部版本号,但这使得难以手动重现特定版本。最终我们进入了当前的(Subversion-revision)计划。
Note: Unfortunately with .NET, it is not possible to perfectly recreate a build from a past revision, because the .NET compilers encode the current timestamp into the object file when compiling. Every time you compile the same code, you get a different object file.
注意:遗憾的是,使用.NET时,无法从过去的修订中完美地重新构建构建,因为.NET编译器在编译时将当前时间戳编码到目标文件中。每次编译相同的代码时,都会得到一个不同的目标文件。
#2
9
I see many posts here about using the subversion revision number as a component of the assembly version. Beware: the 4 version numbers available in windows (a.b.c.d) are each limited to 16 bit (max = 65535). The subversion revision number can easily exceed this limit, especially if you host multiple projects in the same repository.
我在这里看到很多关于使用subversion版本号作为程序集版本的组件的帖子。注意:Windows中可用的4个版本号(a.b.c.d)每个都限制为16位(最大值= 65535)。 subversion版本号很容易超过此限制,尤其是在同一存储库中托管多个项目时。
#3
4
At a previous job, where we used Subversion, I had a nant script run about ccnet to extract the repository version and used that as the final number.
在我们之前使用Subversion的工作中,我有一个关于ccnet的nant脚本来提取存储库版本并将其用作最终编号。
At this job, we use VSS (shutter), so that's not really an option, so we have a policy of updating it manually, with the following guidelines:
在这项工作中,我们使用VSS(快门),因此这不是一个真正的选择,所以我们有一个手动更新它的政策,遵循以下准则:
- Major : significant ( > 25%) changes or addition in functionality or interface.
- Minor : small changes or additions in functionality or interface.
- Build : minor changes that break the interface.
- Revision: fixes to a build which do not change the interface.
主要:功能或界面的重大(> 25%)变化或添加。
次要:功能或界面中的小改动或添加。
构建:破坏界面的微小更改。
修订:修复了不会更改界面的构建。
We also keep the Assembly & the File versions in sync. The Assembly version can be easily read programmatically, while the file version can be displayed as a column in Details mode in Windows Explorer.
我们还使Assembly和File版本保持同步。可以通过编程方式轻松读取程序集版本,而文件版本可以在Windows资源管理器的“详细信息”模式下显示为列。
#4
3
Our build scripts inject the changeset number from TFS into the version. That way we know exactly what checkins are in the build.
我们的构建脚本将TFS中的变更集编号注入到版本中。这样我们就可以准确地知道构建中的签名。
#5
3
We have our CruiseControl.NET build server embed the perforce changelist number into the AssemblyFileVersion — this lets us track back to the source code for any assembly built by the build server. (We always build from the main branch.)
我们的CruiseControl.NET构建服务器将perforce变更列表编号嵌入到AssemblyFileVersion中 - 这使我们可以追溯到构建服务器构建的任何程序集的源代码。 (我们总是从主要分支建立。)
For assemblies that customers will be referencing we leave the AssemblyVersion constant unless there are breaking changes, in which case we increment the version to ensure that customer code gets re-built against the new version.
对于客户将引用的程序集,我们将AssemblyVersion保持不变,除非发生重大更改,在这种情况下,我们会增加版本以确保客户代码可以针对新版本重新构建。
#6
2
We use the versioning from subversion and have the buildscripts update the assembly version info, so source checkins control versioning.
我们使用来自subversion的版本控制,并让buildscripts更新程序集版本信息,因此源checkins控制版本控制。
#7
2
We tend to embed the release (or build) date into the assembly. For example if built today the version would be "2008.10.06" (the build script updates it).
我们倾向于将发布(或构建)日期嵌入到程序集中。例如,如果今天构建版本将是“2008.10.06”(构建脚本更新它)。
#8
1
The AssemblyVersionAttribute is part of an assembly's identity. Changing that means it is a different assembly and programs linking to that assembly need to be recompiled/linked or a version policy need to be applied. We didn't find that apealing so we choose to only increase the AssemblyFileVersion for each hotfix and only change the AssemblyVersion for each major release. We are aware that this decision brings back some of the win32 dll hell. We increase the AssemblyFileVersion for each build and label/tag the version control system with that version so we know from what source the binary came.
AssemblyVersionAttribute是程序集标识的一部分。更改这意味着它是一个不同的程序集,链接到该程序集的程序需要重新编译/链接或需要应用版本策略。我们没有找到apealing所以我们选择只为每个修补程序增加AssemblyFileVersion,并且只更改每个主要版本的AssemblyVersion。我们知道这个决定带回了一些win32 dll地狱。我们为每个构建增加了AssemblyFileVersion,并使用该版本标记/标记版本控制系统,以便我们知道二进制文件的来源。