Pre-compilation for deployment creates an ‘executable’ (no source code) version of your web application. With pre-compilation for deployment you give the aspnet_compiler the path to your source code, and the path to a target directory for the compilation results, like below.
aspnet_compiler -p "C:\MyDevelopment\WebSite1" -v / C:\Staging
This command will compile the site and place the result in C:\Staging. You must still specify –v as a parameter, even though we are not using a virtual path as either a source or a destination. Instead, the compiler will use this parameter to resolve application root references (~).
The pre-compilation for deployment step will recreate your web site’s folder structure in the destination directory. All of the static files (HTML files, image files, configuration files) are copied into the folder structure exactly as they appear in the source folder hierarchy. A bin directory will appear in the target directory with all of the assemblies and .compiled files.
The target directory will contain no source code. All of the classes in the App_Code folder are now compiled into one or more assemblies in the bin directory, and no .cs or .vb files will exist in the target directory. Master page files will also compile to the bin directory and not exist. All the code and markup in ASPX, ASCX, and ASHX files, along with any associated code-behind files, will live inside of one or more assemblies in the bin directory, although these files will still exist in the target directory, they exist as nearly empty ‘marker’ files. If you open an ASPX file in a pre-compiled target directory you’ll see the following content:
This is a marker file generated by the precompilation tool, and should not be deleted!
Note: This behavior is as of beta 2 and may change. The IIS script map for the ASPX file extension leaves the “Verify that file exists” checkbox unchecked, and the site will work without any of the ASPX files present. There is, however, a problem getting IIS to serve a default document for a directory request unless the file is present.
Once the application finishes compiling you can FTP or XCOPY the target directory to a web server (or map a virtual directory to the target directory), and the application will be ready to run. A benefit to pre-compilation for deployment is that no one can make changes to the web application by tweaking the source code – no source code exists! In fact, you can’t even place a new ASPX file into the existing application directory structure without causing an error.
Making a change to your site will require you to make a change in the original source code, pre-compile the application again, and redeploy all files to the server. There is one caveat in this scenario, in that pre-compilation generates unique filenames for some assemblies in the bin folder, and these filenames will change each time the pre-compiler executes. The first time you run aspnet_compiler you might see App_Web_lufhs9vn.dll in the bin directory, the next time you might see App_Web_hviqdkt.dll with the same compiled code, even though no source file has changed. This means you might have unneeded dlls in your bin directory if you keep repeatedly copy files to the server without cleanup. Use the -fixednames switch to generate repeatable assembly names.
For some people, the ability to update content on the web server by modifying aspx and ascx files is a needed feature. To support this scenario, the aspnet_compiler has the –u switch for an “updateable” pre-compilation. With updateable pre-compilation the ASPX, ASCX, ASHX, and MASTER files are copied to the target directory in tact - they do not become ‘marker’ files. You can deploy these files to the server and modify them without causing an error, because the ASP.NET runtime will dynamically parse and compile these files. All of the source code for code-behind files and in the App_Code folder will still be compiled into assemblies and will not need to be deployed.
