The work ASPC does could be separated in two phases:

Phase 1: ASP/HTML pre-processing. Depending on the processing options for the file this could mean converting to plain VBScript, converting to another ASP, generation of many ASP/HTML files from a template and so on. This phase includes also the Compile Time Scripting (CTS) feature (version 1.1). CTS allows the developer to program the compiler - e.g. to extend it and implement custom pre-processing. CTS is a multipurpose feature and the compiler's IDE includes the CTS Library tool. CTS Library is a way to organize the Compile Time Scripts, pack them with short documentation, configuration dialog etc. Packed CTS also can be distributed to other machine (s) and installed in the library.

Phase 2: Pre-compilation of prepared VBScript to Microsoft Visual Basic (VB) project and COM DLL after making the project with VB. In case of ASP pages this phase uses the result of the Phase 1. The core functionality of ASPC covers VBScript translation to VB  Microsoft Visual Basic 6.0 is used to compile the resulting files to a COM DLL - Service pack 3 for VB 6 is recommended but not required. ASPC supports almost all of the VBScript 5.0 features including Class-es, With statements, constants and more. 

Processing of a certain file may need internally the both phases or only one of them - for example a plain VBScript file for Windows Scripting Host would be directly converted to VB, but an ASP page must be prepared first (Phase1) - converted to plain VBScript where all the HTML tags are converted to Response.Write statements, ASP tags stripped and optionally pre-processed and modified by custom CTS. The developer needs to be aware of the phases only if he/she is  going to write CTS - simple tasks like compiling ASP to DLL require only setting the option for the file (e.g. telling the compiler what to do with this file). Thus the compiler could be used for various purposes - alone or in combination and by various users - beginners and gurus. 

Read more about:

Compilation process of an ASP page to VB and COM DLL. Assuming no CTS is used (for simple explaination).

More about phase 1 - HTML/ASP pre-compilation and interaction with the Compile Time Scripts.

ASPC uses project to list all the files that must be processed together with the global and file specific options. Each file in the project could be different - for example you may have a project which contains few ASP files that will be compiled to a DLL and few other files which will be processed by a CTS to produce set of plain HTML pages from a data base on the local machine.  

What ASPC does with VBScript language? When compiling to VB and then to COM DLL ASPC solves the problems caused by the context and syntax differences between VBScript and VB. Although VBScript is very similar to VB there are many syntax differences and much more differences in the program structure. While a VBScript file (ASP page for example) is more likely a program executed sequentially from the beginning to the end, the COM DLL is a server of services called from outside. There is no way to say what is the beginning and what is the end of a COM DLL but these terms are clear in case of ASP page or other script. Thus the compiler reorders the input file, modifies its code to match the VB and COM requirements and also produces a loader ASP or plain VBScript file (s) that uses the generated DLL and classes in it. Depending on what is compiled the loader file replaces the original ASP page or the other script file. It acts as a stub for the original file and also could be used to pass some constant parameters to the compiled COM object (s) if needed (see the configurable example).

The generated COM classes form ASP files do not use the IIS or COM+ (MTX) context objects and interfaces. Thus the resulting DLLs are virtually compatible with any ASP-Like environment. For example - Active Local Pages or non-Microsoft ASP enabled WEB servers (Windows only). The deployment requirements of the DLLs are minimal - by default the VB runtime DLL only and the custom components used in the original page (a 3-D party ActiveX for example). See Deployment for detailed information.