Put it this way - say you identify a problem with a component on your site. During a round of testing and development you create a new component that addresses the problem that you duly deploy to the remote server. Now when you come to test, the bug appears to still be there. The question that runs through most developers' heads at this point is "Is the code the correct version?"

Well, Microsoft does a really neat job of hiding most of the internals of ActiveX away from us, so in order to determine if IIS (the Server we intend to deploy to)) is loading the right component we have to start digging through the Registry. Even if all that appears to be in order, we still can't see inside IIS to determine if it's doing something odd. We then can't be confident that our next step in solving the problem is the correct one.

One of the quickest and easiest ways to address this problem is through versioning. Since the beginning, Windows has put functionality into its development tools that lets developers tack version numbers onto the end of any DLL, EXE or OCX.

For example, if you open up Windows Explorer and find a DLL or EXE on your system, then right-click on it, choose Properties, and change to the Version tab, you should see something like:

In this example, which is one of Microsoft's MFC runtime DLLs, we can see the version number that the developers tacked onto the end of the file to identify it; in this case it's 4.21.7022.

The three parts making up this number are, in order, termed:

• Major Number
• Minor Number
• Revision

Thus in our example the major number is 4, the minor 21 and it's revision 7022. The major and minor numbers usually stay fixed throughout a development project. So, if six months after we've deployed Jo's Coffee we need to do some maintenance work, we will probably choose to increase the minor number. If we need to do a serious overhaul of the code, we will probably choose to increase the major number.

For day-to-day deployment and testing, we'll usually increase the revision number (sometimes called build number). The very first component we deploy will have a revision number of 0. The second will be 1, and so on.

It's a good idea to do include versioning information with our DLLs, but we should make sure that each time we compile a new version of the DLL for deployment we have to change the version number.

Try It Out - Setting the Original Version Number

1. You can use VB's Project Properties dialog to set the original version number of the project. Select Project | WroxCommerce Properties and change to the Make tab:

You can see on the dialog that there are three boxes, one for each of minor, major and revision. There's also a Version Information box that you can use to set other information on the DLL, like copyright information, product information and such like. Referring back to the MFC DLL Properties screenshot, you can guess that, if we change that information here, users of Windows Explorer will be able to see the values we set when they bring up the file's properties.

We can ask VB to automatically increment this revision number for us each time we make (or compile) the DLL by ensuring Auto Increment is checked on.

2. As we are just starting out on our project set Major to 1, Minor to 0, and Revision to 0 and close the dialog.

An Aside - Obtaining the Version Number

Once we're confident in our versioning strategy, we can make our business object DLLs tell us their version number by querying a property on the root object in the model.

Programmatically checking the version number of DLLs on your system is actually quite tricky. For this reason, we're going to build properties into our Visit object that we can use to quickly find the version number of our business object DLLs.

To do this, all you have to do is ask the Visit object for it's Major, Minor, and Revision numbers, like this:

' Version - returns the version number back...
Public Property Get Version() As String
Version = App.Major & "." & App.Minor & "." & App.Revision
End Property

In our Version property, all we've done is taken those three numbers and mangled them into a string, like this: 1.0.0. We'll see this approach in action later on.

As you'll see later, we can, when required, build a very simple ASP page that lets us keep our head while all around are losing theirs. Just by querying a single page on the server, we can see if we are using the correct version of the component. The code that we'll eventually use to achieve this aim is:

<%
 ' create an instance of the site...
 Dim Visit
 Set Visit = Server.CreateObject("WroxCommerce.Visit")

 ' get the version number...
 Response.Write "Version: " & Visit.Version

 ' stop the site...
 Visit.ShutDown
 Set Visit = Nothing 
%>