COMMERCIAL AND PROFESSIONAL APPLICATION DEVELOPMENT
Part Six - Installation and Integration

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

Welcome to the Sixth and final part of this series. I don't have to remind you of everything we've covered in this series so far, If you've read them all, I'm sure you already know what you learned. In this final part, we will be covering the installation and integration process, or whatever comes after the application is ready for distribution to your users and/or your clients. The installation process isn't a simple question of creating the installation and running it on the users machine or having the client run the setup. The creation of the setup files is a process in itself and there are certain things to consider while creating the setup file. Reason why I mention this is I've seen people create a setup for their application and when the client executed that setup, either some other program didn't work anymore, or worst, the whole system when into a rebooting loop and couldn't complete the booting process anymore. All this could have been avoided with the proper set if precautions to take when making your application installation.

This is what this last part of the series will be about. We'll see what these considerations should be, we'll look at the tools we have at our disposal because just like the other parts of the development cycle, there are tools out there specifically designed to help make the creation of an installation system straightforward while minimizing the risk of software conflicts like the two examples I mentionned above. Let's start from the beginning and work our way down the installation process and see what happens.

WHAT IS AN INSTALLATION:

Well, there's two possible answers to this question and both of these entail a very different set of considerations and precautions to take. When you think about it, there's two types of development projects, as mentionned, in the corporate world. There are the applications developed with the goal to be sold as a commercial product and there are the application that are created to be used either by the employees of your firm, or one specific client. Let's take the time to review some specifics of these two types of application project. This will help us, later in the document, to see why they are so different and therefore require some very different sets of considerations.

• The Commercial Applications:
  Commercial applications are applications that are sold in the stores or by the company. You can imagine that this type of applications need be able to install itself in many different operating system versions as well as cause no conflict with any application the user might have already installed on their machine. As such, creating an installation for a commercial application needs to take all this into consideration. In this type of application project, only one thing really matters and that is the application's capacity to coexist with anything else that might already be present on the system.


• The Professional Applications:
  The professional application are either used inhouse or created contractually for a specific client. The first thing you can imagine from this type of application is that usually, thre will be a fixed number of possible circumstances to consider. It will be more important to make the application work on the system where it will be executed rather than try to create a universal installation. In a very general point of view however you can use the same tools to create the installation program itself as you would for a commercial application. What will change is everything you'll be taking into consideration for both type of applications.

Again here I can safely mention that preperation is definitaly the key. And to prepare yourself for an installation process requires nothing special. You need to know where the application is going to be installed, what could be already present, and how you can avoid overwriting anything that could cause a conflict of some sort once your application is installed. Once you have all that information, creating the installation can be quite easy, and quick provided you have, once again, the right tool for the job.

WHAT ARE THE TOOLS AVAILABLE:

There is more than one installation tool available, some companies offer different products for different types of installation needs. There's only two companies that I will talk about here because they are the companies/products that I have had teh chance to work with and can give you enough information about them so you can make a choice on which. When you have all your installation specifications and the considerations you are equipped to make the right choice when choosing the installation system you'll need. That is assuming your firm doesn't already use one and that you are limited to using that system only to create your installation.

• The Wise Family of Installation System:
  Wise Solutions is the first installation system I've had to use in my career. Back then, Wise Installation System only came in one flavor because the operating system was pretty straight forward to get an application installed on it. Today, The wise family of products range from the simple installation system (copying DLL's and the Executable essentially with the ability to gether specific information needed to run the application after the installation is completed) all the way to the full fledged online installation package. Wise products work based on an advanced scripting installation language that offer a complete range of commands to write and retrieve information from the windows registry, create any and all custom dialogs your installation could ever need, allow to make copies of the files it may need to overwrite depending on copying conditions (very useful if the need to uninstall the application for whichever reason should occur). Prices vary with the different packages available.


