Programming Microsoft ASP.NET 4 - Dino Esposito [22]
I’ll demonstrate concretely how to set up the IIS 7.5 autostart feature later in the chapter in the section about the configuration of IIS.
Application Pool Custom Identities
For years, worker processes under both IIS 6.0 and IIS 7.0 have run under the aegis of the NETWORKSERVICE account—a relatively low-privileged, built-in identity in Windows. Originally welcomed as an excellent security measure, in the end the use of a single account for a potentially high number of concurrently running services created more problems than it helped to solve. In a nutshell, services running under the same account could tamper with each other.
In IIS 7.5, worker processes by default run under unique identities automatically and transparently created for each newly created application pool. (The underlying technology is known as Virtual Accounts and is currently supported by Windows Server 2008 R2 and Windows 7. For more information, have a look at http://technet.microsoft.com/en-us/library/dd548356(WS.10).aspx.)
You can still change the identity of the application pool using the IIS Manager dialog box shown in Figure 2-7.
Figure 2-7. Modifying the identity of an application pool.
Deploying ASP.NET Applications
An ASP.NET application must be installed on an IIS machine for it to be usable by its end users. Installing a Web application means moving files and configuration from the development server to a staging server first or directly to the production environment. In general, deployment of a Web application entails a number of steps that relate to moving settings and data around a few server machines. This process can obviously be accomplished manually but does offer a high degree of automation. Automation is always useful and welcome; it becomes a necessity, though, when you need to install on a hosted server instead of an enterprise server that you might have direct access to.
In the beginning of the Web development era, deployment was not an exact science and everybody developed their own set of practices and tools to simplify and speed up necessary tasks. Today, Web deployment is part of the job, and effective tools are integrated into the development environment and are taken care of as part of the development cycle.
Not all scenarios are the same for the deployment of Web applications. You still can recognize simple and less simple scenarios and pick appropriate tools for each. Let’s start with plain XCopy deployment for Web site projects and then move on to consider more enterprise-level tools, such as the IIS 7 integrated Web Deployment Tool, that are better suited for Web application projects.
Note
In Microsoft Visual Studio, you can choose between two main types of Web projects—Web Site Project (WSP) and Web Application Project (WAP). The biggest difference between the two is the deployment of the source code. In a WSP, you deploy markup and source code; in a WAP, you deploy markup and compiled code. There are, of course, pros and cons in both situations. Having source code deployed to the Web server enables you to apply quick fixes and updates even via FTP. If you need to control the rollup of updates, or you are subject to strict rules for deployment, a WAP is preferable as you build a single package and run it through the server.
A comprehensive comparison of WSP and WAP can be found in the whitepaper available at http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5. An interesting post that helps you make the choice through a series of questions is found at http://vishaljoshi.blogspot.com/2009/08/web-application-project-vs-web-site.html.
XCopy Deployment for Web Sites
In simple scenarios, installing an ASP.NET application