ASPCompiler Adopting ASP/VBS applications
ASP Compiler 1.1 documentation is under development. See also the examples.

Adopting ASP/VBS applications

This chapter is intended to give you some general ideas on how to use the ASPC better when compiling ASP and other VBScript applications to COM DLL(s).

First you should be aware of the fact that the compiled DLL cannot be changed at any time as the textual ASP page or another script. Thus you will benefit of every successful attempt to foresee the page/script usage in location/place different from the current one (if possible). Thinking for the compiled pages or scripts as for a libraries which will fit in several applications may bring some good ideas how to improve them and make them less dependent on data or circumstances specific for the current environment only. This process depends on you but in certain points you will need some help from the ASP Compiler. Thus we add some initial features and we will add more upon the developers requirements.


One of the most common features is ability to configure the compiled class instead of recompiling it for every single project. This feature is mentioned in other places in this documentation and is also demonstrated with a simple example (see configurable example in ASP samples). In short this is done using the Discard directive that allows certain statements to be exluded. Usually these are intended to set some hard-coded parameters in the source ASP page or script.

Why discard them? In most cases these statements set values to some of the global variables, used later to determine behavior or find required resources. Compiling the page/script makes impossible to change them later. This is not appropriate if the meaning of these values is for example path to an external resource. If the page/script will run correctly with every resource similar to the hard-coded one then why not leave this path in some kind of configuration or property? This is the reason to discard these statements - discarding them you need to add 1-2 lines in the loader file  to pass to the compiled code the required parameters before its execution.

An example:

Dim Param
'#! Discard
Param = "C:\file.txt"

Suppose the Param is used to determine a text file used by the script code in the page. Than you may need to change this file sometimes or make several copies of the script using a file with the same format but with different content. Then the discard directive will leave the global variable Param unset and you will need to set its value from the outside - in the loader file:

' Loader file code - omitted for brevity
proc.Param = "C:\anotherfile.txt"

See more details and samples on the Directives page and the ASPC samples.

One specific example is provided:

1. Example3: Configurable - Implements a page that needs some data to be set from the loader page before the execution of the main code. See the sample description - without editing the loader file you will receive errors caused by the missing data required by the compiled page. 

Library or packing functionality in a reusable component

Another interesting usage are the private libraries. Usually they are kept in include files or sometimes placed in every file again and again. The libraries may contain set of multipurpose routines or/and VBScript classes. With the evolution of such library the size of the include files grows and thus the time required for a particular page processing increases.

Well, ASPC will remove this problem automatically but why not pack these include files as a separate component(s) and use them instead? There are several different ways to achieve the target. Choice is entirely yours and we will explain the easiest way only:

Empty page

This is the easiest way - to create a minimal ASP page (without any output in it) which includes the desired library include files. the intention of that page will be initialization (if any is required). Compiling it (or a set of such page-includes combinations) a DLL will give you a DLL which contains the library routines as public Subs and Functions. To use it you will need to place the code from the generated loader file into the file which will use the library, probably rename the variable holding the object with something more descriptive and call its members in place of the calls to the functions and subs originally found in the include files. Also any variables declared globally will be accessible as properties.

If the library contains only Functions and Subs this will be enough and possible adjustments will be caused by the specific language requirements - such as public arrays which are not allowed and so on. But if you have some VBScript classes in your libraries you will need to use some of the ASPC directives in order to make them accessible for the outer code.See the Public directive and Createble directive (The second one is not recommended for developers with no experience with COM programming).

The purpose of the above directives is to make the objects of these classes accessible for the script using the library. But this will not make them creatable as like the other VBScript classes defined in the script! Thus you will need to make some additions to your library - responsible for their creation. See the Directives for an example how to do so. If you are still confused about the need of these additions remember the major facts about the compiled classes - they are COM classes implemented in a DLL and your script accesses them as COM objects. They cannot be created as a script specific objects - they are accessed and created in the manner typical for the other COM objects you are using in your application. But simple usage of CreateObject will not be enough because in nearly all the cases depend on some global variables, or another objects and thus they need initialization. This is the  reason to implement a creator function which creates new object of a certain class and ensures it has access to all the required data.

Two examples are provided:

1. Example7: Simple library - illustrates the above method

2. Example5: Users component - Implements class which is used in several pages.

Building COM components from plain scripts

As alternative to the Windows Script Components you can use ASPC to build your own ActiveX components. To do so you can use plain VBScript files and some of the ASPC directives. 

What are  the requirements:

  1. First of all these scripts must not use any global namespaces! You should delete all the namespaces in the project settings dialog. This will invoke errors if the script depends on some global namespaces and will help you to deal with them.
  2. It is recommended to not use global variables if possible. If they are required every object will need a call to a certain member before any other calls. This call should check/initialize the content of these variables. In this case you must supply this information with the component.
  3. The ideal solution will be enclosing all the code in VBScript classes and make them Creatable or Public as appropriate.
  4. If VBScript classes are used they should not depend on global variables or routines (except those declared with DLLGlobal directive).

If you need a complex cooperation between several objects you can still make them dependent on global routines or variables, but you will need to supply creation routines (global ones) for them. The compiler is able to reduce the required work, but such scenarios require average experience in COM programming

Two very simple examples are included with ASPC:

1. Example8: Simple component example - which implements a simple class from a VBScript file. Note it contains only one class!

2. Example9: Simple components 2 example - which implements two classes as VBScript classes and using directives makes them accessible from outside.

Every example has a description - use the samples shortcut from the program ASPC's program group in the start menu to reach them. Copyright 2001-2006 newObjects [ ]