• The InstallShield Family of Installation System:
  InstallShield is the second installation system I used. I think the preference of using Wise or InstallShield really depends on your personal experience. Me I prefer Wise because I had to get familiar with it first so anything else I used I tended to compare to how Wise does things. However I don't want to bring down InstallShield, it is a power family of products that is based on the steps needed to perform the installation rather than a scripting language and offers unique features and possibilities. I say give both of them a good try and pick one once you are familiar with both. I might even push things a bit and tell you that for a different type of application deployment scheme, one of these two packages, Wise or InstallShield might be better suited to perform that specific installation quicker than the other. I'll just let you decide for yourself.


• The NullSoft Scriptable Install System: [OpenSource]
  NullSoft Scriptable Install System is an OpenSource installation system that is also based on a scripting language. It offers a very straightforward and systematic approach to the software installation process which is the main reason why I included it in this list. The scripting language features commands to search for the target OS specific information and it also allows the creation of custom dialogs when the need for more specific information is needed in the installation process. All in all, this OpenSource installation system provides everything you'll need for all common installation needs. I was amazingly surprised to see such a tool offered as a free installation system, it really is that complete. So I wouldn't just ditch it out of the list in the count that it is free and OpenSource.

Tools like this really shorten the time to create an installation for your application even today. And for that reason alone, they should very seriously be considered, not just in commercial or professional applications but even if you are creating a game or other types of applications. Their usefulness has been proven time and time again over the years not just for me and my installation experiences, but for every single one of my collegues. You'll see why later in this document. For now, suffices to say that they are great tools that really fill a need that just wasn't met before.

Now that you know of the existence of these tools and all the time (and many headaches) they will save you. The time has come to officially start the preparations for the creation of an adequate installation system for your application. To do so, as I mentionned, you need to know what you are installing exaclty, and what you will be installing on as well. Let's take the time to see the special considerations to take.

SPECIAL INSTALLATION CONSIDERATIONS:

It's important to note, right from the start, that these considerations should apply to both commercial and professional application projects alike. Whenever you install an application on any user or client machine, you need to be sure of what exactly the installation is supposed to do as well as have some means of knowing what the installation process actually did once the installation is over. In a perfect world, the "what it should do" and "what it actually did" lists would be the same, everything that should have been there is, and nothing else, installed on the user's machine has been tempered with by your installation. Here we will list the danger zones that you need to watch out for before you actually start copying the files and registering DLL's and ActiveX controls should the need be. As per our project, once again the considerations will pertain to the Windows™ environment.

• The Presence Of An Older Version Of Your Application:
  It seems that today, people still believe that everything works like the good old DOS days. Today, upgrading to a newer version isn't as simple as replacing the executable file, at least not in most cases. Now you have to consider more than that when upgrading. Sometimes, if you didn't add any dependencies on the current upgrade, replacing the executable file could be enough. But many times, upgrades exists because there are changes in the dependencies and that can cause serious errors you never thought you'd have. So you need to be sure to know if there is a previous installation, and what it is exactly that you need to upgrade in that installation.


• Dynamic Link Libraries:
  The now infamouse DLL file. This is always a majour source of conflict, when you are unprepared. There's just so many of them on a typical user's machine that it's very hard, maybe even impossible, to know what DLL files belong to what application. Rest assured there is a simple way to avoid conflicts, but you really need to stop at the DLL issue seriously or you will ultimately create problems for your applications or other applications that were installed before your application was. The truth is you don't need to verify every single Dynamic Link Library that you will see. Only the ones that could interfere with those you need installed by your application.


• ActiveX Controls and Servers:
  The controls are files that have the OCX extension whilst server objects are DLL files of a different nature than what is usually attributed to a DLL file. The same conflicts that I explained for DLL files can also Occur for ActiveX Controls and COM objects. So, the same trick that works for DLL files will also work for OCX Files and Server Objects. As an added precaution, most commercially available OCX controls need a license to be usable in a development environment. If you are allowing those controls to be altered while the application is running (in the case of a form designing tool for example) then you'll need to contact the control vendors to get a valid distribution license for that control to your users.


