Breakpoints

Understanding Assemblies

The way versioning is handled in the .NET world is considerably different than the way things were done with COM. In the past, each component (DLL or EXE, for example) had an embedded version number and was registered in the Windows registry using a unique ID. Whenever a new version of the component was distributed to a computer and registered, the registry would be updated and all clients that made use of the component on that computer would use the new component. This lead to a phenomenon known as "DLL Hell," which essentially consisted of the following problems:

• Some installation applications were poorly written and would actually install an older component file over a newer version. This would break applications that relied on functionality in the newer component.

• Some installation programs didn't adhere to proper standards and would install components in incorrect locations. This would often result in an older component being registered, voiding the registration of a newer version of the component that existed in a previous location, which would, once again, break applications that relied on functionality of the newer component.

• Some installation programs would fail to tell Windows that a given component was a shared component. When a COM component is installed as a shared component, Windows keeps track of the number of clients that have installed the component. That way, uninstalling a program won't uninstall a component that is being used by another client. When an installation program fails to tell Windows that a component is shared, the component could be uninstalled when the program is uninstalled (due to an invalid installation count), which would break other applications using the component.

• Some component vendors break compatibility in their new components. In this case, installing a newer version of the component in place of an older one (a perfectly logical and desirable thing to do) would break applications based on a previous edition of the component. This is perhaps the most serious problem of them all because you cannot run two different versions of a COM component. So, if you have one program that needs version A and another program that needs version B, the only solution is to modify the clients to use the same version or build an entirely new component that satisfies both clients.

The new versioning mechanism of .NET is built around assemblies. Assemblies are reusable packages that are versionable, self-describing building blocks that make up .NET solutions. Assemblies can be as simple as a single executable or can comprise numerous components and files. One key aspect of assemblies is that they do not rely on the registry in any way. Recall from the previous list that many of the issues of DLL Hell are related to the fact that COM components must be registered in the Windows registry. The fact that assemblies aren't registered in the Windows registry means that you can have side-by-side installations, where two or more versions of an assembly can exist on the same machine.

The key to assemblies is the fact that they contain metadata, which is data that describes the assembly. This self-describing metadata is called a manifest. When an assembly consists of a single component (such as an EXE), the manifest is compiled into the component. When an assembly is made up of multiple files, the manifest might exist as a separate file. The manifest includes, among other things, the versioning information for the assembly. In fact, the versioning information is one of the key pieces of data used to identify an assembly. This is why AssemblyX version 1 and AssemblyX version 2 each have a distinct identity and are treated as such.

You can get pretty detailed when dealing with assemblies and their manifests, but you don't necessarily have to. In fact, you don't really have to do much with them except define some key pieces of data before distribution, which I'll discuss in this chapter. In addition, you can create private and public assemblies. Public assemblies (which reside in the global assembly cache) are considerably more complicated than private assemblies (which reside in an application's folder). Public assemblies are discouraged for a number of reasons. One reason is that applications will use only the version of a public assembly for which the client was originally written; you can't drop a new version of the assembly in the global cache and expect clients to start using the new version. With private assemblies, however, you can distribute a new version of an assembly to the client folder and the client will use the newer version with no further interaction.

Note

If you find that you have to tailor the behavior of complex public assembly configurations, you should consult a text dedicated to the subject.

 

The versioning information in an assembly has four distinct parts, each separated by a period. These parts are as follows:

<major version>.<minor version>.<build number>.<revision> 

For example, consider the following version number:

2.0.1005.1 

In this version number, 2 is the major version, 0 is the minor version, 1005 is the build number, and 1 is the revision number. Each successive build of your component should have a new, incremented version number. Which portion of the version you choose to increment (major, minor, and so on) depends upon many factors, but the following are excellent guidelines to consider:

• Update the major version number when releasing a substantial upgrade to your application. Major version number changes are usually made to builds that require an upgrade fee. For example, when Microsoft released Microsoft Word 2002, it had a different major version than Word 2000, which had a different major version from Word 97, and so on.

• Update the minor version when building an update (service pack) that provides new functionality. Minor version releases (often called point releases) aren't usually revenue producers, but rather they are issued free to current customers or perhaps only to customers under support agreements. For example, say you added support for a new e-mail client in your application due to popular request. The additional functionality probably warrants a minor revision number update.

• Change the build number when only minor changes have been made to the component. Bug fixes and small feature changes, for example, usually warrant only a build version update.

• Modifying the revision number is usually reserved for internal builds. As you build, test, and tweak an update for release, update the revision number. When you are ready to build the release version of your component, reset the revision number to 0 and update either the build, minor, or major version number.

All Visual Basic .NET projects include a file titled AssemblyInfo.vb. (See Figure 17-1.) Double-clicking this file brings up the code editor, where you can make changes to the assembly's information. (See Figure 17-2.)

Figure 17-1. The AssemblyInfo file contains the assembly information including the product version.

You should enter values for all of the assembly attributes (title, description, and so forth), but the one item we're most interested in here is the Assembly Version attribute visible at the bottom of Figure 17-2. Notice that the default value for new projects is the following:

<Assembly: AssemblyVersion("1.0.*")> 

The format string "1.0.*" isn't actually a version number per se. Instead, it's a reserved string that Visual Basic .NET processes as follows:

1. The major version is set to 1.

2. The minor version is set to 0.

3. The build number is set to the number of days since January 1, 2000.

4. The revision number is set to the number of seconds since midnight.

Using "1.0.*" as the version number ensures that a unique version number is always assigned to a build, but the version numbers really don't make any sense. Instead, you should always use a specific version, like this:

<Assembly: AssemblyVersion("1.0.1.1")> 

Figure 17-2. Setting assembly attributes is as simple as entering some text in the code editor.

Warning

In previous editions of Visual Basic, you could set a flag that caused Visual Basic to increment the build number by one on each successful build. There is no such feature in Visual Basic .NET, so you'll have to add manually updating the version number to your release process.

 

 

Goals of Version Control

The goals of version control include

• Compiling the most current and stable components

• Versioning all compiled components

• Maintaining a history list of changes in versions

• Backing up project and other source files to prevent loss of work and time