• Using the Server.CreateObject
• Using the internal script language routines such as CreateObject (in VBScript) and new ActiveXObject (in JScript).
• Using the <OBJECT RUNAT=SERVER ... > tags.

We strongly recommend usage of the Server.CreateObject (or OBJECT tag where suitable) instead of the language internal routines. In both classic ASP and ALP this method provides additional functionality that allows the object bind with the ASP engine (if it supports this feature) and some internal adjustments are made that are bypassed if you use the language specific routines. Note that the script language engines are universal and not especially designed for classic ASP or ALP either. So the language engines are not aware of the extended features the ASP environment may offer.

Differences between ALP and classic ASP. In ALP you can use both ClassID or ProgID as parameter for the Server.CreateObject. Also note that using the COM aliases you can define application specific ProgID to ClassID mappings (for example shorter ID-s for the frequently used objects) - see the ScriptGen configuration and the ALP shell extensions. 

<%
Dim sf,fld
Set sf = Server.CreateObject("newObjects.utilctls.SFMain")
Set fld = sf.OpenDirectory(Server.MapPath("."))
%>
Folder name: <%= fld.Name %><BR>
Date created: <%= fld.Stats.Created %><BR>
Date modified: <%= fld.Stats.Modified %><BR>
Date accessd: <%= fld.Stats.Accessed %><BR>

The above example (VBScript) shows how to create SFMain object from the ALP run-time library and use it to show some information about the current folder. Info: SFMain is much like FileSystemObject but is more universal - supports not only files. The above CreateObject line can be changed to:

Set sf = Server.CreateObject("{F86AC6C2-5578-4AE8-808A-DC5DAA78082A}")

and in ALP the sample will work all the same, but note that in classic ASP only ProgID-s can be used. Therefore you should use COM aliases to avoid specifying raw ClassID and thus keep compatibility with the classic ASP.

Autorun and other on-the-fly scenarios. ALP with the ALPFrame viewer can be configured to run without need to be installed first - i.e. you can just put the files (the ALP binaries, configuration and the application ASP files) and then open the ALPFrame.exe and have it working. This is one of the most popular usages of the ALP product and it requires a bit more attention then the usual "installed" scenarios. As the Windows COM library refers to the system registry in order to map first ProgID to ClassID and then it to the DLL where the object is implemented, in autorun scenarios it is most likely that this information will not be known for the system. E.g. there is no installation that has registered the ALP and any 3-d party components in the system's registry. So, ALP carries part of the Windows COM library tasks on its own. In the ALPFrame configuration (see the LIBRARIES section) you can list ClassID-s and the DLL in which the corresponding classes are implemented. From that source ALPFrame creates in-memory registry for those classes and allows the COM system find them when referred. As you will notice there is no ProgID information in the ALPFrame configuration, so to define also ProgID-s for the listed classes you need to add COM aliases for them in the ScriptGen configuration for the application (in the alp.application file in your application directory tree) see ScriptGen configuration and the ALP shell extensions.

The deployment samples and packages are by-default distributed with the classes from the ALP run-time library already configured. Also the COM aliases form in the ALP settings shell extension offer presets that allow you add ProgID for all the classes in one step.

In autorun/on-the-fly scenarios there are some limitations - the above technique requires a little support from the COM classes themselves. The need of that specific support is a result of an unfortunate practice but anyway it is a fact that must be considered. The problem is that the implementations (the DLL-s) most often require their type libraries to be loaded. Most of the development tools capable of creating COM DLL produce code that loads these type libraries by referring the registry entries for them even if the type library is contained in the DLL's resources. This problem could be overcame in C++ but it is hardly possible to do anything in VB for example. Thus the DLL build after this popular practice will not be able to run correctly even if their ClassID and/or ProgrID are registered with ALP. The effect is that any call to them ends up with an error.

What is the impact of this limitation? In general the small and fast installations are popular enough today so very often if many components not capable of working in such a scenario can be installed before the application starts. The users will not be startled if such a step is required. However quite a lot can be achieved in autorun mode because in the most cases the applications that really need to be of "autorun" type need only a few external components - ADO for example. Most of the other tasks can be performed using components from the ALP run-time library which is fully capable and designed to run in autorun/on-the-fly scenarios. For more detailed information see the ALP applications deployment chapters.

The above limitations are not in effect when you deploy the applications, ALP and any additional components needed using setup solutions.