• Database Management System:
  I am listing this one here in the case that you, for example, developed a database application and are trying to install it on a user's machine. I am assuming here, that the database you used was Microsoft Access™ because it is a good example of the type of situation you need to watch out for. If you created your database with Access 2000 for example, and the user only has Access 97, there may be a need for them to upgrade their database to a newer version. Likewise, if you application opens their database and you are using Access 2000 to open them, when the user tries to open his database with his older version of Access, he or she will get an error message because you have more than likely transformed the database to the newer version probably without knowing it. You need to be careful when dealing with this type of database and database engine to avoid these types of situation.


• The Windows Registry:
  Ah yes, the dreaded registry file. There's two things I've seen happen as far as the registry goes. The first is people often forget to enter the information they need in the registry. I'm not talking about registering things that you application uses, i'm talking other types of information that you code reads from the registry but your installation does not write. It's a common problem that can be very easily fixed. Whether you use one of the installation software I mentionned above or wether you created a custom installation software, you need to be sre that the values you need are present when the application is executed. People forget this quite often even if they know what they are reading from the registry by heart it's just a common mistake. You can create the values in the installation process or in the application is code (the first routine that gets callled when the program is executed is usually a good place).

These are the main problem areas that need special attention as far as installation is concerned. When you create your installation script or decide on the list of files you'll need to copy, you need to be careful about these areas. You can't be to careful when it comes to this because if you're not carefil the installation process can be responsible for many phone calls or support emails that didn't really need to happen if those precautions were taken. Let's take each of these danger zones again, but this time we'll look at what we need to be careful about.

• The Presence Of An Older Version Of Your Application:
  If you detect that there is a previous version of the application installed, you have a choice and that choice depends on which of the previous version you detected, and what changed since that older version that would need to be upgraded as far as copied files are concerned. Then you could either uninstall the old version (if no risk of lost of information or data is involved) or unregister everything that your application will be registering again and copy your files over the old files and let the rest of the installation do it's thing.You could be lucky and not have any conflict in registered components in which case you could simply add the new components that weren't there and the installation process would be finished right then and there.


• Dynamic Link Libraries:
  We are a bit lucky as far as DLLs are concerned, everyone that creates a DLL for their application tends to be very careful how they name it and rightfully so. All DLL files would typically go in the Window's System folder as it's called so you can imagine that no two names should be the same since Windows doesn't allow to files with the same name in any folder. Ultimately you could copy the DLL files right in the same folder as you are installing your application. But what if you select the Windows System folder and there is already a file with that name (usually because a previous version of your application was installed). The best thing you can do is detect the version of the DLL and copy your DLL only if it's newer (in version or in file date) than the one you found in the folder you'd be copying to. If you take the time to do that, you can't imagine all the problems you'll be saving yourself and your users/clients.


• ActiveX Controls and Servers:
  As I mentionned earlier, ActiveX Controls and Servers should be treated just like DLL files. Typically their destination folder is the Windows System folder as well and like DLL files you could decide to copy them to your application folder instead too. Typically the only reason you'd want to copy an OCX over an old one is, like DLL files if your OCX control is newer in version or in file date than the one already present in the folder. Of course if for any reason you had to revert to an older version of the OCX (to get back some functionality that was lost in the newer version) you best bet is to add the missing functionality to the newer version and recompile it. Ultimately you could unregister the OCX file, overwrite the user's OCX file with your older version and re-register the OCX if you really need to.


• Database Management System:
  The solution to this problem, taking our Microsoft Access™ example of above, is very different for commercial and professional application. In the case of a commercial application, the best thing to do is detect if the user has access at all on his system, if he does and it's an older version then you could warn them that the Access database you are creating cannot be opened by their version of Access. If it's the right version, there's nothing to do, if their version happens to be newer than the one you use, you should issue a warning ridding you of all responsibilities should they try to open your database with their newer version of Access. In the case of a professional application, you'll need to contact the resources and see if they can be in sinc with the version you are using in the code. Of course, when you are programming a project for a given client, you would probably find out long before the installation process that they do have Access or not and which version. You can then take care of this problem long before you attempt to install your application. You could synchronize your application to use their version of Access or let them know they will need to upgrade their Access long before you go ahead and install your application on their system.0


