Programming Microsoft ASP.NET 4 - Dino Esposito [25]
Figure 2-10. The Web Deployment Tool installed through Web Platform Installer.
After you have WDT on board, all you need to do is prepare a deployment script and push it to the tool installed on the IIS machine.
Notice that you can use WDT for clean installations as well as for updating existing applications. In other words, the tool gives you an API to synchronize files over HTTP, the ability to execute setup and configuration commands remotely; more importantly, it works in both enterprise and hosted environments.
The strict requirement, of course, is that WDT must be installed on the server machine.
Note
To successfully operate with WDT, you need compatible versions of WDT installed on the server and the client machine. However, note that WDT is automatically installed if you have Visual Studio 2010. In addition, you must have appropriate permissions on the target computer to perform the tasks you require.
Building a WDT Package
A deployment package is a zipped file with a manifest. The package includes all the information required to set up the IIS application and the files to copy. In a package, in addition to the application’s source files and binaries, you find IIS and application pool settings, changes required to the web.config file in the production environment, database scripts, security certificates, registry settings, and assemblies to place in the global assembly cache (GAC).
You can create a WDT package either from Visual Studio 2010 or using Windows PowerShell or the command-line version of the tool. From Visual Studio 2010, you have a highly automated user interface you control through the Package/Publish Web tab. (See Figure 2-11.)
Figure 2-11. The Package/Publish Web tab, which is used to configure default settings for WDT.
You access the tab from the Project menu and use it to set your default settings for the projects. Interestingly, the tab goes hand in hand with the Package/Publish SQL tab, where you can list the databases you intend to configure and script on the server. The tool also offers to load some database information from your web.config file.
In Visual Studio 2010, you can choose to publish the application directly or you can build a WDT package and deploy it later. To build a package, you select the Build Deployment Package item from the Project menu. You obtain a ZIP file in the specified location that, among other things, contains a Windows PowerShell script to be used on a server machine. Figure 2-12 shows the content of such a package.
Figure 2-12. The content of a sample WDT package.
You can also publish the application in single step by choosing the Publish item on the Build menu. You are then shown the dialog box seen in Figure 2-13 where you indicate the full name of the target site or application and whether you want it to be a new application or simply a virtual directory. To turn the newly installed package into a new application, you select the Mark As IIS Application On Destination check box. For the entire operation to work, you need to run Visual Studio 2010 in administrative mode.
Figure 2-13. Publishing a Web application via Web Deploy.
If you choose to deploy a new IIS application, it will be placed in the default application pool. Obviously, if the application pool is configured for, say, the .NET Framework 2.0, it can’t be used to host an ASP.NET 4 application.
Propagating IIS Settings
How would you specify IIS settings for the application? The first option is importing a package that will be installed in the application pool of choice, configured as appropriate. Another option is creating the desired IIS environment in the development machine and then just propagating those settings up to the destination environment via WDT. There are some snags, though.
The Visual Studio Publish Wizard doesn’t let you determine the target application pool