Programming Microsoft ASP.NET 4 - Dino Esposito [26]
An IIS Web project is a project that relies on the local IIS Web server instead of the ASP.NET Development Server that comes with Visual Studio. (Note that this internal Web server is also referred to as the Visual Studio Development Server or, more familiarly, Cassini.) For a WAP, you switch to the local IIS Web server by selecting the Web tab in the application properties dialog box, as shown in Figure 2-14.
Figure 2-14. Switching to an IIS Web project.
At this point, when you open the Publish Settings tab you find a couple of check boxes selected that allow you to propagate current IIS settings down to the destination. (See Figure 2-15.) To configure the local IIS for the current project, you just click the Open Settings link. Any application pool or configuration scenario you define will be reported in the deployment script.
Figure 2-15. Propagating IIS settings.
Web.config Transformations
During the development of a Web site, you rely on a bunch of settings stored in the web.config file that refer to the current environment. So, for example, the data access layer targets a development database and the security settings are different from those required by the production environment. When it comes to deploying the site to the real host, you need to tweak the web.config appropriately. This is usually a manual process. You open the development version of the web.config in Visual Studio and then proceed with any required changes.
To make the whole matter even more complicated, sometimes you need to go through a battery of integration tests. An integration test is typically a situation in which you test the behavior of your site (or part of it) in an environment that simulates the production environment and in which multiple elements are being tested together. You might need yet another web.config file for this scenario. In the end, you likely need about three different versions of the web.config file: debug, release, and test. How do you deal with that?
The simplest, but not necessarily most effective, solution is managing distinct files and keeping them in sync by manual intervention. However, if you made the switch to Visual Studio 2010, you can rely on a new IDE feature that automatically maintains a single copy of the web.config file—the skeleton—and then transforms it into as many versions as you need when you publish the solution using WDT. This feature is supported by Web application projects and is not available for simple Web site projects.
The web.config file of a Visual Studio 2010 WAP looks like the one shown in Figure 2-16. It shows up as a subtree in Solution Explorer. If you expand the node, you see two child files—web.debug.config and web.release.config. The debug version of web.config looks like a regular configuration file except for a little detail.
Figure 2-16. Predefined transformations of the web.config file.
Here’s how the root The element includes the definition of a new namespace whose suffix is xdt. The namespace refers to a specific XML schema used to express transformations required on the content of the file. You use xdt elements to insert commands in the configuration file to be processed during the publish process to apply transformations to the actual web.config file being deployed for a given configuration (debug, release, or any other one you want to support). Suppose, for example, that the web.config file you use for development purposes contains a xdt:Transform="Replace" connectionString="..." /> The Transform attribute indicates the operation to perform on the current