If you deploy the site by copying all the files (including the source code), the pages and the source code files are compiled dynamically at runtime when they are first requested by a user. This is called in-place compilation, and the generated assemblies are compiled into a temporary folder. As an alternative, instead of deploying source files, you can use the aspnet_compiler.exe tool (located under C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727) to pre-compile the source code files and (optionally) the markup files. This is the command you could use to pre-compile everything (this should all be entered on one line):

aspnet_compiler.exe -p c:\Projects\ASP.NET\TheBeerHouse\TBH_Web -v /TheBeerHouse c:\Deployment\TheBeerHouse

The -p parameter specifies the source directory, and the -v parameter specifies the virtual directory used at runtime by the site. The path at the end of the command is the destination directory for the compiler output files. If you look under the c:\Deployment\TheBeerHouse\bin folder, you’ll find multiple .dll assembly files, plus one .compiled XML file for each .aspx and .ascx file (see Figure 12-15).

Figure 12-15

The files named with a .compiled extension contain XML text that shows the relationship between the virtual path of a page or user control and the corresponding type compiled into one of the assemblies. If you look into any of the .aspx files, you won’t find any HTML/ASPX markup code, but rather the markup string printed below:

This is a marker file generated by the precompilation tool, and should not be deleted!

After executing the aspnet_compiler, you take all the output generated by this tool and upload it to the remote server, typically via FTP. If you’re deploying to a server within your network you might simply copy the files to a shared folder on that server. However, even local servers are often isolated behind a firewall, so FTP may be needed anyway.

Compiling the markup code may definitely be appealing in some circumstance, such as for packaged commercial products for which you don’t want the client to change anything; however, if you’re deploying to your own site this may not be particularly useful or necessary. Furthermore, it would complicate updates, because every time you need to change a line of markup you’d have to recompile everything and re-deploy the generated files. In the case of deploying to your own sites, it’s simpler to pre-compile only the source code files but not the markup files. To do this, just add the -u switch (which stands for updateable) to the command line, as follows:

aspnet_compiler.exe -p c:\Projects\ASP.NET\TheBeerHouse\TBH_Web -v /TheBeerHouse -u c:\Deployment\TheBeerHouse

With this command no .compiled files will be generated under the /bin folder, and the content of the .aspx and .ascx files won’t be removed. However, the CodeFile attribute of the @Page and @Control directives will be removed, and the Inherits will be updated with a reference to the type compiled into one of the generated assemblies.

Note that all static files (images, .htm files, .css stylesheet files, etc.) are always copied “as is” to the target folder. These are never included as part of a pre-compile.

However, there’s a small deployment issue when using one of the two pre-compile commands described above: The assemblies they generate always have a different name, which makes it difficult to update the site locally and then replicate the changes remotely, because the assembly names will be different after each pre-compile. If you don’t want to leave old and unused assemblies in the remote /bin folder, you need to delete them first and then upload all new .dll files. This is very annoying and time-consuming, so you can add the -fixednames compiler switch to cause the aspnet_compiler to create an assembly for each file it compiles, using a fixed name scheme. This is good because it allows you to update the site locally, recompile it, and then upload only the changed assembly file. This is the modified command line:

aspnet_compiler.exe -p c:\Projects\ASP.NET\TheBeerHouse\TBH_Web -v /TheBeerHouse -u -fixednames c:\Deployment\TheBeerHouse

I covered the syntax of the command-line tool for completeness (and because many of you will want to script this procedure), but you don’t have to remember all the various switches because Visual Studio provides a simple integrated UI for aspnet_compiler, which you can access by clicking Build @@> Publish Web Site. Figure 12-16 shows the graphical front-end that it provides, making it easy to select your options, and to select a local or remote IIS site, or an FTP site, as the destination for the operation, in addition to a local folder.

Figure 12-16

Some of you may be concerned about the large quantity of assemblies produced by the pre-compilation step. In large projects with hundreds of pages, the /bin folder will contain a lot of files, and it may be more convenient for deployment if you could combine all those .dll files into a single assembly file. There’s no way to do this with the tools included in VS2005 and the standard installation of the .NET Framework 2.0, but Microsoft listened to its customers, and after releasing VS2005, they later released a free package called “Visual Studio 2005 Web Deployment Projects,” which can be downloaded from http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx. After installing the package, you’ll find a new command-line tool called aspnet_merge.exe under the C:\Program Files\MSBuild\Microsoft\WebDeployment\v8.0 folder. As its name suggests, it enables you to merge the multiple assemblies generated by the aspnet_compiler tool into a single dll. When you run this program you only need to specify the path of the pre-compiled web site where it can find the assemblies you want to merge:

aspnet_merge.exe c:\Deployment\TheBeerHouse

