ALP DEVELOPER Licenses
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 alp.site 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 alp.site 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 alp.site 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 alp.site file. Alp.site 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 alp.site 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 alp.site file.
The second effect can be reached without a license as well - by placing an empty alp.site file there.
Frequent mistakes:
Some users replace the alp.site 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 alp.site 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 alp.site 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 alp.site file in a directory containing (may be) several sub-applications in its
sub-directories. The license in this alp.site 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 alp.site or alp.application means for ALP that the directory where
they are found is root of a virtual site (alp.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.
|
