A Web service can be deployed on a Web server in a variety of ways:
By manually copying the files
By using the Copy Project command of Visual Studio .NET
By using a Windows Installer package created using the Visual Studio .NET Web Setup project
You will learn more about each of these techniques in the following subsections.
Deploying a Web service by manually copying the files is a four-step process:
Build the Web service When you build a Web service, all the code-behind files of the Web service are compiled into a DLL file and are stored in the bin subdirectory of the Web service. This step enables you to deploy the compiled DLL files instead of the source files.
Select the files that need to be deployed A Web service might need to deploy several additional files besides the DLL files created in step 1. Table 10.2 lists the various files that are created in a Visual Basic .NET Web Service project and whether the file needs to be deployed. In addition to these files, you might also use some other files such as an .xml file or an .xsd file, which you might require on the production Web server.
Web Service File | Description | Needs to be Deployed? |
---|---|---|
.asmx | This file contains the WebService processing directive and serves as the entry point for the XML Web service. | Yes |
.asmx.vb | This file is a code-behind file that contains the source code for the XML Web Service. When you build the Web service, the content of this file is compiled into a DLL file. | No |
AssemblyInfo.vb | This file contains metadata about the assemblies in a project, such as name , version, and culture information. The contents of this file are also compiled into a DLL file. | No |
Web.Config | An XML-based file that contains configuration information for the Web service. | Yes |
Global.asax | A file that contains information for handling application-level events. | Yes |
Global.asax.vb | The code-behind file of Global.asax that contains the source code for the global.asax. When the Web service is built, the contents of this file are compiled into a DLL file. | No |
.vbproj | This file contains settings for a Web service project for use by Visual Basic .NET. This file is only used at the time of development. | No |
.vbproj.webinfo | Contains the path to the project on the development server. | No |
. vsdisco | A file that provides dynamic discovery for all the installed Web services on a server. You should not usually deploy this file to the production server because in doing so, you will lose control over which Web services you want to make available to others. | No |
.disco | A file that provides static discovery of Web services. This file only includes the Web services that you explicitly want to expose to others. | Yes |
.dll | The assembly that contains the compiled output for the Web service project. | Yes |
.pdb | A file that contains the debug symbols for the XML Web service and provides support for debugging of the XML Web service on the server. This file is only created when the project is compiled in the debug mode. | No |
.sln | The file that stores the metadata of the Web service solution. | No |
Copy the Files to the production server After you have identified the files that are required for deployment, the next step is to deploy all these file to a folder on the production server. You can use any copy mechanism such as XCOPY or FTP to accomplish this.
Configure the Web service folder on the production server Just copying the files to the production server is not enough. You also need to configure the target folder as a virtual directory, set access permissions for the virtual directory, and configure the virtual directory as an IIS application.
In addition to the preceding steps, you might also need to perform additional steps such as installing an assembly to the Global Assembly Cache, registering a serviced component with the COM+ catalog, or setting up data access to SQL Server.
For Web applications, Visual Studio .NET provides a Copy Project command that can help developers quickly copy all the files in a project to a different location on the same machine or a different machine.
To use this tool, take the following steps:
Open the Web application that needs to be deployed in Visual Studio .NET.
Select Project, Copy Project. You see the dialog box as shown in Figure 10.16.
Select the Web access method as FrontPage if you need the target project to be automatically set up as an IIS application.
Select Only Files Needed to Run This Application option if you only want to deploy the files necessary to run the Web application.
Because the Copy Project command can also set the destination directory as an IIS application, it saves an extra step required when manually copying the files using XCOPY or FTP. As a Visual Studio .NET developer, this command is an easy option for you to quickly transfer your application to a different computer and test the results.
However, this technique might not be sufficient to deploy a Web service on the production Web server because the Copy Project command does not provide any options for configuring the settings of virtual directory such as an option for configuring directory security. In addition, the Copy Project command still shares many of the limitations of the XCOPY command as mentioned in the previous section.
Another option for deploying a Web service is by using the Visual Studio .NET Web setup project. You can use the various editors available in the Setup project to automate most of the steps required for deploying a Web service to the production computer.
In Step by Step 10.16, you'll use the Web setup project to create a Windows Installer setup package for deploying the Northwind Web service that you created in Chapter 4, "Basic Web Services." You'll use the File System editor to copy all the required files and use the Launch Condition editor to ensure that the Web service is installed on the target computer only if the target computer has support for Microsoft Data Access Components (MDAC) 2.7.
STEP BY STEP10.16 Creating a Web Setup Project for the Northwind Web Service
|
The preceding exercise illustrates the process of creating a Web Setup project. When the project is compiled, the output files are placed in the Release or Debug folder, depending on the active configuration. The contents of the folder are an installer package ( .msi ), executables ( .exe ), and initialization ( .ini ) files. The .msi file is the installation package in the Microsoft Windows Installer format. If the Windows Installer Service is installed on your computer, you can directly start the installation by double-clicking this file. The executable files consist of Setup.exe , InstMsiA.exe , and InstMsiW.exe . Setup.exe (also called the Windows Installer Bootstrapper) bootstraps the installation process by first testing for the presence of the Windows Installer service on the target machine. If the Windows Installer service is not installed, the bootstrapper will first install it using either InstMsiA.exe (for Windows 9x and ME) or InstMsiW.exe (for Windows NT/2000/XP/.NET ) and then instruct the Windows Installer service to execute the installation based on the information stored in the installation package ( .msi file). The setup.ini file stores the initialization settings, such as name of the installation database, for the bootstrap file setup.exe .
But there is one catch here. This setup project will only work on computers where the .NET Framework runtime has been already installed. In fact, when you build the setup project, you will see the following message in the Output window of Visual Studio .NET:
WARNING: This setup does not contain the .NET Framework which must be installed on the target machine by running dotnetfx.exe before this setup will install. You can find dotnetfx.exe on the Visual Studio .NET 'Windows Components Update' media. Dotnetfx.exe can be redistributed with your setup.
On the other hand, when you look at the Web setup project folder in the Solution Explorer window, you will see that it had created a Detected Dependencies folder and included a file named dotnetfxredist_x86_enu.msm in it. But the Exclude property of this file is set to true . This is just a placeholder module that stops Visual Studio .NET from automatically including the .NET Framework files from your installation of the .NET Framework into the project. If you try changing the Exclude property of the dotnetfxredist_x86_enu.msm file to false , Visual Studio .NET won't allow this, and you will get an error at the time of building the project. The error message would say ERROR: dotNETFXRedist_x86_enu.msm must not be used to redistribute the .NET Framework. Please exclude this merge module. You should leave the Exclude property at its default value of true for the dotNETFXRedist_x86_enu.msm dependency.
Actually, the .NET Framework is a complex system, and installing the .NET Framework by just redistributing the files is not enough to get it work successfully on the target machine. The merge module dotNETFXRedist_x86_enu.msm is included in the setup project as a proxy to prevent the dependency resolution system from detecting the .NET frameworks and attempting to redistribute the files as part of the setup package.
Ideally, the .NET Framework must be installed separately. There are several ways to accomplish this:
Ask the user to run setup for .NET Framework from the Windows Component Upgrade CD that comes with Visual Studio .NET.
Ask the user to download the .NET Framework from the Microsoft MSDN Download Center or from the Microsoft Windows Update Website, http://windowsupdate.microsoft.com.
Use the .NET Framework bootstrapper ( Setup.exe ) that checks for the availability of the .NET Framework and install it if it is not already installed.
Of course, for a professional setup program, you would not like to leave it to the users to perform a manual installation of the .NET Framework. Using the .NET Framework bootstrapper Setup.exe is a good idea. Microsoft provides a sample bootstrapper Setup.exe that you can readily use in your projects. I will tell you where to get and how to use this bootstrapper Setup.exe later in this chapter in Exercise 1. For now, I will assume that the .NET Framework is available on the machine where you will deploy your applications.
You can modify the configuration settings for a Web setup project by selecting the project in Solution Explorer and choosing Project, Properties from the main menu. This opens up the Project Property Pages dialog box as shown in Figure 10.24.
The five main configuration properties are as follows :
Output file name Specifies the output filename of the installation package ( .msi file).
Package files Specifies how to package the files. The options are, As Loose Uncompressed Files, In Setup File and, In Cabinet File(s). If the In Cabinet File(s) option is selected, you can also specify the maximum size of the cab files.
Bootstrapper Specifies whether any bootstrap file needs to be created for launching the installation program. A bootstrap is required when the target machine does not have the Windows Installer service already installed. The None option generates only the installation package ( .msi file). The Windows Installer BootStrapper option creates a Setup.exe file capable of installing the Windows Installing service if it is not already installed.
Compression Specifies whether to optimize the installation files for size or speed or if no optimization is required. The value Optimized for Speed will use a faster compression algorithm that will unpack the files quickly at install time. A faster compression algorithm will usually result in larger installation files. The value Optimized for Size will use a compression algorithm that will run slowly but tightly pack the files. If the value None is selected, no optimization is performed.
Authenticode signature Allows you to specify the file containing the Authenticode certificate, Private key file and the Timestamp server URL (provided by the certification authority).
NOTE
Use Application Center to Deploy Web Applications and Windows Services to a Web Farm or a Cluster Microsoft Application Center provides the synchronization capability needed to manage the deployment process across multiple servers in a Web farm or a clustered environment. For example, you can script Application Center to apply specific IIS settings on the virtual directory of a Web server, and then Application Center will take care of applying those settings to all the Web servers involved. For more information on Application Center, see www.microsoft.com/applicationcenter.
The output files generated can be deployed ( copied ) to any target machine and then can be installed and later uninstalled. When an application is uninstalled, all the actions performed by the installer application during the installation on the target machine are undone, leaving the target machine to its original state. You can also choose to repair or reinstall the application installed by clicking the Change button in the Add/Remove Programs dialog box.
Before other developers can use a Web service, they must know about the location of the Web service. You can provide a discovery mechanism on the Web server by deploying a discovery file ( .disco ) on your Web server or by registering the Web service in the UDDI Registry. For more information about how to publish Web service discovery information, refer to Chapter 5, "Advanced Web Services."
GUIDED PRACTICE EXERCISE 10.1Visual Studio .NET provides a Setup Wizard template in the Setup and Deployment Project category. The Setup Wizard collects information to create a setup package in a step-by-step manner. In this exercise, you are required to create a Windows Installerbased setup package for the StringProc Web service that you created in Chapter 4. How would you create a setup package using the Setup Wizard? In this exercise, you will practice creating a setup package by using the Setup Wizard. You should try working through this problem on your own first. If you get stuck, or if you'd like to see one possible solution, follow these steps:
If you have difficulty following this exercise, review the section "Deploying a Web Service," earlier in this chapter. After doing that review, try this exercise again. |
REVIEW BREAK
|
Top |