Section 5.17.Distribute Excel .NET Applications

5.17. Distribute Excel .NET Applications

One of the big advantages of Excel .NET applications is that they can be easily distributed through a network. Just set the project Assembly Link Location property to a network address and distribute the Excel workbook that uses the assembly. Whenever anyone uses the workbook, the assembly will then be loaded from that network location.

5.17.1. How to do it

Before you can distribute applications in this way, however, you need to make sure your users meet the following requirements:

• They must be using Excel 2003. Prior versions of Excel are not supported for Excel .NET applications.

• The Office 2003 PIAs must be installed on the user's machine.

• The .NET Framework Version 1.1 runtime must be installed.

• The user's .NET security policy must specify Full Trust for the network address from which the assembly is distributed.

The first two requirements are best handled using the Office Resource Kit's Custom Installation Wizard or Custom Maintenance Wizard. See Chapter 4 for information on obtaining and using those tools. You can use those tools to create a chained installation that calls subsequent installation programs, such as the setup for Excel .NET application prerequisites and security policy settings.

The .NET Setup and Deployment projects detect the Office PIAs and .NET Framework as dependencies of the Excel application. According to the Visual Studio .NET Tools for Office documentation, you shouldn't distribute the PIAs through your setup program (instead, use the Office setup to do this as mentioned above). Special steps for creating an installation program for Excel .NET application prerequisites include:

1. Exclude the PIAs from the setup project. These are added as dependencies by default.

2. Optionally, exclude the Primary Output ( projectname .dll) from the installation. Usually, you'll want to distribute the assembly from a network address, rather than installing it on client machines where it is harder to update.

3. Create a batch file, script, or Windows installer to set the client's .NET security policy to enable the assembly to load from its network address.

A simple to set security policy on a client is to use a batch file that calls the .NET utility caspole.exe. The following batch file assigns FullTrust to the network location \\wombat2\SharedDocs\bin:

    REM Adds FullTrust for \\wombat2\Sharedocs\bin location.    %WINDIR%\Microsoft.NET\Framework\v1.1.4322\caspol -pp off -m -ag LocalIntranet_Zone -url  \\wombat2\shareddocs\bin\* FullTrust -n "Excel Project Assemblies" -d " Share point for .NET code running in Office 2003 applications."    %WINDIR%\Microsoft.NET\Framework\v1.1.4322\caspol -pp on

You can also use caspole.exe to remove a security policy, as shown here:

    REM Removes FullTrust for \\wombat2\Sharedocs\bin location.    %WINDIR%\Microsoft.NET\Framework\v1.1.4322\caspol -pp off -remgroup "Excel Project Assemblies"    %WINDIR%\Microsoft.NET\Framework\v1.1.4322\caspol -pp on

Another way to distribute security policies is by using the .NET Configuration utility to generate a Windows Installer file (.msi) for a group policy. To do this, follow these steps:

1. Configure you machine with the security policies you want to deploy.

2. Start the .NET Configuration utility for the current version of the .NET Framework.

3. Select the Runtime Security Policy item in the treeview and click Create Deployment Package, as shown in Figure 5-22.

   Figure 5-22. Creating a Windows Installer for .NET security policies

   
   
   

4. Follow the steps in the wizard to create an .msi file containing the security policies to deploy (Figure 5-23).

5. Click Next, then Finish to create the Windows Installer file (.msi).

Once you've created the .msi file, you can deploy that policy to your enterprise by using the Group Policy Editor snap-in from the Microsoft Management Console (mmc.exe) or by installing the .msi file individually on client computers.