Pre-compilation of Applications

Pre-compilation of Applications

Dynamic compilation is targeted at reducing the number of manual steps developers have to perform while constructing a site. Pre-compilation, on the other hand, targets two issues with ASP.NET 1.x: (1) the compilation delay when first hitting a site or page, and (2) the hosting scenario, where source code must be present on the server. For intellectual property reasons this isn't always an acceptable situation.

Both of these issues are tackled individually by a pre-compilation system. Part of this functionality will not be in place for the initial Technology Preview release but will be available in later betas and the final release.

In-place Pre-compilation

While ASP.NET performs extremely well, the hit taken while a site initially compiles can be quite large. To avoid this, some developers have built tools to hit every page to ensure it is compiled. In ASP.NET there is support for in-place compilation, which does just thatit compiles every file within an application root. This mechanism is done by navigating to the special URL:

http://applicationDirectory/precompile.axd

Table 2.2. Compilation Life Cycle

Scenario

Pages and Themes

\Resources Folder

\Code Folder

Global .asax

Personalization

Restart Application Domain?

Modify .aspx , .asmc , mascx

Compile as necessary

       

No

Modify Global .asax

Compile

   

Compile

 

Yes

Modify source files in \Code

Compile

 

Compile

Compile

Compile

Yes

Modify Web.config

Compile

Compile

Compile

Compile

Compile

Yes

Modify\Bin

Compile

Compile

Compile

Compile

Compile

Yes

Modify\Resources

Compile

Compile

Compile

Compile

Compile

Yes

Add .resx anywhere

Compile

If referenced

If referenced

   

No

Add source files anywhere

Compile

 

If referenced

   

No

Change themes

Late bound compile of themes only if referenced

       

Yes

Personalization

Compile

   

Compile

Compile

Yes

The precompile.axd URL is handled by an HttpHandler , which pre-compiles the entire site, thus avoiding the compile delay during the first hit. There is no overhead if the URL is called multiple times because only changed files are recompiled. Global dependencies, such as changes to global.asax and web.config , are obeyed, and all source files will be marked as out of date, triggering a complete compilation if requested .

Errors that occur during pre-compilation will halt the entire process. These appear in the browser window exactly as they would if the page in error had been hit directly.

Pre-compilation for Deployment without Source

Being able to pre-compile to a target directory without the source is a great way to not only deploy ready-to-go applications but also to protect intellectual property. Pre-compilation is achieved by use of the aspnet_compiler.exe tool, whose syntax is shown below:

 aspnet_compiler.exe [-m metabasePath                       -c virtualPath                     [-p physicalPath]]                     [targetDirectory] 

where:

  • metabasePath is the full IIS metabase path of the application.

  • virtualPath is the virtual path of the application.

  • physicalPath is the physical path of the application.

  • targetDirectory is the target directory for the fully compiled application.

If the target directory is not supplied, the application is pre-compiled in place and the source is left where it is. When a target directory is specified, the target will contain no source code after the compilation. A text file is placed at the top-level directory indicating that the site has been pre-compiled. All of the source files are compiled into assemblies, and the source files have all content removed and remain simply as markers so that IIS can find the physical files.

Pre-compilation does not compile static files, such as HTML files, web.config , XML files, and so on. These are just copied to the target directory. If you wish to keep the contents of HTML files from being readable in the target directory, you could rename them to .aspx so they will take part in the pre-compile. This isn't recommended, however, because it loses the benefits of IIS being able to serve HTML pages efficiently , and the performance loss may not be acceptable. Assemblies in the \Bin directory of the source application are also preserved and copied directly to the target directory.

Once an application has been pre-compiled in this manner, changes (e.g., additions to the source directory) will not trigger a recompilation. Compilable files (such as .aspx files) cannot be added to the target directory once it has been generated. They must be added to the source directory and recompiled to the target.

Pre-compilation for Deployment with Source

As mentioned above, dynamic files cannot exist in a pre-compiled target directory, so it is not possible to deploy a pre-compiled application with the source intact. This is a feature that is being investigated for later releases, but for the time being the standard deployment and in-place pre-compilation is a great model to work with.

The Compilation API

The technology underlying the pre-compilation system is the Client BuildManager , which also provides an API, allowing custom tools to be built. Listing 2.6 shows how this can be achieved.

Listing 2.6 Using the Compilation API
 Imports System.Web.Compilation Public Sub BuildApplication   Dim src As String = "C:\Development\WebSites\MySite"   Dim vdir As String = "/MySite"   Dim tgt As "C:\InetPub\WWWRoot\MySite"   Dim bmgr As New ClientBuildManager(src, vdir, tgt, vbNull)   bmgr.PrecompileApp() End Sub 


A First Look at ASP. NET v. 2.0 2003
A First Look at ASP. NET v. 2.0 2003
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 90

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net