• Choose a category
• All
• Classic-Fiction

–p

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

–u

If this switch is specified, it indicates that the precompiled application is updatable.

–v

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

If no target path is specified, the precompilation takes place in the virtual path of the application, and source files are therefore preserved. If a different target is specified, only assemblies are copied, and the new application runs with no source file in the production environment. The following command line precompiles YourApp to the specified disk path:

aspnet_compiler -v /YourApp c:\DeployedSite

Static files such as images, web.config, and HTML pages are not compiled—they are just copied to the target destination.

Precompilation for deployment comes in two slightly different forms—with or without support for updates. 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 on the production server without having to recompile the site.

Sites precompiled for deployment and update are made of assemblies obtained from all files that normally produce assemblies, such as class and resource files. The compiler, though, doesn’t touch .aspx page files and simply copies them as part of the final layout. 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.

In no case can new pages be added to a precompiled site without recompiling it from scratch.

The fixednames parameter in Table 2-1 plays an important role in update scenarios for sites that need to release updates to specific portions without redeploying the entire set of assemblies. In this case, you must be able to just replace some of the dynamically created assemblies and subsequently require that their names be fixed.

Note

In Visual Studio 2010, you have a graphical user interface for site precompilation only if you create a Web site project. If this is the case, and you get to publish the site, you are offered a nice dialog box with options to select to make the precompiled site updatable and to enable strong naming on precompiled assemblies.

Configuring IIS for ASP.NET Applications

Because an ASP.NET application lives within the context of the IIS Web server, the settings you apply to IIS might have an impact on the application itself. Let’s review some of the aspects of IIS you want to consider for achieving good performance and stability.

Recycling Policies

The application pool that hosts your ASP.NET application is subject to process recycling. Process recycling is a configurable setting by means of which you determine when the application pool (and subsequently all of its contained applications) is to be restarted. Recycling is not necessarily a bad thing and doesn’t necessarily indicate a problem. However, if it happens too often and without a clear reason, well, it’s not really a good sign.

Process recycling is an IIS feature introduced as a sort of insurance against programming errors that can cause the application to leak memory, hang, or just slow down. By recycling the worker process behind the application pool regularly, the Web server tries to ensure an acceptable average quality of service.

In light of this, process recycling is expected to happen naturally but occasionally, and in a way that doesn’t affect the perceived performance. What if, instead, you detect that the application