• The Windows Registry:
  The programmer that does the start of the application, the initialization process if you will is usually the one that knows what is being read from the registry. That person should, as soon as he writes code to read values from the registry, Make a note of what he is reading and what type of information he is expecting to be able to read. If he knows the installation system you use, he could even open a script up that does nothing but write the values he needs to the registry. If the information should be typed in from the user at the installation, he should create a quick for that has all the fields that he needs so the user can enter them right in the installation process. It's that simple to do yes. All installation creation software has an option of some sort to create a dialog that will get the needed information from the user and some script command or other option to save those values to the registry. To avoid all possible conflict between other applications' information in the registry, your values should be saved under their own branch in the registry. Just making sure that it's done is all you need to save your staff alot support questions.

As you can see, there's a possible and fairly easy solution to all problem areas. The biggest trick I can give you is to not copy a file if it doesn't need to be copied. You can't really tell yourself "I'll copy it just to be sure" because in many case, doing just that is what will make you unsure and ultimately cause you support time that you could have easily avoided by taking the right precautions. Another good trick is to copy the least amount of files as possible. This just help minimize the list of things to watch out for and shortens the analysis of a problem when it does occur. The less file the quicker you can go through them and find the problematic file and correct the situation.

In the case of a professional application, other concerns will be how each of the user's machine will be accessing the database. Usually, the users or clients company helps you by making sure that each user's mapped drive for the location where the database will be is called the same thing for everyone. There may be cases however where a user mapped his network drive as F: and another user, in the same company, has it's access through his G: drive for some reason. When that happens, you can know about it in advance and instead of just adding a static path to the registry, you could offer a dialog that let's the user select the path where the network database is located. Simple considerations like this at the installation process is easy to do and the time and issues it will save you is well worth the little extra effort to have a good installation process. Believe me, if you take the time to pay attention to these considerations properly and give yourself the time to acommodate for these circumstances appropriately, you'll thank yourself in the end.

Another thing that is gaining popularity fast today is online updates. This is a situation where the client has the option, from the application, to check for the presence of a newer version and could select to install the newly found version. For this all you need to know is what version the user currently has. Connect to the download area of your website and check the version of that file on the server. If they match, there is no need to upgrade. If they don't, you download the version from the server and overwrite your existing version (if all there is is the executable to upgrade). If the upgrade entails that other files be downloaded as well, you'll need to unregister those files, overwrite the old version on the user's machine and re-register the files. Aside the actual connection to the internet and the getting of the files you need, the rest is the same as a regular installation process. This means that the same precautions that i mentionned here will also be the same for an online update.

AND FINALLY WE ARE TRUELY FINISHED:

And this concludes our exhaustive series on commercial and professional application development. There was, once again alot of material to cover even in the installation process. Well my mentality stayed the same throughout this whole series. Preparation is the key to the success of a project of any size (but especially for the bigger scale applications). As far as the installation process goes, the best preparation you can have is if you take care of those precautions I mentionned and if you can get a list of files to copy along with their version numbers so you can compare them later in the installation process when you copy those files. To make a long story short, the more precautions you take, usually, the less problems you'll have throughout the installation process.

As always, I'm open to comments and suggestions. This series represents a general point of view on the development cycle from start to finish. Perhaps in your professional experience, you've experiences things that were quite different than I did, that's very possible. Maybe, in the analysis phase you used very different tolls or methods than those I have mentionned in this series. If this is the case, by all means, do let me know, the real purpose of this series is to be as generic as it can so you can apply what you've learned to your projects so if your company uses totally different tools or methods in their development cycle, I'd like to know about them so I can update this series to be as accurate as possible. I hope you found this series useful or insightful in some way and I hope you enjoyed reading it atleast as much as I enjoyed writing it.

MystikShadows
Stéphane Richard
srichard@adaworld.com