Deployment is everything which you do to get your components installed. This section will only consider deployment of a so-called “desktop” application, in which all components are installed on the same computer. Please consult the basic rules for deployment first.
Find out which components you use.
In general, it is impossible to automate the process of finding which components are being used by your application. This may come as a surprise but it is a logical consequence of the technology we know as ActiveX. I’ll first get a little deeper into that (but not too deep).
Whether you use “CreateObject” or “New” to create instances of classes, COM doesn’t really care. COM calls a system function with a certain 128-bit number (the CLSID), to create an instance of a certain class. COM doesn’t know where it can actually find the class until it has a look in the registry (under H_KEY_CLASSES_ROOT\CLS_ID). There COM will find out where the class you wanted (the actual DLL or EXE - whether it is on the local machine or on a remote machine). You compiled DLL (or other) only contains the CLSID, not the path to the component that defines it. The Idea of COM was that an application should not care where a certain component was installed. If it had the correct CLSID, COM would look up the necessary information and do whatever is necessary.
As a “proof” that you can’t write an application that “knows” which other activeX components you use, I’ll use a variation of the Turing halting problem I once learned. The proof is simple. Suppose you have a procedure that can provide you with a list of such components. We’ll show that it leads to a contradiction and that you are thus not able to construct such a tool (in general).
If getAllActiveXComponentsUsedByMe.Contains (“ABC.DEF”) then
So from the moment our so-called procedure says we aren’t going to use a certain component, we start using it thereby making the procedure lie. On the other hand, if the procedure says we are going to use it, we don’t use thereby making the procedure tell a lie once again.
OK, much ado about nothing. So there is no automatic procedure for this. Then how can I get my list of components ? The easiest answer is : look at the “references” and “components” tabs in your project. They will tell you more. They will provide you with a list of DLLs and OCXes that your project might need. For each of these, you need to search for “dependencies” in turn.
So for your own applications, it is in general quite easy to get a list of required subcomponents. But how about tirth-party components ? Or the core VB components ? Luckily for us, most of those components are accompanied by a so-called “.DEP” file. This file, which looks like a simple INI-files contains dependency information about the component. Here is a sample of the MSCAL.DEP file on my machine :
; Dependency file for setup wizards.
So you see you can find the version inside, where the thing is supposed to be installed and whether it is a self-registring thing. The following component utilizes the “uses” possibilities :(MSBIND.DEP)
; Dependency file for setup wizards.
This file is a little more complicated but you see that msBind needs two other DLLs.
Generating .DEP files for you own components.
This section has been put into a separate page because it took up to much space, whil it is only relevant to the package and deployment wizard.
Create a setup.
Once you have a list of all your components and you also have the .DEP files, you can generate a setup for your application. You will need to check the list of components for your application carefully to make sure you don’t forget one. Now you are ready to create a complete setup for your application.
I myself currently have the joy experiencing that the application we wrote becomes “established”. The fact that our customers (on average) are pleased with the application, gives rise to new demands and opportunities.
We already have demands for building applications that have the same functionality as our previous application but with much less possibilities. These spin-off applications should work just like our main application but focus other user groups.
We could have just adapted our main application to work in different “modes”. We didn’t do this for several reasons. The most important ones are that it would slow down every user (since all code needs to discriminate between the user catageories) and it would make existing code more complex. We therefore created several “main” applications. The user is free to install any of them. Some users will install app1 and app2, while others really only need app3.
The OO foundations of our application have made it a snap to create these applications. The objects are already there. We just need to either adapt the user interface or change the logic in which methods are called. The real problem, however is that we want to deploy all of these applications separately.
To do this, we need to create several setups (we use InstallShield) for each application in the product line. Each of these setups has to work in concert with the others because we are dealing with activeX stuff that is hard to deny (see pitfalls).
Now how can these “setups” work in concert ? My answer is simple. Divide all components you have to install for each of all the applications in your product line into several “categories”. A category is a set of components that are always installed together. Examples of categories are “VB Runtime files”, “DAO database files”, “BDE files”, “Windows components”, “Windows uncommon components”, “Reporting components”, “Company XYZ Core components”, “Company XYZ Financial components”, ... Try to avoid the degenerate case in which each category contains only one component. Try to come up with names that make sense to your customers.
For each of these categories, try to create a separate “setup”. Find our what information the “sub-setup” needs and define clearly how you will get to this information. P.E. : the “Company XYZ Financial Components” needs to know where the main application is installed because it needs to copy a database file there (if it doesn’t already exist). You might stipulate that it will get that information from the registry in H_KEY_LOCAL_MACHINE\Software\Company XYZ\MainAppPath. The subsetup will simply check the value from the registry and abort if it can’t find this entry.
An application setup might ask the user for several paths and other options. It writes these options to the registry and then launches the “category” setups in turn.
The benefit of a “category setup” is that it enables you to make the category setups separately available on a download page on the web. With this download page, a user can upgrade only the categories he needs.
Those are my 2 cents on deployment. It’s a huge topic and I’m sure these recommendations are not complete. However, they are better than nothing.
[COM for VB]
|Site updated : Monday, February 17, 2003|