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

Article
07/23/2007

Hi Everyone,

Welcome back!!!

Let's continue the discussions around the ASP.Net compilation mechanisms. We discussed the overall dynamic compilation concepts (what happens when resources get updated) and pre-compilation (techniques to avoid first hit delay and preserving intellectual property by hiding source code), however whenever any kind of compilation happens for any resource of an ASP.Net site, there is a machinery that gets triggered behind the scenes which does the job of actually compiling the resources from their source files. That's what we will look into today.

Building Blocks of ASP.NET Compilation:

The ASP.NET compilation machinery involves two main manager classes and a family of components named "build providers". The two classes are the ones we mentioned on Friday last week - ClientBuildManager and BuildManager. ClientBuildManager acts a proxy between client applications such as Visual Studio and the ASP.NET back-end system that actually compiles pages and resources. BuildManager governs the physical compilation process from within the ASP.NET environment. It creates and uses build-provider components to process specific resources. Finally, build providers supply an object model to parse file types and generate code. Behind each C# or Visual Basic .NET class dynamically compiled to an assembly from whatever application folder, there's a build provider. For example, a build provider governs the compilation of ASP.NET pages, themes, and profile information. You can define and register custom build providers to extend and enhance the set of file types that ASP.NET can handle. We'll see a sample custom build provider later this week. Let's start the tour of the ASP.NET compilation machinery with a look at the available configuration options. The ASP.NET compilation environment is subject to a number of attributes defined in the web.config file. The section to check out is <compilation>. It is composed of four child sections, as listed in following table:

Child Sections of <compilation>:

Section	Description
<assemblies>	Lists the assemblies that are used during the compilation of an ASP.NET resource.
<codeSubDirectories>	Lists subdirectories containing code files to be compiled at run time. Typically, they are children of the App_Code folder. We'll return to this subject later.
<buildProviders>	Lists all registered build providers. We'll return to this subject later.
<expressionBuilders>	Lists all registered expression builders. (We'll cover expression builders in one of the sessions quite later in one of the coming weeks.)

Before going any further with child sections of the <compilation> block, let's explore the attributes available to <compilation>. The Debug attribute indicates whether to compile retail or debug binaries. The default is false. The DefaultLanguage attribute indicates the language to default to if the page lacks this information. The default is Visual Basic .NET. Strict and Explicit turn on and off the corresponding flags on the Visual Basic compiler. Finally, TempDirectory specifies the directory to use for temporary file storage during compilation.

Linked Assemblies:

The <assemblies> section lists the assemblies automatically linked to each page class being compiled. The default contents of the section are shown here:

The final <add> line dictates that all assemblies found in the /Bin folder are to be loaded for the application. In application-specific web.config files, you can modify this list at will by using the <clear />, <remove/>, and <add/> nodes. They let you respectively empty the previous list, remove a particular assembly, and add a particular assembly.

Batch Compilation:

ASP.NET attempts to batch into a single compiled assembly as many pages as possible without exceeding the configured maximum batch size. Batch compilation is a form of optimization that attempts to minimize the number of assemblies loaded into an application. Batch compilation attempts to group in the same assembly pages resident in the same directory that are using the same language. Batch compilation is attempted only in Web directories containing page content such as .aspx and .ascx files. Reserved directories such as App_Code are always compiled atomically into a single assembly. Pages with parsing errors are excluded from compilation. When a page has a compile error, the result of the failed compilation is not included in the final assembly. Following table lists the configuration options with respect to batch compilation. The batch system is governed by configuration directives in the <compilation> section of the configuration file. Fine-tuning parameters in the <compilation> section of the configuration file is important and should save you from both having (and loading) 1000 different assemblies for as many pages and from having a single huge assembly with 1000 classes inside. Notice, though, that the problem here is not only with the size and the number of the assemblies but also with the time needed to recompile the assemblies in case of updates.

Batch Compilation Options:

Attribute	Description
batch	Enables batch compilation. Set to true by default.
batchTimeout	Indicates, in seconds, the timeout period for batch compilation. If compilation cannot be completed within the timeout period, the compiler reverts to single compilation mode for the current page. Note that in ASP.NET 2.0, this is no longer supported, and it is ignored.
maxBatchSize	Indicates the maximum number of pages to be grouped together per batch compilation.
maxBatchGeneratedFileSize	Maximum combined size (in KB) of the generated source file per batch compilation.

That's it for today. Thanks for joining!!! See you tomorrow. Tomorrow we will continue this discussion and will deal with the ASP.Net 2.0 reserved folders. In the following days we will look at what are build providers and a sample custom build provider.

Thanks,

Sukesh Khare

Coordinator Daily .Net Feed Program

Share via

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

Additional resources