The preceding command generates a dll for each of the web site’s folders containing files that were pre-compiled by aspnet_compiler. This is useful when you have folders that include a sub-application supported by different developers (such as the administration console), and you want to have separate assemblies for separate sections so that you can update them independently on the production server. In other cases, however, you may prefer to merge everything into a single assembly: You can do so with the -o switch, which specifies the name of the assembly being generated:

aspnet_merge.exe c:\Deployment\TheBeerHouse -o MB.TheBeerHouse.dll

Note that the tool can be used whether the aspnet_compiler.exe pre-compiled the markup code or not. But this tool never merges in any external libraries referenced by the web site’s source files and pages, such as the MB.TheBeerHouse.CustomEvents.dll and the FredCK.FCKEditorV2.dll assemblies. It only merges assemblies generated by aspnet_compiler.exe.

As for aspnet_compiler, there’s also a front-end UI for aspnet_merge. The Visual Studio 2005 Web Deployment Projects package is installed as an add-in for VS2005, and it adds a new project type called a “Deployment Project.” You add a new deployment project to your solution by clicking the Add Web Deployment Project… option on the IDE’s Build menu, or via the same option on the context menu of the web site in the Solution Explorer window. You create the project by choosing its name and location from the dialog box shown in Figure 12-17.

Figure 12-17

The project added to the Solution Explorer contains no files; you have to double click the project name to open its configuration dialog box, from which you can specify a number of options. Among other things, you can specify how you want the pre-compiler to work, and how you want the files merged. In the first tab of the dialog box (see Figure 12-18), you specify the output folder, and choose whether the user interface pages and controls should be pre-compiled (which is the updateable option, corresponding to the -u switch of the aspnet_compiler.exe tool).

Figure 12-18

In the second tab, Output Assemblies (see Figure 12-19), you specify whether you want to compile everything into a single assembly, have an assembly for each folder, have an assembly for the user interface pages and controls, or have an assembly for each class and page being compiled (this last option means you don’t want to use aspnet_merge.exe). From here you can also specify the version information of the generated assemblies. If this information is not provided, the settings specified in the web.config file located under the /App_code folder will be used instead (if the file is present, which is not a requirement).

Figure 12-19

The third tab, Signing (not shown here), enables you to sign the generated assemblies with a key file generated by the sn.exe command-line tool, to give them a strong name. This isn’t normally desired for your own sites, but may be useful when you’re creating a packaged application and you want to ensure that your assemblies will not be tampered with. In the last tab, Deployment (see Figure 12-20), you can choose to replace one or more sections of the site’s web.config file with the content from another file. For example, if you write connectionStrings=connectionStrings.LocalSql.config, the whole <connectionStrings> section will be replaced with the content of the connectionStrings.LocalSql.config file at the end of the build process. This enables you to have a connection string pointing the SQL Server Express database to be used while testing the site locally, and later have it automatically replaced with a connection string referencing a local or remote SQL Server 2005 database after building the project for deployment. You can specify additional sections to replace, one per line. You can also use this window to specify a virtual directory to be created during the build process, and whether the App_Data folder will be deleted from the files generated (useful when you will use a SQL Server 2005 database after the build, in which case you do not want to deploy your express files under App_Data).

Figure 12-20

Once you’ve completed the configuration, you can build the project. At the end of the build process you’ll find a copy of the site with the pre-compiled and merged assemblies, plus all other files such as pages, controls, images, stylesheets, and so on in the output folder. You can then take this entire output and upload everything to the production server, typically via FTP.

Deployment projects simply consist of an XML file used to pass options to MSBuild.exe, the new Microsoft build tool capable of compiling and building complex projects and solutions. MSBuild is an extensible tool that uses configuration files that can contain many different options. And if an option or a task that you’d like doesn’t exist yet, you can create it as a C# class, and have MSBuild call it. Many of the configuration settings described here were implemented as custom settings and tasks by the developers of the Web Deployment Projects add-in. There are many more available options in addition to those you can configure from the Properties window explored earlier, such as the option to exclude files from the build, create new folders, grant the ASP.NET account write access to a folder (only on your local machine, though—you’ll still need to replicate these security settings on the remote production server), execute external programs, and much more. You can add more settings and tasks (i.e., operations to run before or after the build and the merge processes) directly from the XML configuration file, which can be opened by clicking the Open Project File option from the Web Deployment project’s context menu. Covering MSBuild is beyond the scope of this book, but you can find a lot of good documentation about this on the web, and in the documents that come with the Web Deployment Projects package.

By default, all projects added to the solution are built in Visual Studio when you launch the primary project, i.e., the web site. Building the deployment project takes quite a lot of time, however, depending on the size of the site (on my machine it takes around 30 seconds to generate the pre-compiled site), and it is not something you want to do while testing the site locally. In order to avoid this waste of time, you can just exclude the project from the Build | Configuration Manager… dialog box.