Comments on: The Art of Assembly Versions http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/ Tue, 16 Mar 2010 14:19:47 -0500 http://wordpress.org/?v=2.8.6 hourly 1 By: trasa http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/comment-page-1/#comment-38409 trasa Sun, 30 Nov 2008 21:02:36 +0000 http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/#comment-38409 I intentionally deviate from what MSDN says there - how do you get a revision out the door without building it? A build # is the smallest conceptual unit we're working with, particularly if you're automating your build. I intentionally deviate from what MSDN says there – how do you get a revision out the door without building it? A build # is the smallest conceptual unit we’re working with, particularly if you’re automating your build.

]]> By: Adam http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/comment-page-1/#comment-38406 Adam Sun, 30 Nov 2008 20:34:05 +0000 http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/#comment-38406 Woops, you've got your revision/build numbers around the wrong way. The version format is: ... see msdn: http://tinyurl.com/5pd4xo Woops, you’ve got your revision/build numbers around the wrong way.
The version format is:

…

see msdn: http://tinyurl.com/5pd4xo

]]> By: Reflective Perspective - Chris Alcock » The Morning Brew #110 http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/comment-page-1/#comment-23326 Reflective Perspective - Chris Alcock » The Morning Brew #110 Mon, 09 Jun 2008 07:28:21 +0000 http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/#comment-23326 [...] The Art of Assembly Versions - Tony Rasa talks version numbers, and why its important to ensure that they get updated. [...] [...] The Art of Assembly Versions – Tony Rasa talks version numbers, and why its important to ensure that they get updated. [...]

]]> By: Dew Drop – June 6, 2008 | Alvin Ashcraft's Morning Dew http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/comment-page-1/#comment-23047 Dew Drop – June 6, 2008 | Alvin Ashcraft's Morning Dew Fri, 06 Jun 2008 12:40:20 +0000 http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/#comment-23047 [...] The Art of Assembly Versions (Tony Rasa) [...] [...] The Art of Assembly Versions (Tony Rasa) [...]

]]> By: Michael Hanney http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/comment-page-1/#comment-22959 Michael Hanney Thu, 05 Jun 2008 18:35:48 +0000 http://elegantcode.com/2008/06/05/the-art-of-assembly-versions/#comment-22959 I completely agree it is important to to have a version naming method, and one that integrates well with the automated build process as well as visual studio. I doubt there is one convention that suits all projects. Here is a scheme I'm currently using on one project. I am not saying it is better, (in many ways it is not). It is just an alternative idea because of the limitation imposed by one particular web hosting environment. In some of our larger deployments we have multiple versions of the same assembly in the GAC to serve many customer websites hosted on one machine (I won't bore you with the details of why the assemblies cannot be the same, or why they cannot go in the website bin dir). The point is, we are required to keep the {major}.{minor}.{revision}.{build} numbers constant between upgrades, but there are other properties available in the assembly manifest meta-data we can use to identify the release. We stamp the assemblies with revision and build information using the AssemblyInformationalVersion, and AssemblyFileVersion properties. These are informational only and don't affect the GAC or linker. We use AssemblyInformationalVersion to identify the product. This is a constant. The AssemblyFileVersion is used to store the {major}.{minor}.{revision}.{build} numbers. The value in AssemblyFileVersion corresponds directly to the tag used to label the source code in the subversion repository at the time the release was created. I am not sure if this is the intended purpose for AssemblyFileVersion, but the name is appropriate considering it ties in with the source files. We can recreate a release from a tag in subversion, or checkout a branch for an already deployed release if it needs a bug fixed and re-deployed. AssemblyInformationalVersion, AssemblyFileVersion and AssemblyVersion are defined in a single VersionInfo.cs file for the build and referenced by each MSBuild project in the solution as a linked file in the Properties directory. There is a also an AssemblyInfo.cs file for each project, as usual, but this contains constant values. When working in visual studio, VersionInfo.cs never changes. When doing a release, a custom MSBuild task creates a new VersionInfo.cs file and proceeds to compile the entire source. The build task is responsible for keeping the values in VersionInfo.cs in sync with subversion tags. Our MSBuild tasks are based on the open source MSBuild Community task which include an AssemblyInfo task. Very much worth checking out, http://msbuildtasks.tigris.org/ I completely agree it is important to to have a version naming method, and one that integrates well with the automated build process as well as visual studio.

I doubt there is one convention that suits all projects. Here is a scheme I’m currently using on one project. I am not saying it is better, (in many ways it is not). It is just an alternative idea because of the limitation imposed by one particular web hosting environment.

In some of our larger deployments we have multiple versions of the same assembly in the GAC to serve many customer websites hosted on one machine (I won’t bore you with the details of why the assemblies cannot be the same, or why they cannot go in the website bin dir). The point is, we are required to keep the {major}.{minor}.{revision}.{build} numbers constant between upgrades, but there are other properties available in the assembly manifest meta-data we can use to identify the release.

We stamp the assemblies with revision and build information using the AssemblyInformationalVersion, and AssemblyFileVersion properties. These are informational only and don’t affect the GAC or linker.

We use AssemblyInformationalVersion to identify the product. This is a constant.

The AssemblyFileVersion is used to store the {major}.{minor}.{revision}.{build} numbers. The value in AssemblyFileVersion corresponds directly to the tag used to label the source code in the subversion repository at the time the release was created.

I am not sure if this is the intended purpose for AssemblyFileVersion, but the name is appropriate considering it ties in with the source files. We can recreate a release from a tag in subversion, or checkout a branch for an already deployed release if it needs a bug fixed and re-deployed.

AssemblyInformationalVersion, AssemblyFileVersion and AssemblyVersion are defined in a single VersionInfo.cs file for the build and referenced by each MSBuild project in the solution as a linked file in the Properties directory. There is a also an AssemblyInfo.cs file for each project, as usual, but this contains constant values. When working in visual studio, VersionInfo.cs never changes.

When doing a release, a custom MSBuild task creates a new VersionInfo.cs file and proceeds to compile the entire source. The build task is responsible for keeping the values in VersionInfo.cs in sync with subversion tags. Our MSBuild tasks are based on the open source MSBuild Community task which include an AssemblyInfo task. Very much worth checking out, http://msbuildtasks.tigris.org/

]]>