Freigeben über

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

  • Artikel

Hi Everyone,

Welcome back!!!

We again missed a couple of days and most of you know what most of us were busy with in the last 2 days :-) :-). So, as mentioned earlier, today we talk about ASP.Net site pre-compilation.

Application Pre-compilation:

By default, each public resource of an ASP.NET site is compiled on the fly only upon its first request. This introduces a first-hit delay as a result of the compilation process. Since the advent of ASP.NET 1.0, developers have raised the issue of site pre-compilation. Site pre-compilation brings a double benefit: no delay for requests because of compilation and no need of deploying source code to the Web server. Further, as do classic Windows executables, precompiled sites offer a high degree of protection against violations of the intellectual property behind the work. Pre-compilation comes in two forms, each targeting a specific scenario/goal: in-place pre-compilation and deploy pre-compilation. The former prepares all the resources in a site to be served without delay by actually accessing and thereby generating all needed dynamic assemblies for all pages and resources that need be compiled. In-place pre-compilation occurs on an already deployed application.

In-Place pre-compilation:

In-place pre-compilation is merely a form of performance improvement. You deploy the application as usual using whatever technique you like or can afford—FTP, Xcopy, or setup packages. Once the site is up and running on the production server, you pre-compile it before it goes public. Pre-compilation ensures that each page is accessed and each required dynamic assembly is created. In this way, even the first user hitting the page will be served quickly because the required assembly is already available. In-place pre-compilation essentially primes a site, meaning that no end user will ever wait for pages and their references to be compiled before being served a response.

Conditions for In-Place Pre-compilation:

In-place pre-compilation assumes that the site is running under IIS, and it requires that .NET compilers are available on the target machine for the languages used by the pages. Pre-compilation will fail on the application if compilation for any single file fails. The in-place pre-compilation model preserves the full site structure and still allows sites to be extended with new pages or newer versions of existing pages. Needless to say, if new or modified pages are uploaded without stopping and recompiling (pre-compiling) the site, the first user hitting modified pages will experience the first-hit delay again. When pre-compiling a site, though, only new or modified files are actually processed. Up-to-date files are skipped, thus minimizing the impact of the operation on the running sites.

The aspnet_compiler utility:

In-place pre-compilation consists essentially of running a batch compiler. It's analogous to manually requesting all the pages on the site to make sure all the code is compiled. The executable in charge of all forms of pre-compilation is aspnet_compiler.exe. You find it in the ASP.NET installation path:

%WINDOWS%\Microsoft.NET\Framework\[version]

To pre-compile a site in-place, you use the following command, where /MyTestPreCompiledSite indicates the virtual folder of the application:

aspnet_compiler –v /MyTestPreCompiledSite

Following table lists the command-line switches supported by the utility that are relevant to in-place compilation:

Switch

Description

-m

Indicates the full IIS metabase path of the application. This switch cannot be combined with the -v or -p switches.

-v

Indicates the virtual path of the application to be compiled. If -p is also specified, the physical path is used to locate the application. If no virtual path is specified, the application is assumed to be in the default site: W3SVC/1/Root.

-p

Indicates the physical path of the application to be compiled. If missing, the IIS metabase is used to locate the application. This switch must be combined with -v.

-d

If specified, the debug information is emitted during compilation.

-c

If specified, the precompiled application is fully rebuilt. Any previously compiled components will be recompiled.

-keyfile

Indicates the physical path to the key file for strong names.

-keycontainer

Indicates the name of the key container for strong names.

-aptca

If specified, compiled assemblies will allow partially trusted callers.

-delaysign

If specified, compiled assemblies are not fully signed when created.

-fixednames

If specified, the compiled assemblies will be given fixed names.

Effects of In-Place Precompilation:

After running the aforementioned command line, the utility runs and recursively scans all the pages and related dependencies in the virtual folder and child applications. Assemblies are generated in the "codegen" directory and remain there to serve requests. To see it live, I suggest that you delete any temporary folder for your application and then run the utility from the command prompt. The folder fills up before your eyes, and when the tool completes, all required dynamic assemblies have been generated. Note that aspnet_compiler requires localhost access and administrative rights on the machine to operate.

That's it for today. Thanks for joining!!! See you tomorrow. Tomorrow we will continue with pre-compilation and will look into deploy pre-compilation, updatable pre-compilation and programmatic pre-compilation.

Thanks,

Sukesh Khare

Coordinator Daily .Net Feed Program

Comments