Script language support
ASP Compiler supports all the VBScript 5.0 features. This
includes VBScript classes, With statements, constant definitions
etc. Preprocessing to VB eliminates most of the possible
incompatibilities, but a some rules can be defined anyway:
Compose your script/page as something which will work without
compilation. ASPC expects VBScript rules to be obeyed by the
source code and syntax constructions you know as allowed in VB but
not in VBScript will cause errors. Keep in mind ASPC makes full
syntax analysis and it assumes the source language is VBScript.
None of the statements is copied without rebuilding it even if
visually no differences are present.
The ":" (colon) statement delimiter is not
supported. Pages/scripts using it may cause errors. By default
ASPC raises an error when the colon is found, you can override
this behavior on your risk by altering the configuration. But we
do not suggest this change it may cause unexpected results and
wrong functionality of the resulting component.
ASPC can be used as ASP pre-processor for script files not
intended to be executed as ASP pages. For example some utility
classes and components for non-WEB applications with some WEB
related features may benefit of such style of writing. In such
case use the loader ASP file generated as an example how to create
and initialize the environment objects. This is advanced technique
and some developers may want to pass to such components objects
which have no equivalent in ASP. But note: the content outside
<% %> tags will be converted to Request Write calls, thus
you will need to supply such object with Write method which
accepts a string as parameter. It is possible to configure the
project to place another call instead of Response.Write - see project
Option explicit is always ignored. Instead compiler issues
warning messages for the non-declared variables. If it is possible
and you have enough time it is recommended to declare all the
variables this will ensure the compiled module will have the
expected behavior. While processing variable declarations are the
key which helps the compiler to determine the scope of the
variables. Without them, in some rare cases, the scope can be
determined incorrectly. If you receive some warnings of this type
and you have some doubts about the functionality this is the
recommended first step before any further debugging.
Execute, ExecuteGlobal and Eval statements and function are
not supported. They are intended to execute script source
in-place which is not applicable for a compiled component. An
implementation of such features is possible but it will be a good
source for user mistakes and will leave parts of the script in
source (text) form. Such an implementation will require creation
of external script engines and tight connection between them and
the compiled component. This will require additional operations at
run time and may lead to decreased performance - in some cases
slower than the plain script version of the page/script! Thus we
decided to leave them unsupported in the current version.
Input format support
Although ASP Compiler is named as something related to ASP only
it supports other formats as well. Future versions may add support
for additional formats and thus extend its appliance area.
Version 1.0 supports ASP normal pages (and not global.asa) with
<% %> and <%= %> tags. The "Language" ASP
option is checked (<% @ Language = SomeLanguageName ) and if it
exist but is not VBScript an error will be issued. If language does
not exist VBScript is assumed. Other options are not supported.
Version 1.0 supports plain scripts. Text files containing
VBScript only. Such files are used by huge amount of popular and
custom script hosts. Some of them are extensions of complex
applications (such as Office applications), some of them are
integral part of products implemented as combination of COM
components and scripts driving them. One of the most popular ones is
the Windows Scripting Host. These hosts have different object models
and you will need to configure the project with the set of the
namespaces for the particular host.
Version 1.0 also supports as a side addition SSI with include
directives only. This allows conversion of such files to plain HTML
files without dependencies which can be viewed in the browser
without need of WEB server or other background processing
What to expect later? Processing is done by the EMBDPRSR.SLL
which is the core component in ASPC. It is a simple COM component
which drives a huge set of parser components able to pre-process a
file to a syntax tree of collections. By adding more components or
extending the existing ones support can be added for more formats
and this will require only minor changes in the other parts of ASPC.
The evolution of ASPC IDE's user interface will follow the
requirements raised by such kind of features.
Compatibility of the compiled classes
What can be done with the resulting DLL of page(s)/script(s)
processing? For some additional details on how the generated classes
are used see the "What replaces the ASP page/VBScript file".
In general the COM classes generated do not depend on specific host
features or specific rear OS additions other than general COM
automation support and of course VB runtime DLL (see also deployment).
Therefore the classes can be used with any host which supplies the
required environment for the source script. This means for example
an ASP page which runs under IIS, but also run under some other ASP
simulators/servers can be compiled and executed under all of them -
as long as the original page is able to run under their limitations
and specific requirements. Avoiding the usage of IIS specific
interfaces or MTX/COM+ specific APIs, components need some
additional initialization made automatically in the loader files,
but this makes them independent of the specific features not
available in all the scripting environments.
Potential problems are possible when porting a script from one
environment to another environment semi-compatible with the first
one. A good example are the various ASP hosts - WEB servers
supporting ASP on their own, pluggable protocols executing ASP
locally in the browser etc. All of them support the most popular ASP
features but there are unsupported ones and some minor
differences in default type conversions and so on. In all these
cases the problems available for the script/page being ported will
be available also for the compiled component. In fact ASPC will not
add, nor remove any problems. As a recommendation we suggest porting
tasks to be started with porting the source pages and compiling the
successful port to the target environment.
Please inform us for any problem you have with compatibility and
language and formats support. We will correct any problems found. If
it is not possible to be done shortly because of some reason we will
publish the possible walk around.
Additionally we will be glad to add warning/error messages which
help to the developers to perform some tasks or avoid potential
problems. Don't think you are going to lose our time - your problem
may become a good reason for a new feature in the next versions.