newObjects Active Local Pages offers many different ways for application deployment. They can vary from typical setup solutions to pure autorun solutions where everything runs on-the-fly without registering anything with the system. There are combined techniques, opportunities for custom solutions and so on. This chapter is intended to point you where to look for more information. 

Open programming environment that is still easy to deploy. 

ALP supports ASP, CGI and some other technologies from the WEB programming world, but gives them ability to run on desktops just like other desktop applications without any need of network features for the purpose. No firewalls are problem, nor the network configuration is of any importance. Furthermore both ASP and CGI are open environments that allow the developer combine his own code, ALP engine and 3-d party components or utilities. This makes it infinitely extendable, but also calls for the developer attention, because the developer must be aware of what and how is used in the application, if it is a 3-d party component or utility, what are its requirements and what must be distributed with the applications and the ALP engine in order to make these 3-d party elements work correctly on all the targeted machines.

So, the main differences between the classic WEB programming and the ALP programming is the deployment. While the classic WEB applications work on a few well-known machines, the ALP applications are distributed to different machines which may have different settings, available components and OS specifics. We created ALP to be binary compatible with all the desktop Windows versions beginning with Windows 95 (including it) with the only requirement - IE 4 or later installed. However any component you use - that is not part of the ALP package - is a bit of code you must consider carefully.

The most important traps

• Versions of popular components. Several system components, such as ADO became so typical for ASP usage that many developers even consider them part of the ASP technology. This is not true and you must never forget that, for example ADO, and all the underlying components it needs are not part of the ASP itself. When you use such a popular component you must determine what kind of features you use, what is the minimal version of the component that supports them and what are the component's own dependencies. This will effectively define where your application will work and where it will need a system update first.
• Availability of components considered part of the system. A good example is the FSO (FileSystemObject) which is considered by most developers as part of the ASP or the script language. Again, it is not! The different Windows versions have different "default install" behavior. On some systems (mostly Windows 9X/ME) this object is not pre-installed by default. Counting on its existence without means to check that it is actually installed may cause your application to fail on such systems.
• Scripting languages version. Althoug the JScript and VBScript are available on all the desktop Windows OS-es where IE4 or later is installed, their version may differ. For example on old systems (prior to Windows 2000) you may meet versions from 3.0 to 5.6 depending on what the user has done with the system. Determining the scripting language version required by your application may be crucial if you want to support old systems. You should check and provide update in case the check fails. However, this issue is a minor one, because most ASP applications stick to VBScript 3.0 features and if they use something from the later versions it is most often the Regular Expression object which is available natively in VBScript from version 5.0.
• 3-d party components OS compatibility. Many developers are tempted to use with ALP components built for the classic ASP. Knowing that the classic ASP is most often used on Windows NT/2k/XP/2003 machines many component developers are building their components for these platforms only. There could be many specifics, but in most cases they are obvious from the features supplied by the component and one would be able to recognize NT specific component easily (for example a component that manages file system security is obviously not a component that will run on Windows 9X). The catch is in another place - some components are compiled for UNICODE. This certainly minimizes the component developer efforts in dealing with strings and many COM developers are tempted by it. The point is, that such components will not work on Windows 9X/ME even if their functionality is something suitable for such a platform. If you are going to target Windows 9X/ME be sure to check any 3-d party component for compatibility. 
• Autoruns. The autoruns are applications designed to work in difficult scenarios. An autorun application is not only an application running from a CD plugged into the CD/DVD drive, but can be also any application designed to work on-the-fly without initial installation and component registrations. Therefore pure autorun is every application that counts only on the features packed with it and the core system features available everywhere. Obviously such an application needs more attention than an application which will be distributed with an installer. The installed applications have chance to check the system, offer updates or install them automatically. On the other hand the autorun applications aim at avoiding such a need at every possible cost. Most 3-d party COM components are unable to meet the needs of an autorun because they need registration with the system in order to function correctly. Counting on visual enhancements such as macromedia flash, particular Java machine and others will render such an application incompatible with the autorun goals. When building an autorun be aware that the machines around you are used by developers and designers, while your clients most likely have quite different habits and experience. Although the latest macromedia flash or Sun Java may be common for the machines in your workplace it is not so on the end-user machines. You can count on them only if you target very narrow public with well known habits and experience or internal company distribution where the software is managed in well-known manner. Failing to estimate the consequences may require you pack with the application too many updates. This may cause the application look unsafe or unacceptable for some of the clients who are scared of installing so much software at once.

ALP Run-time library

ALP ships with rich run-time library of COM components serving the major ALP development technique - the ASP compatible pages. The library contains embedded database, file system access components, networking components and much more. In most cases you can use it instead of the components usually associated with the classic ASP. Furthermore the library can be freely installed on an IIS machine to provide cross-compatibility. Therefore using the ALP run-time library will not render your application incompatible with IIS if that is important for you. All you will need to do is install the library on the IIS machine (Download AXPack1 family and install).

Most of the traps listed above can be easily avoided if you use the ALP Run-time library instead of other components providing the same functionality. This includes the autoruns as well - the ALP Run-time library conforms with the autorun requirements and is binary compatible with all the desktop Windows platforms - 9X/ME/NT4/2k/XP/2003 and later.

What tools to use for installation and autoruns.

First of all you may want to take a look at the deployment samples at http://www.newobjects.com/product.asp?Category=57&Story=310 

The installation based solutions may use the ALPInstall utility. It is simple but provides enough features for the most applications - even non-ALP applications. It is driven by a configuration file you can adapt from one of the sample deployment packages.

The autorun based solutions use ALPFrame browser as core element. In autorun scenarios ALPFrame plays more important role than just a browser. You need to configure more options which include the COM DLL list with the classes implemented in them. This is needed because the system is not expected to know about these components. As like the installed solutions, the online sample autorun distributions can be adapted to your application on the price of a few changes and replacing the dummy application in them you yours.

Using other installation solutions is possible. The easiest way to do so is to use them for everything except the ALP itself and run the ALP setup using the minimal ALP distribution for example. This will save you any efforts to integrate the ALP core files installation with the other setup. If you want to alter the look of the ALP redistribution package setup you can still do so by changing the texts and the logos in its setup and packing it back to a self-extract setup or leaving it in a separate directory (if you are using a CD/DVD there is no point in packing it - there should be enough space for everything).

In some specific cases you may prefer to do part of the installation yourself. This is also possible because using the ALP Run-time library you can copy files, register components, create shortcuts and do whatever a setup would need. Thus if you want to build a custom setup solution you can do that in ASP. You can start your custom setup solution as a simple ALP autorun or using a minimal install - just enough to start your ASP files that will do the rest of the work. Although this approach looks a bit untypical it can be the best way for complicated setups where ALPInstall, nor any other setup solution would give you everything you want. For example this may be useful for applications that need to integrate with other software products in corporate environments (MS Office, Microsoft server products like Exchange, database and other servers, 3-d party products and so on). In such case you may want to perform configuration changes to these products, establish some relationships with them (by saving some location and configuration data during the setup and use it later from the application). Such a task may be quite complicated in offices where the IT infrastructure is complex and integrated. Doing this from any setup solution would be a headache compared to ASP with its ability to interact easily with all the COM objects exposed by these products.