ALP Licensing Active Local Pages


LOCAL (Per-seat) licenses

Generate online
(Approve license request)

Check state


DEVELOPER licenses

Check state



Developer licenses are for life. Once received the license data can be included with any of your applications based on ALP and then ALP engine can be distributed with your application. Depending on the usage of the ALPInstall and ALPFrame you can completely hide the fact that your application is ALP driven.

The DEVELOPER licenses are intended for embedding into the applications, so they are not installed on a PC or imported into the registry. Instead they must be put in the file of the virtual ALP sites of your application(s). The license becomes a part of the application directory tree, whenever the application is moved, copied or deployed the license remains part of your application as like the other application specific ALP settings.

How to use

There are two ways to do so.

1.Using the ALP Settings shell extension: You can put the received file in a convenient place (for example in My Documents or on the desktop) and import it in each application you want to license. To do this you need to open the ALP Settings shell extension in that application - open the application root folder (in Windows Explorer), right click in the folder window and choose ALP Settings. Then go to the ALP Site settings and use the browse button to import the license data from the previously saved file (received from us). ALP Settings shell extension also presents some useful helper links - such as go to parent link which allows you to open the ALP site settings if you have clicked in a subfolder of the virtual ALP instead. If you have no ALP site created - create it first. Note that ALP site is almost the same as a virtual WEB site. It is important to create ALP sites for your applications even if they use only relative paths in their code. The ALP site like the virtual sites in the WEB servers isolates the application from the other applications almost completely. Without such isolation the applications may interfere with each other and the results are sometimes unpredictable, because they will depend on what the other ALP applications on the same machine do!

2.Manually: You receive the DEVELOPER license in an e-mail message. It is in the CERTIFICATION section of the attached sample file. files may contain other settings than the license data but they are rarely used so in most cases it is enough to place this file in the root directory of your application. A little example:
Let your application is in C:\works\myapp1 and its subdirectories - you may have several directories containing ASP pages for the different parts of the application, images and other files.
You put the file in the C:\works\myapp1 directory. This leads to two important consequences:
- The license is applied
- The directory is treated as a root of a virtual WEB site (or also called Virtual ALP site). This has effect to all the ASP/HTML functionality based on the site root term. In other words mapping /adir using Server.MapPath or #include virtual directive, or specifying a virtual URL in a link on the page will refer to a subdirectory of the directory containing the file.
The second effect can be reached without a license as well - by placing an empty file there.

Frequent mistakes:

Some users replace the file in the ALP install directory (e.g. SysDrive:\Program files\newobjects\ALP). This will be a mistake! This file has the same name and role but cannot contain licenses and it also contains the default settings vital for ALP. Therefore replacing it will render ALP unable to function!

Placing the file in a wrong location. When developing a WEB application you should consider its directory structure. In other words you should know where is its site root directory and so on. On IIS/PWS you configure a WEB site by configuring where is its root directory and sometimes you put several ASP applications in one virtual site - in different sub-directories/virtual directories. In ALP you have no limitations on how many virtual sites you have thus you can put each application in its own virtual site (by placing file in its root directory). Even if you want to keep your application compatible with IIS/PWS (e.g. designed to work in a subdirectory) you must define a site root point. In such cases you may want to put the file in a directory containing (may be) several sub-applications in its sub-directories. The license in this file will apply to them all.

To understand ALP you can just keep in mind that in contrast with IIS/PWS ALP keeps the WEB site structure and settings in the directory structure of the application and respectively in the file system. While IIS/PWS is one for the machine ALP applications and ALP engine may have many copies/(instances running) on the same machine and the best way to minimize your work and avoid any possibility to loss the structure definition is to keep it in the same place where the ASP files reside. Thus the very existence of files like or alp.application means for ALP that the directory where they are found is root of a virtual site ( or ASP application/session boundary point (alp.application). So there is no global metabase like in IIS/PWS - just files spread through your file system. Accessing an ALP URL implicitly refers to these files and ALP understands what the location is without need to check anything outside the application's directory tree.

ALP WEB site Copyright 2001-2005 newObjects []