Collection of Simple Build Objects

As mentioned in Chapter 2, Windows Installer represents the most effective solution for deploying all but the most simple of .NET-based applications. However there are circumstances in which a simple file-copy distribution method may be appropriate, mainly in the case of ASP.NET applications. If you do use a file copy distribution method, there are some special considerations you need to take into account. These include the deployment of:

• Files and Folders

• Assemblies

• Application Resources

• CAB Files

• Registry Settings

We will cover each of these in turn:

Files and Folders

If you use a copy operation to deploy the build outputs for your Web application, you must make sure that all required files are included. Your Web application probably consists of more than just the build outputs — it contains the .aspx files, graphics and other resources, and so on. You can ensure that all required files are deployed by writing a script or deployment utility that interrogates the Visual Studio .NET project file (*.csproj or *.vbproj) to see which other files are required for your project. The project file is actually an XML-based text file, so retrieving the required information from it is a simple matter. It has a <Files> element that lists the other files used by the solution and specifies each file's build action, which you use to determine whether it should be deployed. The following is an example of the <Files> element in a project file:

 <Files>  <Include>   <File RelPath = "AssemblyInfo.cs" SubType = "Code" BuildAction = "Compile" />   <File RelPath = "Global.asax" SubType = "Component" BuildAction = "Content" />   <File RelPath = "Global.asax.cs" DependentUpon = "Global.asax" SubType = "Code"         BuildAction = "Compile" />   <File RelPath = "web.config" BuildAction = "Content" />   <File RelPath = "WebForm1.aspx" SubType = "Form" BuildAction = "Content" />   <File RelPath = "WebForm1.aspx.cs" DependentUpon = "WebForm1.aspx"         SubType = "ASPXCodeBehind" BuildAction = "Compile" />  </Include> </Files> 

The BuildAction attribute can be one of the following:

• None. The file is not included in the project output group and is not compiled in the build process. An example is a text file that contains documentation, such as a Readme file.

• Compile. The file is compiled into the build output. This setting is used for code files.

• Content. The file is not compiled, but it is included in the Content output group. For example, this setting is the default value for an .aspx, .htm, or other kind of Web file or graphic.

• Embedded Resource. This file is embedded in the main project build output as a DLL or executable file. It is typically used for resource files.

Your deployment script or utility should iterate through the <File> elements contained in the <Include> section of the <Files> node, and should retrieve the RelPath values for each file that has a BuildAction set to Content. Any file that has the BuildAction set to Compile or EmbeddedResource is included in the build outputs themselves. (Of course, you should also remember to include the build output in your copy operation.) Those files set to None are not typically required by your solution.

Assemblies

There are some different considerations for deploying assemblies depending on whether they are private or shared, and if they are instrumented.

Private Assemblies

If your private assemblies are not strong-named, you can use a simple copy operation, such as XCOPY, to install them into the production environment. Private assemblies are self-describing and, unlike COM components, do not require information to be added to the registry.

If your private assembly is strong-named, then it does need to be registered. You should the regsvcs.exe tool to register your assembly.

Deployment of Shared Assemblies

You can install an assembly into the global assembly cache without using Windows Installer technology, by using the Gacutil.exe utility. If you use the Gacutil.exe tool, you should normally use the /ir switch, which installs assemblies into the global assembly cache with a traced reference. These references can be removed when the assembly is uninstalled by using the /ur switch.

As with any form of reference counting, using traced references with shared assemblies will only work properly provided it is implemented consistently. If you implement reference counting, you should make sure that you always do so, or it is of little or no use.

Note

Theoretically you can deploy an assembly into the global assembly cache by simply dragging and dropping it to the global assembly cache folder in Windows Explorer. However, this method does not implement any reference counting and so should generally be avoided. In any case the new assembly will not be used until you modify the reference to the strong name in any application that refers to it.

Deployment of Instrumented Assemblies

As mentioned earlier, instrumented assemblies have special requirements as they require a registration stage, when the schema is discovered and registered in the repository. In practice, this means you need to deploy an instrumented assembly you need to run the Installutil.exe utility against the *.dll file corresponding to the assembly.

For more information about using the Installutil.exe utility, see "Installer Tool (Installutil.exe)" on MSDN.

Application Resources

If you are deploying application resources, such as message queues, event logs, and performance counters, these need to be registered. To register these resources, you should run the installutil.exe utility against the *.dll file corresponding to the application resource.

COM/COM+ Objects

If your Web application includes legacy COM objects, they need to be installed and registered properly before they can be used. You can use the RegSvr32 tool to manually register your COM libraries.

IIS 6.0 Settings

If you use the Visual Studio .NET Copy Project command, a new virtual directory is created for you on the target Web server. However, for simple copy operations, the IIS settings are not copied from your development virtual directory and applied to the production copy of your solution. The new virtual directory inherits the default settings from the Web site. Again, you need to apply the appropriate settings separately, either by developing and running IIS scripts or by manually applying the setting your Web application requires.

Serviced Components

You will need to give special consideration to packaging your Web applications if they include serviced components. You can either have your serviced components registered dynamically, or you can use installer classes to ensure that they are installed correctly. If you use installer classes, and you are not packaging your solution in a Windows Installer file, you need to run them with the Installutil.exe tool.

Applying Security Policy

Rather than deploying security policy with Windows Installer files, you can use scripts and batch files along with the Code Access Security Policy tool (Caspol.exe) to apply security policy settings. If you use this approach, you need to disable the prompt for your users that security policy has been changed. You can achieve this by including the following command as the first entry in your batch file:

 Caspol -pp 

For more information about using this tool, see "Code Access Security Policy Tool (Caspol.exe)" on MSDN.

For more information about administering security policy, see "Security Policy Administration Overview" on MSDN

For more information about specifying security policy in code for application domains, see "Setting Application Domain-Level Security Policy" on MSDN.

For more information about using the Mscorcfg.msc wizard, see ".NET Framework Configuration Tool (Mscorcfg.msc)" on MSDN.

For answers to frequently asked question regarding the deployment of security policy, see ".NET Framework Enterprise Security Policy Administration and Deployment" on MSDN.

Registry Settings

Use the Regsvcs.exe utility from the .NET Framework SDK to manually register your assembly containing serviced components.

As mentioned earlier in this chapter, to register a .NET assembly you need to create an entry in the registry that points to Mscoree.dll, which loads and executes the .NET assembly. If you are not using Windows Installer technologies, you can use the Regasm.exe tool to register the .NET assembly. There is a Codebase switch on the Regasm.exe tool that creates a Codebase entry in the registry. The Codebase entry specifies the file path for an assembly that is not installed in the global assembly cache. This switch is mainly used only in development and you should not specify this option if you subsequently install the assembly that you are installing into the global assembly cache.