Deployment

When you are creating a DLL from your ASP pages or another scripts VB automatically registers the DLL in the system registry. Besides VB you have the VB runtime DLL on your system, thus on the same system your DLL will run without need to do something special. But when moving the DLL and other files to another system you will need to check and prepare the target environment for them.

Dependencies overview

The resulting DLL depends on the VB runtime DLL. Therefore your first task should be installation of the mentioned DLL on the target system. Its name is: MSVBVM60.DLL. You can find it in the system directory. The VB run-tie DLL in turn depends on the COM DLLs, but you can suppose they are OK on every machine with Windows 98 or later or Windows NT4 or later installed. Thus the above DLL will be enough for redistribution purposes in these cases.

How to install it? If you are deploying the components to a server it will be more convenient to place this DLL into the server's system directory (usually subdirectory of the Windows directory - named system32). If you are doing this manually check if the DLL already exists and if so - see if the existing version is not a newer one and if that is a true leave it intact.

The system searches for the DLL in the following manner - in the directory containing the DLL (In this case your component DLL), if not found then in the paths specified by the system's PATH variable, which includes the system directory. Therefore you have an alternative - to put the MSVBVM60.DLL and all the DLLs you create in one directory.

Additional dependencies will differ according to the application specifics. They will be the same as for the raw ASP or other VBScript. Usually they are the components used in the application -such as ADO, FilesystemObject or any other component used. You will need to install and register them on the target system.

Older systems may need additional update. This is mostly problem for Windows 95 or sometimes Windows 98 (first edition). In most cases you may assume Internet Explorer 4.01 or later availability means "no problem". In other cases you may need to update OLE automation libraries. you can do so by using the DCOM95 update available from Microsoft (also distributed with IE) or use the capabilities of an install program which has special support for Visual Basic.

How to perform

Manually

Most servers are managed manually - in this case you will need to copy the MSVBVM60.DLL to the server. The best place will be the system directory. Check if it already exist (it can be installed by another application) and if so check the versions and keep the newer file.

Make appropriate folders for your DLLs - the folders should not be accessible for the world. You will need to allow the system to access them - e.g. The folders security attributes should be set to full access for the Administrators and Local System. If you plan a specific usage which requires another security policy grant access to the appropriate NT accounts/groups. After all copy the DLLs there and register them using the regsvr32 utility.

Regsvr32 utility is in the system directory. It accepts as command line parameter the path to the DLL to be registered as COM server. The most convenient way to use it is to open a Command prompt window cd to the directory containing the DLL(s) and type for example: regsvr32 mydll.dll if the DLL name is mydll.dll. Repeat this step for all the DLLs.

Later when updating the DLL(s) you will need to replace them with the newer versions. Re-registration can be avoided but it is recommended to use regsvr32 again. Note the DLL may be locked because it is currently loaded by IIS or another application. You may need to stop the applications using the former version of the DLL in order to replace it. For the IIS case you will need to stop and restart WWW service or the entire IIS.

You will need also to deploy the external components used by your application - see their documentation for details. Usually they are COM DLL servers which must be registered using the regsvr32 utility - as like your own components.

If the application will run on many servers or if it is for a desktop usage (WSH script or ASP running under ALP) it will be better to prepare setup for your components. Depending on the other parts of the application different setup programs can be used. They will take care for the version checking of the DLLs, thus the manual checking mentioned above will not be required, but you should spare some time to fill the version info for your applications (see the Version info dialog box in ASPC IDE). This will allow safe replacement of the older versions of your DLLs. Failing to do so may cause difficulties and side problems during and after the installation.

Some directions. None of the described products below is part of the ASP Compiler. This information is placed here only in order to help you to find some solution for the installation. You can choose any install utility which is able to install COM DLLs and perform version checking.

On the Microsoft Visual Studio CD you can find a light version of InstallShiled which can be used to deploy DLLs generated using the ASP Compiler,  the VB run time library and additional components.

The installer used by ASP Compiler and newObjects Active Local Pages is not published as separate product but information about it can be found in the ALP documentation (shareware version contains it too). It is a light weight installer and a new version will be published as freeware separate product. It is freeware but requires editing of the install configuration files. Recommended if you are building DLLs for ALP applications.

In case of small number of machines in one office you can use .bat files to copy and register the DLLs, but this will not include the version checking phase. If you are sure you can keep the track of the versions this will be enough good for you.

In all of those cases if you afraid to put the MSVBVM60.DLL in the system directory you can install it in one directory together with the compiled DLLs. Of course this will cost a little more space on the hard drive.

Additional questions and answers

Q: Is it meaningful to place the compiled DLLs in a certain location?
A: No. Once compiled and then registered on the machine the DLLs are loaded through the system registry and their location has no meaning.

Q: How the compiled ASP DLLs fit in my application?
A: You are using the loader ASP files  generated by the ASP Compiler. When deploying components you need to place these files in your WEB site in the locations originally occupied by the source ASP files. The other resources such as images, MDB files should reside in the same locations. You can safely remove the include files which are part of the compiled DLLs only. Anyway it is recommended to keep copy of the original site and not perform the compilation in-place - a little human mistake may cause replacement of the source files with the loader files!

Q: How to copy the loader ASP files?
A: ASPC generates a directory tree in the output directory which contains the ASP loader files. ASPC duplicates the directory structure of the source directory thus you can copy them by copying the entire output tree to the site/application. In all cases keeping one development copy of the site - used also as source directory for the ASPC project and another copy of the site where the compiled versions will work will be convenient and protected from human mistakes (replacement of the source files, removing the sources and so on).

Q: Is it required to include ASP loader files in the installation?
A: If you are using an installation program you may want to include them in the files list together with the other resources used in the pages (such as images). Check if the installation program supports some easy way to configure directory tree copy operation. If it supports it - you can instruct it to copy the output directory to the destination location (site). None of the ASP files and most of the other resource have version information. Date/time checking is not very informative thus if an older version already exists you will have only choice - to replace it. Check if this can be a problem - for example it will be dangerous to replace existing data base which was already filled with some new data during the site/application life. In such cases you may need to implement additional code to upgrade older resources. For example you may need new tables to be created in the database. This cannot be solved by the install programs themselves, but you can implement this tasks in utility to be executed after the setup.