Setup and Deployment Projects

for RuBoard

Assemblies may be deployed as regular stand-alone binary code files (i.e., DLL or EXE files), or they may be deployed using CAB, MSI, or MSM files. A CAB file is a cabinet file with the .cab file- name extension. A CAB file is used to compress and combine other files into one convenient manageable file. Although CAB files can be used for general purposes, they have traditionally been used for CD-based and Web-based installation purposes. MSI and MSM files are Microsoft Windows Installer files, with the .msi and .msm file-name extensions. MSI files (and indirectly, MSM files) are used with the Msiexec.exe Windows Installer program to deploy stand-alone applications and reusable components .

MSI files are Microsoft Windows Installer installation packages that have the .msi file-name extension. MSM files are merge modules that have the .msm file-name extension. Windows Installer supports software installation, repair, upgrade, and removal. Windows Installer packages are self-contained database files that provide installation information to the Windows Installer service. An MSM file has an internal structure similar to that of an MSI file, but it is somewhat simplified. Unfortunately, an MSM file cannot be used directly by Windows Installer, since it lacks certain important database tables. Instead, the MSM file must be merged into an MSI file to be used in an actual installation session. However, MSM files are useful for separating out shared installation information into an independent package that can then be merged into many other MSI packages.

Installation may be accomplished using the Windows Installer, Internet Explorer, or simply by manually copying assemblies and associated files. To help the programmer develop setup and deployment solutions, Visual Studio.NET provides several templates and wizards for generating starter setup projects. These tools are available by way of the New Project dialog box under the Setup and Deployment Projects node, as shown in Figure 7-12. As you can see, the following templates are provided for generating starter setup and deployment projects.

Figure 7-12. Setup and deployment project templates.

graphics/07fig13.gif

  • Cab Project

  • Setup Project

  • Setup Wizard

  • Merge Module Project

  • Web Setup Project

CAB Project

A CAB project creates a cabinet file containing any number of other files that can be used for traditional deployment purposes. CAB files have been used to package legacy COM components deployed over the Internet, and they have also been used in traditional CD-based installation programs. CAB files may now also be used for packaging managed code. However, for .NET deployment, a CAB file can contain only one assembly, and the CAB file must be assigned the same name as the contained assembly, but with the .cab extension. For example, an assembly named SomeComponent.dll would have to be contained in a cabinet file named SomeComponent.cab .

Setup Project

The Setup project template creates a Windows Installer .msi file for a desktop or distributed application. A Setup project is not intended for deployment of Web-based applications, since a specialized Web Setup project is used for that purpose. A Setup project produces a program that installs an application onto a target machine. You may create Setup projects within the same solution that contains the other projects to be deployed. In a multitier solution, you can create one setup project for each project that is to be deployed to a particular target computer. For example, in a simple three-tier solution, you would probably have three deployment projects. Two simple deployment projects would set up the client and server. A third deployment project would then look after the more complex middle- tier business logic. Additional deployment projects may come into play if the solution was highly complex, or if merge modules were incorporated into the deployment strategy.

To create a Setup project, select File New, then select Project. In the New Project dialog box, select Setup and Deployment Projects as the Project Type. Finally, select Setup Project as the Template, specify name and location, and then click OK. The result of this is shown in Figure 7-13, showing Solution Explorer and the File System Editor.

Figure 7-13. Solution Explorer and the File System Editor in a Setup project.

graphics/07fig14.gif

Once the initial Setup project has been created with the Setup Project template, it can be further developed using the File System Editor. The File System Editor allows you to drag and drop, or copy and paste, files to be deployed by the Setup deployment project, and control their destinations on the target machine. Initially, the File System Editor shows an initial list of destination folders that you can deploy into, and you can also add your own folders to this list.

Once you have an MSI file created, you can use Windows Installer, as shown in the following command line:

 Msiexec /i SomeSetup.msi 

The Windows Installer program then starts up and displays a series of installation dialogs. After Windows Installer has completed the deployment, you can try running the installed application to verify that the installation was successful. If you run the same command Msiexec /i SomeSetup.msi , it will detect that it already exists, so it gives you the choice to either repair the installation or uninstall it.

Merge Module Project

A Merge Module project packages reusable setup information that can be independently maintained and then merged as a shared installation package into other installation packages. A Merge Module project produces a merge module .msm file that can be merged into .msi files. This allows you to share common assemblies, associated files, registry values, and setup functionality among multiple applications.

To start the Merge Module Project Wizard, select File New, then select Project. In the New Project dialog box, select Setup and Deployment Projects as the Project Type. Finally, select Merge Module Project Wizard as the Template, specify name and location, and then click OK.

Typically, an MSI file is intended for use by the end user for installing a complete solution in one simple deployment session. In contrast, an MSM file is typically intended for use by other developers who want to use components that you have developed in their setup projects. Those other developers can merge your MSM file into their own MSI file for deploying your components into their test and development environments, as well as for their ultimate end user . End users should not be provided any MSM files, since they are not directly installable using Windows Installer, and they are not very friendly to work with.

To add an existing merge module project to a Setup project, create or open the Setup project, select File Add Project, and then select Existing Project. In the Add Existing Project dialog box, browse to the location of the desired merge module project, select the associated .vdp deployment project file, and then click Open.

We have just added the merge module project to the solution. We now have to add it to the Setup project itself. Select the Setup project and invoke "Add:Project Output," then select the merge module project in the dialog that appears.

Web-based Deployment

Web-based deployment uses Internet Explorer on the client to automatically download assemblies packaged as EXE, DLL, or CAB files on demand from a .NET Web server. HTML files can dynamically deploy assemblies as well as configuration files to control the binding process. Web-based deployment results in assemblies being downloaded into the client's assembly download cache on demand.

The Xml <object> tag is used to download and install assemblies, using either a relative or an absolute URL. The following shows a relative URL example, where the assembly is located relative to the directory of the containing HTML file on the Web server.

 <object     id="SomeComponent"     classid="./SomeDirectory/MyComponent.dll#SomeClass">  </object> 

The following shows an absolute URL example, where the assembly is located on a specified Web server.

 <object     id="SomeComponent"  classid="http://www.acme.com/MyComponent.dll#SomeClass">  </object> 

By default, IE creates a separate application domain for each Web site that it encounters. An application domain is a .NET feature that can be thought of as a scalable lightweight process. An application domain efficiently provides fault isolation without the overhead of running multiple processes. Each application domain may optionally have its own configuration file to control binding and security. Also, a configuration file may specify an isolated application domain for individual applications on the same Web server. Each HTML file that specifies the same configuration file will be placed into the same application domain. Application domains are discussed in the next chapter.

for RuBoard


Application Development Using C# and .NET
Application Development Using C# and .NET
ISBN: 013093383X
EAN: 2147483647
Year: 2001
Pages: 158

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net