I developed an Outlook 2003 add-in which uses the com dll redemption. I created a visual studio 2008 setup project, added a custom action to run “caspol.exe -machine -addgroup 1 -strong -hex [key] -noname -noversion FullTrust -n \”Name\” -description \”desc\” and moved the registry keys under software to HKLM as described in http://msdn.microsoft.com/en-us/library/cc136646.aspx#AutoDeployVSTOse_InstallingtheAddinforAllUsers to ensure all-users compatibility.
I included the redemption.dll in the setup with vsdrfCOMSelfReg (vsdrfCOM throwed an error).
My problem is: When installing the setup on a test machine under an admin account, it runs fine under all users, however when we use the company wide software deployment which runs under a system account the setup executes but the add-in wont load. If I repair the installation with an admin account again it loads just fine. Shouldn’t a system account have the required permissions to install all of the components? What options do I have?
Thanks for any suggestions.
After some endless nights I finally figured out the problem. It really was all about Code Access Security and the caspol.exe
Some tips for deploying Outlook 2003 Add-Ins (Outlook 2007 is different).
First of all, on your test client, be sure to set the Windows environment variable VSTO_LOGALERTS=1, since this will write all the errors of the Add-In to a log file which is located in your target install directory. It is also very important to know, that if your Add-In throws an exception during startup, it will be disabled in the registry on the next launch of Outlook (see here What can cause Outlook to change a COM-addin's LoadBehavior to 2 – other than unhandled exceptions?). This can cause some confusion when you’re not aware of it.
Now let’s move on to the caspol problems. Be sure to sign your assemblies with a strong name key first. Next, you need to make sure that your assemblies gain full trust on the client. To do this you may run the caspol.exe with the following settings: “caspol.exe -machine -addgroup 1 -strong -hex [key] -noname -noversion FullTrust -n \”Name\” -description \”desc\”. With these arguments, you will give all the assemblies signed with your key earlier, full trust on the machine. This is way better than giving a whole directory FullTrust.
In a production environment, you will certainly want to create a setup for your Add-In. You might also create a custom action for your setup project to do all the caspol stuff automatically. You can use the sample code provided here “http://msdn.microsoft.com/en-us/library/cc136646.aspx#AutoDeployVSTOse_CreatingtheCASPolicy” but watch out: Check for -pp off in the caspol arguments. If the policy change prompt is on then you’re automatic installation will fail since it requires user interaction. set -pp to off, execute the policy and set it back on. Watch out again: The sample code does not wait for exit of the process.
After I figured all that out, the deployment of the Add-In was easy, even for an “all users” installation. Hope that helps anyone out there.