When Outlook add-ins collide: things far-fetched and real
The idea of this article came to me several days ago when I came across an article with a similar name published by the VSTO team at their blog.
In their article, the VSTO guys say that when you are building a VSTO add-in project, your add-in is also registered in the host application, and when you just open the host application or test a new add-in project, the first add-in gets running too.
What attracted my attention was the video published in their article. I was hoping to see, for example, how building the project generates registry keys, but I saw only “frills and ruffles”, as a famous Russian fabulist put it. So, I don’t recommend wasting your time on that video.
Now back to the point. When do add-ins collide?
A clinch, or the Outlook client for Microsoft Dynamics CRM vs a VSTO add-in for Outlook
This story was started by a recent refund request from one of the Add-in Express for VSTO customers. He wrote:
I have ordered Add-In Express 2008 for VSTO yesterday. Although it is a great product, it hasn’t helped me with the problem I have (DisconnectedContext exception in an Outlook add-in, having something to do with the MS CRM add-in).
To check if the problem was in the code of Add-in Express, we installed Microsoft Dynamics CRM 4.0 on our server and installed the customer’s Outlook add-in on some of our test machines.
Developers of VSTO Outlook add-ins might not even have heard about Microsoft Dynamics CRM. This is a heavy product that stores information about customers, sales, and marketing campaigns in a DB and provides a lot of functionality that may be interesting for your boss. What interests you is the Microsoft Dynamics CRM Client for Outlook.
If you or your administrators break through a number of settings on the server side (SQL Server 2005, IIS, Microsoft Dynamics CRM), install and set up the add-in, you’ll be able to see when add-ins collide.
It’s easy: just create a VSTO add-in project and build it, then run and close Outlook. Now you can find your Outlook hanging in the Task Manager window. Both Outlook 2003 and 2007 are affected on both Windows XP and Windows Vista (you will find a hotfix below). Of course, neither the VSTO add-in nor the Microsoft CRM add-in produce this effect.
A side note. A simple add-in created using the .NET edition of Add-in Express for Office wasn’t affected.
Google shows that this sort of problem existed in the Outlook client for Microsoft CRM version 3.0.
On an Evisions.com forum, a VSTO novice recounts how a simple add-in generates the “Context is disconnected” exception. The problem was solved by installing an appropriate MSMXL update. The story ends with this question from the developer:
“So because the CRM add-in was missing the hotfix, it crashed my VSTO addin?”
I have to admit that it’s difficult to answer such questions.
I believe that numerous problems with custom Outlook add-ins have made eVisions System, a Microsoft Gold Certified Partner, publish the following warning on the Eggheadcafe.com:
After you install Microsoft CRM client for Microsoft Office Outlook on a client computer that is running Microsoft Dynamics CRM 3.0, custom add-ins may not work as expected in Microsoft Office Outlook 2003.
The possible solution needs to be further identified by one of our certified solutions consultants, as the problem may extend further than the initial error shown.
And now, the latest version of the Microsoft CRM add-in is installed but we see the same story (taken from the CommunityDynamics.com forums):
I’m developing an Outlook Add-in for Outlook 2007 using Visual Studio 2008 (C#) . Without CRM Add-In for Outlook (CRM 4.0, Russian) everything works fine, but after installing it and closing Outlook, outlook.exe process hasn’t terminated. For a test, I’ve created a blank default Outlook Add-in C# Project in VS2008 and added some basic logic for testing. Well, the reaction of outlook.exe was the same: everything working correctly when it’s new blank add-in or CRM4Outlook, but together they didn’t allow outlook.exe to close.
At last, Microsoft released a fix for this problem. I have installed it today and my empty VSTO add-in doesn’t make Outlook 2003 SP3 hang on Windows XP SP3. Unfortunately, Vista machines are currently unavailable for testing.
This isn’t a story about how Microsoft fix their bugs. In fact, every developer has left some bugs non-fixed forever. This is a story how one add-in that obviously drives deep into Outlook, MAPI, network connectivity and such may affect another add-in that is based on an intricate system like VSTO.
I don’t like to see or hear how people tear Microsoft to pieces. In fact, Microsoft gives us our jobs. As for negative moments, well, to err is human, to forgive divine.
When googling on the above-mentioned problem, I came across the following outcry on Eggheadcafe.com:
Microsoft support has been ZERO help in resolving this. Yesterday we worked with a moron from the office team that tried to convince us Dynamics CRM was a 3rd party product that they would not support. We were transferred to the office team after submitting several log files and traces to the CRM support team before they gave up and passed it over to office team to figure out. The recommendation from this group was to turn off the crm add in. Then they proceeded to close the case as resolved.
Shame to me, but I also was such a moron once. Some time ago I was convincing a customer that the product for which he needed support was not ours and sent him away. Shortly I found out that it was our product, an end-user Excel add-in. But it was in the realm of our end-user branch, AbleBits who provide Excel add-ins and Outlook plug-ins, and I just didn’t know that they had already released it. And, of course, we could not just close a support case; we needed to have a “Thank you” from the customer to mark the case closed. As you understand, this is just another story.