Compatibility

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 options dialog.

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 application.

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.

Problems solving

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.