Daily .Net Feeds - ASP.Net 2.0 - Advanced - Day 10

Hi Everyone,

Welcome back!!!

Let's continue the discussion about ASP.Net site pre-compilation. We talked about in-place pre-compilation yesterday; another flavor of pre-compilation is deployment pre-compilation.

Pre-compilation for deployment:

Pre-compilation for deployment pursues different goals than in-place pre-compilation. Conceptually, it tends to transform the ASP.NET application into a closed executable that preserves intellectual property by hiding source code (possibly both markup and classes). Pre-compilation generates a file representation of the site made of assemblies, static files, and configuration files that can be later packaged into a CAB, ZIP, or MSI file for actual deployment. As a pleasant side effect, it also saves your users from first-hit compilation delay. Note that the overall purpose of in-place compilation was getting rid of the first hit delay for the site pages but that is not the case with deployment pre-compilation which in turn works towards getting rid of having to put code at the deployment location. Pre-compilation for deployment has two variants that allow for non-updatable or updatable sites.

You use the same utility—aspnet_compiler—to build manifests of a Web site. Following table lists additional command-line switches that are useful here.

Switch	Description
-u	If specified, indicates that the precompiled application is updatable.
-f	Indicates that the target directory will be overwritten if it already exists and existing contents are lost.
targetDir	Indicates the physical path to which the application is compiled. If not specified, the application is precompiled in-place.

Non-updatable Pre-compilation:

The big difference between in-place and deploy pre-compilation is that the latter can work on the development machine and creates a deployable image of the site in the specified target directory. Try the following command:

aspnet_compiler -v /MyPrecompiledSite c:\Deliverable

You get the output shown in the following figure:

 

The first thing that you notice is the presence of an additional small file named precompiledapp.config whose contents are shown here:

< precompiledApp version="2" updatable="false"/>

The file is a marker to inform the ASP.NET runtime that the application is precompiled. In the figure, you also see that web.config and web.sitemap have a different date. This is because static files such as images, web.config, web.sitemap, and HTML pages are not compiled. They are just copied to the target destination.

On the surface, the structure of the site is intact. However, if you delve a bit deeper, you see a lot of differences. First, all .aspx files are empty. To be more precise, they contain a string of text that warns you not to remove .aspx files even though they don't appear to contain any significant text.

In a precompiled solution, ASP.NET pages are marker files and should not be deleted. In other words, they represent a necessary endpoint and must be deployed. However, their contents won't be parsed or processed. You can also replace the text to display a custom message before you package the layout into a deliverable file.

The Bin folder of the application also contains a different set of assemblies, as in the original project. In addition to the referenced assemblies, the folder now contains one App_Web_xxx assembly for each page in the application. Sites packaged for deployment only are not sensitive to file changes. When a change is required, you modify the original files, recompile the whole site, and redeploy the new layout. The only exception is the site configuration; you can update web.config or web.sitemap on the production server without having to recompile the site.

Updatable Precompilation:

By adding a –u switch to the batch compiler utility, you can pre-compile a site to be updatable. In this case, .aspx files are slightly touched to remove the CodeFile attribute and change the Inherits attribute. Other files, on the other hand, are compiled as usual. In this way, you are allowed to make limited changes to the ASP.NET pages after compiling them. For example, you can change the position of controls or settings regarding colors, fonts, and other visual parameters. You can also add new controls to existing pages as long as they do not require event handlers or other code. Code files are not deployed as source code, so you can't update the logic of the page without recompiling and redeploying the layout. Updatable sites won't save users from first-hit compilation delay when each page is accessed for the first time after a change is made.

Note: Updatable pre-compilation in ASP.NET 2.0 is nearly identical to the compilation and deployment model of ASP.NET 1.1, in which.aspx files are deployed in source and all classes (including code-behind classes) are compiled to assemblies.

Programmatic Precompilation:

Site pre-compilation is also possible programmatically. The ClientBuildManager class exposes an API to invoke pre-compilation on an ASP.NET application. The aspnet_compiler utility itself simply creates an instance of this same class and works through its public interface. The method to start the pre-compilation is PrecompileApplication. The class constructors allow you to specify virtual and physical directories for the source and the target directory for the output. In addition, one of the constructors can accept additional parameters, such as pre-compilation flags and strong name attributes. All classes are located in the System.Web.Compilation namespace. An example follows:

ClientBuildManagerParameter params = new ClientBuildManagerParameter(); params.PrecompilationFlags = PrecompilationFlags.Updatable | PrecompilationFlags.OverwriteTarget; ClientBuildManager cbm; cbm = new ClientBuildManager(vdir, sourceDir, targetDir, params); cbm.PrecompileApplication();

The PrecompilationFlags enum type is defined as follows:

public enum PrecompilationFlags { AllowPartiallyTrustedCallers = 0x20, Clean = 8, CodeAnalysis = 0x10, Default = 0, DelaySign = 0x40, FixedNames = 0x80, ForceDebug = 4, OverwriteTarget = 2, Updatable = 1 }

That's it for today. Thanks for joining!!! See you tomorrow. We are done with the discussion of pre-compilation today and tomorrow we will start delving deeper into the overall ASP.Net compilation machinery :-).

Thanks,

Sukesh Khare

Coordinator Daily .Net Feed Program