In this article I intend to share some of the common issues encountered during Outlook Add-in (VSTO) development and how these may be addressed. There is interesting information available out there on the web that would help out the VSTO community and I have also tried to provide the links to these articles.
Is there a simpler way to add Prerequisites for VSTO through VS2005?
In an earlier article Walkthrough - Automatic Update Process for Outlook Add-in Solutions, I had discussed setting up the prerequisites through the Launch Conditions Editor. This may be a time-consuming process and may have to be repeated for other VSTO projects.
I found some interesting information here on how you can achieve it by selecting the VSTO pre-requisites directly in your Setup project. You only have to do it once and it makes life easier.
Read the instructions in file 'InstallNotes.txt' that is included as part of this download on how to set it up on your development machine. Once installed, in VS2005 you have to right click the 'VSTO Setup' project and selected 'Properties'. Click on the 'Prerequisites' button that would pop-up something similar to the screen shot shown below.
Click here to download Visual Studio Tools for Office runtime (vstor.exe).
Click here to download Office 2003 Primary Interop Assemblies (PIA) redistributable (O2003PIA.exe).
How do I Sign an Assembly prior to deployment in VS2005?
Your VSTO application needs to be signed with a strong name prior to deployment. To sign the assembly in VS2005, follow these steps:
- Right-click your VSTO project and under Properties, select the Signing option.
- Choose New and provide the key file name accordingly.
- Uncheck the box that protects the key file with a password.
How do I manually setup code access security (CAS) policy?
Once you have the .msi file generated from your VSTO Setup project, you are all set to install your solution. But you still need to consider what permissions your application requires on the end user machine and this is where CAS policy comes in.
For more information of setting up CAS at the User, Machine and Enterprise levels, refer to the article in this link.
To set up CAS for your application at the "User level", follow these steps:
How do I programmatically configure CAS as part of Installation?
I found a sample code (available in both C# and VB.NET) published here, which may be used to handle CAS programmatically. The author has excellently handled both Install and UnInstall in his code.
Follow these steps:
- In your VS2005 Solution, add a new Class Library project.
- Delete the default Class1.cs file created.
- Add a new Installer Class (SetSecurity.cs)
- Cut/paste the relevant code from sample into SetSecurity.cs that you just created.
Note: You will have to include the following 3 namespaces in the SetSecurity.cs class (which were missing)
- Configure the
PermissionSet in the code to your needs.
private readonly string installPolicyLevel = "Machine";
private readonly string namedPermissionSet = "FullTrust";
- In the Outlook Setup project, the Primary output from SetSecurity project needs to be included and using the Custom Actions Editor you may add it as a Custom Action for Install and UnInstall as shown below.
- Build the Outlook Setup project (which references both your security project and Outlook Add-in project) and Install them on the End-User machine. A snapshot of the Code Access Security (CAS) entry in the .NET Framework 2.0 Configuration is shown below.
Why is the URL to the deployment server missing in the Manifest file?
A concern normally raised by the user community is that the Manifest file on the .msi installed machine does not have any reference to the published URL. There is a roundabout way to handle this.
Follow these steps:
- In the screen-shot below, the next version of the release during a Publish in the below Outlook Add-in project would be 220.127.116.11.
- Right-Click the Outlook Add-in project and do a Publish to some deployment server. Refresh the project and look for a manifest file inside the bin\Release\xxx.publish\xxx_18.104.22.168 folder (where 'xxx' is your Outlook Add-in project name).
- Open up the manifest file and you would notice that "codebase" has the "complete URL" to the deployment server. This is the one that finally needs to show up in the end user machine.
- Notice that the setup project shown below has the Primary output from both MyOutlookAddin and SetSecurity projects. We need to exclude the manifest file from the primary output of the Outlook Add-in.
- Right-click on the Primary Output from Outlook Add-in and select Exclude Filter.
- Click on Add Filter to exclude the manifest file shown in the primary output.
- You now have to manually add the right manifest from the bin folder that was published. Right click on the Setup project and select Add followed by File.
- Navigate to bin\Release\xxx.publish\xxx_22.214.171.124 folder and select the recently published manifest and add it to the project. Open the manifest file to confirm that the URL to the published server exists in the manifest as shown below.
- Rebuild your setup solution and install it on the end user machine.
The objective of writing this article was to share the information I gathered from both experience and reading what the experts out there had to say, so as to provide a helping hand to the VSTO community.
This way of setting up CAS is good enough for the application to run on one machine. Unfortunately, we cannot expect all end-users to manually set up the CAS for your Outlook Add-in assembly.