MidniteBlog

Outlook Add-in Deployment issues

So after you’ve built your new whiz-bang Outlook Add-in, you will want to deploy it to your user’s machines. It runs fine on your development machine, but when you copy it (or use the installer to install it) to another box, it doesn’t run so fine. Here are some deployment issues I ran into that weren’t really documented very well. Hopefully they will save you some time.

- Outlook recognizes your Add-in and shows it in the COM Add-ins dialog, but won’t load it. The COM Add-ins dialog will say something like “error in loading.” This is a perplexing one and it was quite a problem to solve. I ended up downloading a file system sniffer and discovered that Outlook was trying to load something called “Extensibility.dll.” What in the world is that?
Technically speaking: “This assembly is necessary for referencing the IDTExtensibility2 interface that shared add-ins must implement, as well as creating command bars and command bar controls that provide the primary interface for users of the managed COM add-in in the application.”
In other words, it is a Microsoft file that Outlook needs to talk to plug-ins. It is also, apparently, not on the list of redistributable components. This is quite an unfortunate circumstance.
From what I have read on the Microsoft team forums (e.g.
http://forums.microsoft.com/MSDN/ShowPost.aspx
?PostID=1436656&SiteID=1)
there isn’t a really good solution.
The best one I saw was to install the “VS SDK” which contains an MSI that contains Extensibility.dll. Are you kidding? Install the VS SDK on a user’s machine so an Outlook Add-in will load????
If anyone else has better ideas please post them. (See “The Answer” below)
- Does the Outlook Add-in have to be in the GAC? As best as I can tell, the answer is No. I never had to put it there to get it to load and run. I did, however, strong sign the Add-in because of the additional security that provides, and it will need to be strong-signed if you are going to put it in the GAC.
- A dependency I noticed only on Vista was msvcr80.dll. I suspect it will be needed on other OSes as well, however.

Development Issues

Here are some issues I ran into when developing the Outlook Add-in.

- When you add a reference to Microsoft forms (fm20.dll) (if you are going to place an Active-X control on your new Contact tab), make sure it is the reference that creates the Microsoft.VBE.Interop entry in the Object Browser (View/Object Browser). There was another Microsoft forms to choose from when I added it in the “Add Reference” dialog and apparently I picked the wrong one because it did not work until I took out the incorrect reference and added the other one that creates the Microsoft.VBE.Interop reference in the Object Browser.
- To debug your Add-in with Visual Studio, go to Project/Properties/Debug tab and under “Start Action” choose “Start external program” and put the path to Outlook on your machine in the edit box there. This will make your life much easier in fixing problems.
- If your Add-in suddenly stops working it is possible that Outlook unloaded it (Outlook will mercilessly unload any Add-in it thinks has misbehaved). In Outlook, go to Tools/Options then “Other” tab, choose the “Advanced Options” button, then the COM Add-Ins button which will bring up the COM Add-ins dialog. Make sure your Add-in is still checked.
- If Outlook really thinks your Add-in has been bad, it will totally disable the Add-in. In this case (this was a hard one to figure out because of the lack of docs) go to Help/”About Microsoft Office Outlook” and click on the “Disabled Items” button there. If your Add-in was very naughty it might end up here in the Disabled Items list. Click on it and then the Enable button to reenable.
- I did NOT need to use caspol to set code access security policies. Not to say that it won’t be needed at all, but I don’t think it is as critical to getting your app running as some of the discussions would lead you to believe.
- In Outlook 2007, in order to get your Add-in recognized, you have to go to Tools/Trust Center…, then click on Add-ins and make sure your Add-in is in the “Active Application Add-ins.” If not, pick “COM Add-ins” from the drop down at the bottom, then click on the “Go” button. This will bring up the familiar “COM Add-ins” dialog. Pick your Add-in from the “Add-Ins available” list and you should be good to go.

Security Issues

- Under the Outlook dialog found at Tools/Macro/Security on the “Security Level” tab, if “High” is checked and on the “Trusted Publishers” tab, if “Trust all installed add-ins and templates” is NOT checked, Outlook will prompt the user on startup to see if they want to run the add-in. This is a pain, but just the way Office security works.

Vista-specific issues

- When you try to register (with regsvr32.exe) your unmanaged C++ shim (if you wrote one) in Vista with UAC on, you will have permission issues and it will not register. According to Microsoft, this is “expected” with UAC on. They suggest changing the way your component registers (presumably not trying to write to HKLM), or to run regsvr32.exe from an “elevated command prompt” which you get by right-clicking on command prompt icon and choosing “Run as Administrator.”
They also suggest running Visual Studio in “admin mode” which you can do by right-clicking on Visual Studio icon and choose “Run as administrator” from the context menu. (More info here:
http://blogs.msdn.com/vcblog/archive/
2006/09/06/742187.aspx).

General Info

- Registry key where Outlook tries to find add-ins:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\
Outlook\Addins

The Answer:

How to redistribute Extensibility.dll
After looking long and hard for the answer as to how to redistribute Extensibility.dll (which shared Office add-ins need in order to reference IDTExtensibility2), I decided to give in, grit my teeth, and submit the question to Microsoft support. After spending 2 hours on the phone and getting transferred no fewer than 5 times, someone that was reasonably intelligent-sounding promised to get right on the problem and get back to me.
After a day I got another e-mail from someone else in Microsoft support asking again what the problem was, to which I replied “Is Extensibility.dll redistributable or not” and, “If so, is there an install for it?”
After being sent yet again to another support engineer, it began to look like we might get a real answer. Another couple of days went by trading e-mails with this new person, and I finally got the answer.

Here it is, in case you are trying to solve the same problem.

MSFT support claims extensibility.dll is redistributable, but you have to do it through a specific .msi (no explanation as to why we need the .msi as opposed to just distributing the .dll).

The KB fix (VS2005-KB908002-ENU-x86.EXE) at the following address provides a copy of the needed .msi along with some other Office fixes:
http://support.microsoft.com/kb/908002/en-us

The fix is called “Shared Add-in Support Update for the Microsoft .NET Framework 2.0 (KB908002),” and Microsoft says that it provides the required fixes in Office and the .NET Framework together with the solutions that you write in Visual Studio 2005.

When you run the .exe there as instructed, it gives you an .msi (extensibilityMSM.msi), as expected, in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\KB908002. According to my support contact, this .msi is distributable (There is a eula.txt there in the “en” directory underneath the .msi with the legal details).

So the answer is to let your install kick off extensibilityMSM.msi and then Extensibility.dll should be in place on the user’s machine.

What an ordeal just to find out such a simple answer from Microsoft support.
Microsoft: Is a week’s response time the best you can do to support engineers that pay a premium for your services — especially on such an easy question? Also, would it be too much to ask to bring some of the support back to native English speaking countries so we are not trying to communicate with ESL people in India? I will certainly be advising my organization against buying Microsoft “support incidents” for all our developers in the future. Better to pay for the incidents on an emergency, last-ditch basis.

midniteblogger