| |
Introduction |
| |
Each assembly has a version
number as part of its identity. As such, two assemblies that
differ by version number are considered by the runtime to
be completely different assemblies. This version number is
physically represented as a four-part number with the following
format: |
| |
| <major
version>.<minor version>.<build number>.<revision> |
| |
For example, version 1.5.1254.0
indicates 1 as the major version, 5 as the minor version,
1254 as the build number, and 0 as the revision number. |
| |
The version number is stored
in the assembly manifest along with other identity information,
including the assembly name and public key, as well as information
on relationships and identities of other assemblies connected
with the application. When an assembly is built, the development
tool records dependency information for each assembly that
is referenced in the assembly manifest. The runtime uses these
version numbers, in conjunction with configuration information
set by an administrator, an application, or a publisher, to
load the proper version of a referenced assembly.
|
| |
| The runtime distinguishes between
regular and strong-named assemblies for the purposes of versioning.
Version checking only occurs with strong-named assemblies. |
| |
Controlling Assembly
Version |
| |
| An assembly's version is specified
via the AssemblyVersion attribute (which is defined within the
AssemblyInfo.cs or AssemblyInfo.vb file). 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. 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. |
| |
| 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. |
| |
| Using Auto-Increment
Version Numbers |
| |
| An auto-increment version number
is established by adopting the default "1.0.*" pattern
for the AssemblyVersion attribute. |
| |
| Advantages |
| |
| 1. |
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. |
| 2. |
You guarantee never to have different
builds of an assembly with the same version number. |
|
| |
| Disadvantages |
| |
| 1. |
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. |
| 2. |
Build and revision numbers are not increased
by one but are based on the time an assembly is built. |
| 3. |
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 |
| |
| 1. |
You have complete control
over the exact version number. |
| 2. |
Assembly build numbers can be synchronized
with the system build number. |
|
| |
| Disadvantages |
| |
| 1. |
The version numbers must
be manually updated by the build coordinator or by the
build script. |
| 2. |
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). |
|
| |
| 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. |
| |
| Global Assembly Cache |
| |
| A machine-wide code cache that
stores assemblies specifically installed to be shared by many
applications on the computer. Applications deployed in the global
assembly cache must have a strong name. |
| |
| Multiple Versions of
Same Assembly in GAC |
| |
| Global Assembly Cache (GAC)
maintains all the assembly in <OS Folder>\winnt\Assembly
folder. If you see this folder in command prompt, you can see
multiple sub folders for each assembly installed in GAC with
name of folder as assembly name. If you see inside that assembly
name folder, you can find out how the multiple versions of same
assembly is stored in GAC. This sub folder will have many sub-folders
in the combination of version and public key. Hence when old
assembly is deployed with new version number or public key,
a new sub folder is created under the same assembly name folder.
Hence it can maintain multiple versions of same assembly. Check
out the following fig, how it maintaining multiple versions
of same assembly |
| |
 |
| |
| 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. |
| |
| COM+ |
| |
| Whenever an assembly is registered
in COM+, an Classid is generated for that assembly and it is
registered in COM+ with that id. Classid is generated based
on assembly name, version number and public key. So whenever
the version number or public key is changed for an assembly,
it will consider that registration as a new registration. Hence
it will be registered with new Classid. |
| |
| When a assembly is not registered
in COM+, but it is registered in GAC. When that assembly is
initiated , first it will register that assembly with COM+ with
default attributes mentioned in assembly manifest, then that
assembly is initiated. This type of registration is known as
Lazy-registration. You should avoid this type of registration. |
| |
| Conclusion |
| |
| In this article, we have seen
how versioning is happening in .NET and the various methods
of versioning. Depending upon our application we need to decide
on which method to choose. If you are planning to follow static
versioning method, then you need to decide on when to change
the version number for your assembly or you need to have strategy
for centralizing assembly version numbers. |
| |
| |
