You’re living in your own private AppDomain–or at least you want to be.


Sam Gentile blogs about ReleaseComObject–between Sam and Andrew Whitechapel I think they have covered this area well.


However, from the standpoint of Office development and add-ins for Word, Excel, etc., the best policy is to stay out of DefaultDomain (which is where you will land if you don’t create a shim–see below) and load into your own AppDomain because even though you may understand when to call ReleaseComObject, chances are some other developer won’t.  You don’t want to be in the same AppDomain as the developer that does this wrong.  Also, being in the same AppDomain as another add-in has it’s own additional set of problems–what if, for example, some other add-in in that domain has loaded a different version of the Office PIAs than the one you want?


Make sure your add-in loads in its own AppDomain.  Today, a shim can make this happen.  See these articles:


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoxpta/html/odc_shim.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoxpta/html/odc_comshim.asp


This is the right approach IMHO for the present.  In the future, Microsoft is looking at providing a managed add-in model that will load you into your own AppDomain by default and do other goodness for add-ins.

Comments (4)

  1. Omar Shahine says:

    I’ve heard loud and clear that the Shim is the way to go, but it seems that no one does this (Lookout and Newsgator). Having to deal with a bunch of C++ code to make some simple managed code work in Office to avoid COM problems isn’t really an optimal solution IMHO. I’ve avoided doing this because I don’t want the overhead of having to deal with another C++ projects and authenticate and all that. The complexity of doing Managed Office development drastically increases at that point.

    But I digress. It’s great that a future version of Office will deal with this. Can’t wait!

  2. Omar Shahine says:

    Er, I mean authenticode.

  3. Eric Carter says:

    I hear you. Like you say–the good news is that we will fix this in a future version of Office. Also I think there is some work going on to make the creating a shim part a little easier for the here and now–to reduce the complexity of this step.

    Why is it so kludgey now?–it’s partly about timing, Office 11 was already pretty much locked down by the time we really realized this was a problem, so we weren’t able to do something nice for Office 11–like for example, make Office 11 managed add-in aware. We did get Office 11 to be managed smart tag aware and load managed smart tags in their own appdomain–this was kind of a wierd thing we got in at the last minute and I think it probably looks wierd from outside Microsoft as to why we fixed this for managed smart tags but not for add-ins.

    But we’re on it for Office 12–there are top minds working on it right now–top minds 🙂

    It would be nice if some of the big popular like Lookout and Newsgator would realize this and move into their own appdomain. It seems like they would at least be getting support calls–there’s no guarantee that they will always be the "first in the pool" to quote from Omar’s blog.

  4. Eric Carter:Sam Gentileblogs about ReleaseComObject –between Sam and Andrew Whitechapel I think they have covered this area well. However, from the standpoint of Office development and add-ins for Word, Excel, etc., the best policy is to stay out of DefaultDomain (which is where you will land if you don’t create a shim–see below) and load into your own AppDomain because even though you may understand when to call ReleaseComObject, chances are some other developer won’t. I agree … but it’s a shame to throw-out the wonderful C# code that I wrote that lets my derive AddIns from a base .NET class. I wrote the shim (or something quite similar to it) to solve a problem with the fact that Groove doesn’t create an AppDomain for each custom tool/component and ran into similar issues. Why can’t Office applications (perhaps Visual Studio, the Shell and IE — and related siblings) examine the registry before co-creating the COM object and actually create the per add-in AppDomain so that we can move beyond the shim approach (it’s oh so W16/32 thunkish to me)?…