File Version Information
Michael Casey
development in .NET, and I'm struggling to understand how the File Version
information for files should be handled. So, my question is really a
software development question that pertains to how the properties of the
file are manipulated, such that the Windows file system will recognize and
report these properties.
For those of you that are not familiar with .NET development, there is an
AssemblyInfo file that is included within a Visual Studio project, which can
be used to specify assembly attributes. One of those attributes is the
AssemblyVersion, which eventually will become a property of the Program
Executable version information. This can be verified by checking the
properties of the file through Windows Explorer. I have also noticed that
there is a variety of "other version information" available in the
properties dialog box of a file; of particular interest are some additional
version number attributes:
- FileVersion (defaults to the same number as the AssemblyVersion, but
listed as a separate property)
- Product Version (defaults to the same number as the AssemblyVersion,
but listed as a separate property)
Both of these attributes default to the same value as the AssemblyVersion
attribute, but may be controlled independently. Returning to the
AssemblyInfo file, used by project files of VisualStudio.NET, this file
contains attributes to control these properties:
- AssemblyFileVersion
- AssemblyInformationalVersion
Also, looking at the Windows Platform SDK, I have discovered a VERSIONINFO
Resource that looks like it is intended to be used in C/C++ header files for
controlling the version information of a build output. Within this
information, there is a FILEFLAGS property that includes attributes to
indicate whether the file is a PRERELEASE, PRIVATEBUILD, or SPECIALBUILD.
The use of these file properties are also of interest.
Now, given all these various ways to indicate version numbers (and other
version attributes), the question is how to use the attributes. The
AssemblyFileVersion seems to be the primary number of interest when viewed
by the Windows OS (i.e. Windows Explorer properties). However, the
AssemblyVersion number is the one that is routinely referenced by .NET
applications. Finally, the Product (or Informational) version appears to be
useful for managing a super version number that applies to a complex
multi-module assembly.
To summarize, my questions are:
1) Is it possible (and if so, how) to specify a PRERELEASE, PRIVATEBUILD, OR
SPECIALBUILD property for .NET program executable files?
2) When is appropriate to use a different numbering scheme for the Assembly
Version number, versus the File Version number? My current thinking is that
the Assembly Version number should include an auto-generated build number
(based upon a date/time stamp); whereas, the File Version number represents
a more stable looking release number for marketing purposes.
NOTE: I'm not sure if this newsgroup is appropriate for this question. If
not, I would appreciate any suggestions for where else to ask the question;
I don't see any .NET groups geared toward topics that include file
versioning.
Mike Casey
Cherry Qian (msft)
Thank you for the posting on the Assembly Version.
For your reference, I am providing you with the following information.
Controlling Assembly Version
==========================
An assembly's version is specified via the AssemblyVersion attribute (which
is defined within the AssemblyInfo.cs or AssemblyInfo.vb file). The version
number is physically represented as a four part number separated with
periods:
<major version>.<minor version>.<build number>.<revision>
You do not have to set and update each part explicitly because you can use
wild characters (*) to automatically generate the build and revision
numbers. Visual Studio .NET generates an AssemblyInfo source file with the
AssemblyVersion attribute defined as follows:
[assembly: AssemblyVersion("1.0.*")]
The result of this is a build number set to the number of days since a
random, designated start date and the revision based on the number of
seconds since midnight.
You can either use auto-increment version numbers or opt to manually
control version numbers as part of the build process. Each approach has
associated benefits and drawbacks.
Note For a Microsoft Visual Basic? .NET project with an AssemblyVersion
set to "1.0.*", the assembly version is only updated the first time the
project is rebuilt within the Visual Studio .NET integrated development
environment (IDE). The version number remains constant for subsequent
rebuilds within the same instance of Visual Studio .NET. This does not
represent a problem because the assembly version is for information only in
assemblies that do not have a strong name. For strong named assemblies, you
should avoid the use of wild characters in the AssemblyVersion attribute,
as explained in the following section.
For C# projects with an AssemblyVersion set to "1.0.*", the assembly
version is updated every time the project is rebuilt.
Using Auto-Increment Version Numbers
=================================
An auto-increment version number is established by adopting the default
"1.0.*" pattern for the AssemblyVersion attribute.
Advantages
Using auto-increment version numbers has the following advantages:
The build and revision numbers are handled automatically by Visual Studio
NET and do not have to be handled by the build script or build
coordinator.
You guarantee never to have different builds of an assembly with the same
version number.
Disadvantages
Using auto-increment version numbers has the following disadvantages:
The internal assembly build number does not match your system build number,
which means there is no easy way to correlate a particular assembly with
the build that generated it. This may be particularly problematic when you
need to support your system in a production environment.
Build and revision numbers are not increased by one but are based on the
time an assembly is built.
A new version of an assembly is generated each time it is built regardless
of whether any changes have been made to the assembly. For strongly named
assemblies, this means that all clients of that assembly must also be
rebuilt to point to the correct version. However, if the build process
rebuilds the whole system this should not be an issue.
Using Static Version Numbers
==========================
With this approach, you use a static version number, for example
"1.0.1001.1", and update the major or minor numbers only when a new version
is shipped with your next system release.
Advantages
Using static version numbers has the following advantages:
You have complete control over the exact version number.
Assembly build numbers can be synchronized with the system build number.
Disadvantages
Using static version numbers has the following disadvantages:
The version numbers must be manually updated by the build coordinator or by
the build script.
If the version is not incremented with every build, you may end up with
multiple builds of the same assembly with the same strong name. This is
undesirable and can be problematic for assemblies that are installed in the
Global Assembly Cache (GAC).
Important If you do not change the version of a strongly named assembly
and attempt to install it into the GAC using the Microsoft Windows?
operating system Installer, the latest dynamic-link library (DLL) does not
install if a previous version exists in the GAC with the same version
number.
If you use Gacutil.exe instead of Windows Installer to install the
assembly, the updated DLL is installed even if the assembly version number
is the same.
Consider Centralizing Assembly Version Numbers
To update the assembly version information for multiple assemblies, the
build script or build coordinator must check out and update multiple
AssemblyInfo files. To centralize the version information and enable a
single file checkout and update, consider the following approach:
Place the AssemblyVersion attribute in a single source file, for example
AssemblyVersionInfo.cs or AssemblyVersionInfo.vb.
Share the file across any projects that need to share the same version
number within VSS.
This approach assumes that you want the same assembly version assigned to
all assemblies generated by a particular system build. This may or may not
be appropriate for your particular system.
Hope the above information and suggestion helps and answers your question.
Meanwhile, it appears that this is a development-related request that would
best be best addressed in the developer newsgroups. The developer
newsgroups are located at:
http://msdn.microsoft.com/newsgroups/default.asp
Thank you for your understanding on this.
Sincerely,
Cherry Qian
MCSE2000, MCSA2000, MCDBA2000
Microsoft Partner Online Support
Get Secure! - www.microsoft.com/security
====================================================
When responding to posts, please Reply to Group via your newsreader so
that others may learn and benefit from your issue.
====================================================
This posting is provided AS IS with no warranties, and confers no rights.