ASPC is a script host (as like ASP or WSH). It uses a set of ActiveX controls build especially for the case and some universal ones. IDE (Integrated Development Environment) is responsible to connect all them and pass the control to a driving script which controls the process. In other words the harder work is done by COM components (written in C++) and they are controlled by a script. Driving script is in aspc.js file which must present in the ASPCIDE.EXE directory. Thus clicking the button "build" you are invoking a script host which loads the files you specified and applies different kind of filters over them in order to implement the process shown.

Lets trace the processing step by step, of course excluding any details which will make this page too long. Think for one file from the file listed in the project.

1. Driving script (DS)  loads the ASP file.
2. DS passes the file to the parser component initialized with the ASP file rules.
3. DS obtains as result simple syntax tree (not shown on the picture) and immediately saves it to a file (in ASP to VB case it is a temporary file). The file is plain VBScript in which for example all the <% %> tags are replaced with Response.Write statements. In other words this file will run under IIS if one <% is placed on the first line and one %> on the last (Note that ASPC has a processing option that does it - ASPToASPPlain - without continuing with the next steps).
4. Now DS passes the generated file to the VBScript structure analyzer/parser. It is a parser component initialized with the VBScript program structure rules. It is responsible to generate a Code syntax tree. This tree contains a tree - collections of objects and other collections. In it all the parts of the code are classified and for example every Statement is placed as sub item of the containing Sub/Function and so on.
5. DS reviews the tree and builds corresponding internal objects intended to encapsulate every part of the script. All the arguments from the routines argument lists are parsed and recorded in array attached to the routine enveloping object and all the local variables too. The same is done with the VBS classes (in any) and their members. Thus after this step DS has a full description of the code which can be searched.
6.  After finishing the above steps for all the files in the project DS has all the code from all the files represented in the tree. And continues with the generation phase. It generates the loader files and begins the generation of the VB class files.
7. During this step DS inspects every statement in every routine and generates its equivalent statement for VB language. The most important task in this phase is the symbol linking. DS inspects every identifier in the statement and searches for its definition/declaration. Also if a New operator is found DS generates additional statement(s) needed to initialize the object correctly. For more details on this phase see symbol linking.
8. Finally DS generates a VB project file which describes all the class files and additional project parameters. Depending on your configuration VB can be automatically invoked to compile it.

As you may already suppose this scheme can be used to generate not only VB projects. We will extend it and add new preprocessing options in future.

The process described above contains additional details, but these are the key steps in it. ASPC project files keep information about the driving script used. Thus in theory it can be replaced by another which does something different. In current version all the supported preprocessing options have common parts thus we use only one script but this will change in future.