Using the compiled modules.
What replaces the compiled ASP pages and other scripts?
This chapter is about the results of the processing options
concerning ASP or other VBScript files. If you are meeting with
ASPC for the first time it is recommended to take a look at the
available processing options first.
ASPC processes series of script files or/and ASP pages. In most
cases these files are part of some project/application/site. We
decided to make the output easy for deployment - manual or
automatic. Thus ASPC output can be separated in two categories:
- Files related to the DLL creation
- Files intended to replace the source files.
The first category - VB class modules and other files
are stored in one directory and they are subject of the
developer's interest only in rear situations such as some bug
tracing tasks. Thus they they are stored in manner more convenient
to the Microsoft Visual Basic compiler and in second place for
The second category - replacement files are called in
this documentation "loader"
files. Their purpose is replacement of the input/original files in
the WEB site or another scripting application by using the
compiled COM class generated over the first category of files.
These files are subject of direct interest for the developers and
also the developer may need to edit some of them, make their
copies and so on - depending on the application purpose and
To simplify their usage and keep the original application
structure ASPC stores them in a directory structure equal to the
original structure found under the source folder. This is the
reason for the settings you need to supply in the project
settings. You supply there source and output directory - ASPC
processes the files you specify from the subtree under the source
folder and outputs the loader files for them under the output
folder in the same relative locations. Example:
If your source folder is C:\src and one of the processed
files is C:\src\dir1\dir2\one.asp and the output directory
is C:\out then the loader file for the processed ASP page
will be C:\out\dir1\dir2\one.asp .
Of course if you have another directories and files in the
source tree, but they are not configured with the project they
will not be processed and folders for them will not be created.
Thus you have the choice to configure everything in the project or
combine it with a little manual work as appropriate.
In most cases the output directory tree can be just copied to the
WEB site (assuming ASP site processing) and only the generated
component DLL will need to be copied separately and registered in
order to run the site in compiled form.
Loader files are simple script files stored in the same format as
their sources - e.g. if ASP file is processed - the loader will be
an ASP file, if plain .vbs file is processed - plain .vbs loader
file will be generated. Their job is to load and initialize the
appropriate component from the DLL and invoke it. One example file:
Set proc = Server.CreateObject("ASPHello.cls2HelloWorld_VBScript_asp")
Set proc.Application = Application
Set proc.Request = Request
Set proc.Response = Response
Set proc.Server = Server
Set proc.Session = Session
As you can see the loader creates an object, sets its properties
and finally calls the predefined Sub created by the compiler. This
Sub implements the page behavior. Thus the loader
file invokes the compiled implementation of your page passing the
environment objects (ASP objects in this example) to it - by setting
the appropriate properties of the object. You are able to move this
file to any location where the original page will be appropriate and
functional. Of course the only additional requirement is the DLL
registration on the machine.
The samples supplied with the compiler show non-standard usage.
In such case loader file may need some changes or can be used as an
example how to add the compiled page functionality to another
non-compiled page. Special interest for many developers will be
ability to reuse one page in different sites/applications. By using
the Discard directive some
settings can be set from outside - which means from the loader file.
Usually page reuse is done by copying the page to the other
application and some minimal changes in the code are enough to adopt
it. This is not the best way for the compiled pages and causes too
many similar components to be registered on the same system. Leaving
some of the global variable assignments for the outside world is in
fact conversion to public properties of the compiled class. Thus the
mentioned technique allows the developer to make different copies of
the loader files. Adding manually a few lines in these files
configures the page for the requirements of the particular
a-application. This is mostly subject of the application planning -
see the example "configurable" and its description in the
main Readme.htm file in the samples directory.