Andrew Whitechapel : COM Shim

COM Shim 2.3.1.0 Bug Fixes

andreww — Thu, 26 Feb 2009 21:48:00 GMT

A customer (VSP) was using the COM Shim and identified a scenario where a bug in the shim code could cause the host application to remain in memory indefinitely – thanks, VSP for finding this and bringing it to our attention! Misha did some ninja debugging and pinpointed the problem.

The shim is described here and here.

The problem is that the ManagedAggregator.CreateAggregatedInstance method is taking in an IComAggregator object (the CConnectProxy object, which is the outer object in the aggregation), but is not releasing it. This is a problem because the object was passed from the native shim code to the managed aggregator code and wrapped as an RCW. If we don’t release the RCW, the CLR will potentially hold on to it (and the underlying COM object) until the corresponding AppDomain is unloaded. However, in the current implementation the AppDomain is unloaded when COM object’s reference counter reaches zero. This essentially constitutes a circular reference problem thus preventing the host from terminating cleanly. The fix is simple: in the finally block, add a call to Marshal.ReleaseComObject on the outer object:

public void CreateAggregatedInstance(

string assemblyName, string typeName, IComAggregator outerObject)

{

IntPtr pOuter = IntPtr.Zero;

IntPtr pInner = IntPtr.Zero;

try

{

pOuter = Marshal.GetIUnknownForObject(outerObject);

object innerObject =

AppDomain.CurrentDomain.CreateInstanceAndUnwrap(

assemblyName, typeName);

pInner = Marshal.CreateAggregatedObject(pOuter, innerObject);

outerObject.SetInnerPointer(pInner);

}

finally

{

if (pOuter != IntPtr.Zero)

{

Marshal.Release(pOuter);

}

if (pInner != IntPtr.Zero)

{

Marshal.Release(pInner);

}

// FIX: Bug discovered after release of 2.3.1.0.

// We call ReleaseComObject on the outer object (ConnectProxy)

// to make sure we delete the RCW, and prevent the CLR from

// holding onto it indefinitely (and keeping the host alive).

Marshal.ReleaseComObject(outerObject);

}

While we were in the code, Misha identified another potential problem. There are scenarios where it is possible that the CConnectProxy::FinalRelease may not get called – for example, if you have some other add-in or automation client that connects to this shimmed add-in via the COMAddIns collection. Right now, the FinalRelease is implemented to clean up and unload the appdomain. To make sure this always happens, you can simply move all that code to the end of the OnDisconnection method instead:

HRESULT __stdcall CConnectProxy::OnDisconnection(

ext_DisconnectMode RemoveMode, SAFEARRAY **custom)

{

HRESULT hr = S_OK;

hr = m_pConnect->OnDisconnection(RemoveMode, custom);

if (SUCCEEDED(hr))

{

m_pConnect->Release();

m_pConnect = NULL;

}

// FIX: Bug discovered after release of 2.3.1.0.

// Move the code that releases the aggregated innner object

// from the CConnectProxy::FinalRelease to
// CConnectProxy::OnDisconnection.

// This ensures that the code gets called even if this add-in gets

// handed out via the COMAddIns collection to other consumers.

if (m_pUnknownInner)

{

m_pUnknownInner->Release();

}

if (m_pCLRLoader)

{

m_pCLRLoader->Unload();

delete m_pCLRLoader;

m_pCLRLoader = NULL;

}

return hr;

}

// FinalRelease will be the last thing called in the shim/add-in, after

// OnBeginShutdown and OnDisconnection.

void CConnectProxy::FinalRelease()

{

}

Thanks again to VSP for spotting the original problem, and to Misha for identifying the cause and the fix.

COM Shim Wizard 2.3.1.0

andreww — Wed, 27 Aug 2008 20:36:00 GMT

We’ve released a slight update to the COM Shim Wizard. This is available as a free download here, and the covering article is on MSDN here. The differences Between v2.3.0.0 and v2.3.1.0 are summarized below.

Setup

The major difference between v2.3.0.0 and v2.3.1.0 is that v2.3.0.0 was built to install with Visual Studio 2005, whereas v2.3.1.0 installs with either Visual Studio 2005 or Visual Studio 2008, or both. The setup for the COM Shim Wizard now gives you the option to choose which version or versions of Visual Studio to install for. There are 3 additional enhancements to the setup for the COM Shim Wizard v2.3.1.0:

1. The setup disables installation on a per-user basis. This is because installing per-user (and therefore registering to HKCU) causes problems on Vista with UAC turned on, or when running Visual Studio in an elevated process.

2. The custom actions are set to NoImpersonate, so that they work correctly on Vista with UAC on.

3. The setup is formatted so that any error messages are displayed (otherwise they are not visible in Vista, the user just sees Error 2869).

CLR Start Bug

I documented this fix as a community comment added to the MSDN documentation for the COM Shim Wizard v2.3.0.0. Part of what the shim does is to load the CLR: it does this by calling CorBindToRuntimeEx. We test the return from CorBindToRuntimeEx, and if it's S_FALSE, this indicates that the CLR has already been loaded. In the released version of the shim, if we get S_FALSE, we simply return.

However, there is a scenario where the CLR could already have been loaded but not started. It's an unusual scenario: it could happen if some other managed code was loaded into the process but never executed. The problem is that the shim code assumes that if the CLR is loaded it is not necessary for us to start it. Of course, if the only other things in the process that load the CLR are all shims created with the COM Shim Wizard, then this assumption would be true – because the first one to load would have loaded the CLR and started it. However, this assumption doesn't hold if there are other native components that load the CLR but don't start it.

We fixed this in the code generated by v2.3.1.0 of the wizard by simply removing the test for S_FALSE – this works because we do call Start later on.

Post-build step to copy ManagedAggregator.dll

In v2.3.0.0, a post-build step in the generated shim project copies the ManagedAggregator.dll from the \bin\debug folder unconditionally. We changed this in v2.3.1.0 to copy the dll from the target folder for each project configuration. For example, for a standard debug configuration, it will copy from \bin\debug; but for a release configuration, it will copy from \bin\release.

COM Shim CLR Loader Bug

andreww — Mon, 26 Nov 2007 03:42:00 GMT

The latest version of the COM shim wizards was released back in the summer, here. With the help of Adam Smith of Xobni (and of course, the indispensable Misha), we've identified a minor bug with the project code that the wizard generates for the shim. In fact, this bug was identified prior to the last release (as you can read in Misha's blog comments here), but we simply forgot to include the fix – my apologies for that.

Part of what the shim does is to load the CLR: it does this by calling CorBindToRuntimeEx. We test the return from CorBindToRuntimeEx, and if it's S_FALSE, this indicates that the CLR has already been loaded. In the released version of the shim, if we get S_FALSE, we simply return.

However, there is a scenario where the CLR could already have been loaded but not started. It's an unusual scenario: it could happen if some other managed code was loaded into the process but never executed. The problem is that the shim code assumes that if the CLR is loaded it is not necessary for us to start it. Of course, if the only other things in the process that load the CLR are all shims created with the COM Shim Wizard, then this assumption would be true – because the first one to load would have loaded the CLR and started it. However, this assumption doesn't hold if there are other native components that load the CLR and don't start it.

The change to fix the bug is to EITHER call ICorRuntimeHost::Start if we get S_FALSE, OR simply don't test for S_FALSE at all – this works because we do call Start later on. The fixed code is shown below, with the S_FALSE test removed and highlighted:

HRESULT CCLRLoader::LoadCLR()

{

HRESULT hr = S_OK;

// Ensure the CLR is only loaded once.

if (m_pCorRuntimeHost != NULL)

{

return hr;

}

// Load the CLR into the process, using the default (latest) version,

// the default ("wks") flavor, and default (single) domain.

hr = CorBindToRuntimeEx(

0, 0, 0,

CLSID_CorRuntimeHost, IID_ICorRuntimeHost,

(LPVOID*)&m_pCorRuntimeHost);

// If CorBindToRuntimeEx returned S_FALSE, the CLR has already

// been loaded.

//if (hr == S_FALSE)

//{

// return hr;

//}

// If CorBindToRuntimeEx returned a failure HRESULT, we failed to load

// the CLR.

if (!SUCCEEDED(hr))

{

return hr;

}

// Start the CLR.

return m_pCorRuntimeHost->Start();

}

We'll work with the gentle folks at MSDN to get the COM Shim Wizard download updated as soon as possible. In the meantime, you can make this simple change to the wizard-generated code in ClrLoader.cpp. Note that this test for S_FALSE occurs in all variants of the shim code – that is, the shim for add-ins, smart tags and real-time data components. It can be removed from all these variants.

Thanks again to Adam Smith, Shamil Salakhetdinov, and Misha for identifying the problem and the fix.

Updated COM Shim Wizards

andreww — Thu, 05 Jul 2007 19:05:00 GMT

In our spare time, Misha and I have been working on and off on the COM Shim and associated COM Shim Wizards for the last few years, and we've just published a new version here: Isolating Microsoft Office Extensions with the COM Shim Wizard Version 2.3, with the accompanying download here.

The new version includes all the old projects for smart tags and RTD components – these have not changed since the previous version. The significant changes in the new version are all in the add-in shim and the add-in shim project wizard. Apart from minor bug fixes and code cleanup, the changes all relate to the new extensibility interfaces introduced with Office 2007. All the new interfaces are now supported in the shim (including IDocumentInspector, which is kind of redundant, but included for completeness). See my previous post on the new interfaces: Office 2007 New Extensibility Interfaces.

In another post, Why is it so hard to shim IRibbonExtensibility?, I discussed the reasoning behind the change in the shim design. Basically, it comes down to the need to support the potentially undefined methods on an automation interface (like IRibbonExtensibility). The IRibbonExtensibility interface only defines one method (GetCustomUI), but Office will expect to be able to call back on your IRibbonExtensibility object for any number of additional methods that are not defined in the interface. This is standard behavior for automation interfaces. For example, in your ribbon XML, you might specify that the callback method for a button is say MyButtonCallbackMethod, a method that is obviously not defined in the IRibbonExtensibility interface. Office uses the IDispatch interface implemented by all automation objects to call back on these "undefined" methods.

The same model is used for Excel automation add-ins. These can implement IDTExtensibility2, but they don't have to. Indeed, they don't have to implement any defined interface beyond IDispatch (the automation interface). All the UDFs will be automation methods.

The old add-in shim (and the shim for smart tags and RTD components) uses containment to proxy the defined method calls on the specific interfaces that the shim is shimming (IDTExtensibility2, ISmartTagRecognizer, ISmartTagAction, IRtdServer, etc). The new add-in shim still uses containment for the known interface it proxies (IDTExtensibility2), but it uses aggregation for the automation interfaces used in Ribbon customization and Excel automation add-ins (and potentially any other new automation interfaces that Office might introduce in later releases).

To achieve this aggregation, there's a bit of work to call Marshal.CreateAggregatedObject – this is a static method in a sealed abstract base class in the .NET base class library. In order to call this from the (unmanaged) shim, we have to instantiate a tiny managed component to call it on our behalf. Hence the shim is now slightly more complex than it was – in that, it now has 2 pieces, one unmanaged (as before) and one managed. If you read my previous discussion of the reasoning behind this design, you'll realize that we could have built the new shim in a much simpler way by overriding QueryInterface and blindly aggregating all the interfaces that we don't proxy by containment. Right now, this would probably work, because right now Office doesn't transition from any of these interfaces to any other interfaces. But, this model would break COM identity rules, and your shim would be broken if Office ever decided to optimize their interface querying differently from the way they do now. So, the slight added complexity of 2 pieces in the new shim is the price we pay for a robust model that is resilient to future changes, and doesn't break any rules.

Our day job (or night job, in Misha’s case) is building VSTO, so it might seem strange that we spend our spare time building tools and components that support an alternative add-in model to VSTO. The simple fact is that we recognize that VSTO add-ins do not cover the totality of customer requirements (for example, no support for versions of Office earlier than 2003, and for “minor” Office apps such as Publisher). The main reason that VSTO doesn’t support all permutations is that the test matrix would be fantastically large. Everything is a trade-off, and we believe the trade-off between shipping good tools that cover some large percentage of customer requirements in a reasonable time frame, versus shipping tools that cover 100% of requirements in an unreasonably long time frame, is an optimal one. So, use VSTO where you can – and for those scenarios where you can't, do shim your add-ins, and you can use the COM Shim Wizard tool to help you build suitable shims.

Why is it so hard to shim IRibbonExtensibility?

andreww — Fri, 09 Mar 2007 22:35:00 GMT

The COM Shim Wizards are a set of Visual Studio 2005 project wizards that automate the generation of COM shims for non-VSTO managed Office extensions. These shims support COM add-ins, smart tags and real-time data components. The shim for each is broadly similar, although there are obvious differences to allow for the different interfaces that each component implements, registration differences and so on.

There have been many questions in the forums over the last few months as to why these shims do not support the new Office 2007 extensibility interfaces, particuarly the interfaces for custom ribbons, custom task panes, and custom form regions. The short answer is that the shims are written to support a specific set of interfaces (IDTExtensibility2, ISmartTagRecognizer, ISmartTagAction, IRtdServer), and would therefore need to be extended to support the new interfaces (IRibbonExtensibility, ICustomTaskPaneConsumer, FormRegionStartup, etc).

OK, so why don’t we update the shims to support these new interfaces? The answer is that for all the interfaces except IRibbonExtensibility, this would be fairly simple. The problem is IRibbonExtensibility.

First the good news. The good news is that Office is generally moving towards an extensibility model where all new interfaces are implementable via COM add-ins (managed or unmanaged). More good news: all of these new interfaces are accommodated by the VSTO runtime if you’re building VSTO add-ins. If you’re not building VSTO add-ins, you simply implement the interface in your add-in code directly (in fact, you can also do this in VSTO add-ins if you don’t want to use the higher-level VSTO abstractions). The COM shim can be easily extended to specifically support most of these interfaces.

Now the bad news: although all the interfaces are implementable by add-ins, they are not all the same. Specifically, the programming model is different. Most especially, the programming model for ribbon extensibility is completely different from all the other interfaces. All the other interfaces follow the same model as any traditional COM interface. That is, the interface defines a number of methods, which are the communication points (the “interface”) between Office and the add-in. IRibbonExtensibility does define such an interface (it is a COM interface, after all), but it also assumes additional methods that are not defined in the interface.

IRibbonExtensibility only defines one method (GetCustomUI), BUT Office will expect to call back on your IRibbonExtensibility object for any number of additional methods in response to user interaction with the ribbon and any programmatic ribbon control state changes. For example, in your ribbon XML, you would specify that the callback method for a button might be MyButtonCallbackMethod – and this method is clearly not defined in the IRibbonExtensibility interface. In other words, while IRibbonExtensibility is basically a COM interface, it is most emphatically an automation interface. That is, you’re allowed to define any number of additional methods on the end of the interface, and Office will call back on these methods using IDispatch::GetIDsOfNames and IDispatch::Invoke. So why is an automation interface a problem for the shim?

Recall that there are two standard ways to build a shim: containment and aggregation.

With containment, the shim acts like an outer component, and contains pointers to interfaces on the inner component (the add-in, smart tag, etc). The shim re-implements the same interfaces as the add-in, and when Office calls into the interface on the shim, the shim then passes the call on to the add-in’s implementation of the same interface. With this approach, the shim can specialize the interface with prolog and epilog code wrapping the call to the add-in. This is how the shim is currently written: it uses containment for the interface on the add-in. We do this because we want to provide behavior that is additional to the add-in’s implementation of the interface – notably to create and destroy appdomains as part of the startup (IDTExtensibility2::OnConnection) and shutdown (IDTExtensibility2::OnDisconnection) sequences. The same model holds true for smart tags and RTD components (although with different interfaces, of course).

We could extend the shim’s containment model to cover ICustomTaskPaneConsumer and FormRegionStartup. Unfortunately, we can’t extend it to cover IRibbonExtensibility, because Office relies on the additional methods in the ribbon object that are not defined in the IRibbonExtensibility interface. If we don’t know what these additional methods are, we can’t provide a containment for them.

Aggregation is a specialization of composition. When an outer component aggregates an interface of an inner component, it doesn't reimplement the interface - it merely passes the inner component's interface pointer directly to the caller. With this model, the outer component can't specialize the behavior of the inner component. The critical problem with aggregation is that you’re handing out an interface pointer to the inner object back out to the caller (Office in this case). Because of this, you must be very careful to construct the inner object so that it is aware that it is being aggregated. Why? Because of the COM rules of identity, and specifically QueryInterface transitivity.

A COM component can implement any number of interfaces, and a caller must be able to switch between these interfaces, and back again. The COM rules state that “the QueryInterface method takes an interface ID and returns the requested COM interface on the same object. The set of interface IDs accessible via QueryInterface is the same from every interface on the object.” That is, whatever COM interface pointer a caller has on an object, it should be able to switch to any other interface on that object, and back again. This is a problem in aggregation, because here the caller starts off with a pointer to the outer object’s interfaces, and later gets handed a pointer to the inner object’s interfaces. Now, the outer object is aware that it is aggregating an inner object, so it can always deal with QIs for inner object interfaces correctly. However, we can’t have the caller QI on an inner object interface directly, because the inner object doesn’t have any knowledge of the outer object’s interfaces.

So, how does aggregation work? The solution is for the inner object to delegate IUnknown calls in its own interfaces, but also allow the outer object to access the inner object's IUnknown functions directly. All in all, aggregation is reasonably well-understood, and it works. The critical issue is that the inner object needs to know that it is being aggregated, so that it can take the correct action when QI calls come in. This is simple enough if you’re building your inner object with ATL – by default, ATL objects are aggregatable as inner objects. It’s not so simple if you’re building your inner object with managed code. It's even more difficult if your inner object is managed and your outer object is unmanaged.

There is an additional problem in the shim/add-in scenario, because typically, you build an add-in and then use the COM shim wizards to generate a shim. While we can write wizards that generate shims, the wizard can’t interfere with the code in the add-in itself - you might not even have the sourcecode of the add-in. So, there’s no easy way for us to make the add-in behave correctly as an inner object in an aggregation.

So, where do we go from here?

One option that we considered was to extend the existing shim containment model to allow the shim to reflect over the add-in to discover what additional methods are exposed from the object that implements IRibbonExtensibility, and then shim those methods also. But that’s a lot of work at runtime, and potentially error-prone. We would have to assume that any public method on the object is a potential ribbon callback, and that’s a wild assumption. Or, we’d have to mandate that the add-in developer adds some [RibbonCallback] attribute to each of the methods they want to expose. But, the existing shim doesn’t make any such assumptions about the add-in, and we don’t want to touch the add-in code at all. So, this is not a viable option.

Another option that we considered early on was to override the InternalQueryInterface method on the shim (which, you may recall is implemented with ATL). The thinking here was that for any new extensibility interface QI'd by the calling host, we would delegate to the add-in itself:

HRESULT WINAPI CConnectProxy::InternalQueryInterface(

void* pThis, const _ATL_INTMAP_ENTRY* pEntries, REFIID iid, void** ppvObject)

{

if (m_pConnect &&

(iid == IID_ICustomTaskPaneConsumer

|| iid == IID_FormRegionStartup

|| iid == IID_IRibbonExtensibility

|| iid == IID_IBlogExtensibility

|| iid == IID_IBlogPictureExtensibility

|| iid == IID_IDocumentInspector

|| iid == IID_SignatureProvider

|| iid == IID_EncryptionProvider ))

{

HRESULT hr = m_pConnect->QueryInterface(iid, ppvObject);

if (hr == S_OK)

return hr;

}

return CComObjectRootBase::InternalQueryInterface(

pThis, pEntries, iid, ppvObject);

}

This could be simplified further, so that we QI on the inner object for any interface apart from the ones we want the shim itself to handle:

HRESULT WINAPI CConnectProxy::InternalQueryInterface(

void* pThis, const _ATL_INTMAP_ENTRY* pEntries, REFIID iid, void** ppvObject)

{

if (m_pConnect

&& iid != IID__IDTExtensibility2

&& iid != IID_IUnknown

&& iid != IID_IDispatch)

{

HRESULT hr = m_pConnect->QueryInterface(iid, ppvObject);

if (hr == S_OK)

return hr;

}

return CComObjectRootBase::InternalQueryInterface(

pThis, pEntries, iid, ppvObject);

}

BUT: this breaks COM identity rules, because in this approach we’re handing out a pointer to one of the new interfaces, which may be implemented in a separate object from the add-in. So, if Office were ever to QI again on that pointer, they would not get a QI closure to all the interfaces supported by the add-in. In other words, this code would implement a kind of partial or fake aggregation, without the most crucial feature of real aggregation.

It’s seductive to think that the following would work (recall that the COM map in an ATL project expands out to the QueryInterface implementation):

BEGIN_COM_MAP(CConnectProxy)

COM_INTERFACE_ENTRY(IDTExtensibility2)

COM_INTERFACE_ENTRY2(IDispatch, IDTExtensibility2)

COM_INTERFACE_ENTRY_AGGREGATE(IID_ICustomTaskPaneConsumer , m_pConnect)

COM_INTERFACE_ENTRY_AGGREGATE(IID_FormRegionStartup, m_pConnect)

COM_INTERFACE_ENTRY_AGGREGATE(IID_IRibbonExtensibility, m_pConnect)

COM_INTERFACE_ENTRY_AGGREGATE(IID_IBlogExtensibility, m_pConnect)

COM_INTERFACE_ENTRY_AGGREGATE(IID_IBlogPictureExtensibility, m_pConnect)

COM_INTERFACE_ENTRY_AGGREGATE(IID_IDocumentInspector, m_pConnect)

COM_INTERFACE_ENTRY_AGGREGATE(IID_SignatureProvider, m_pConnect)

COM_INTERFACE_ENTRY_AGGREGATE(IID_EncryptionProvider , m_pConnect)

END_COM_MAP()

…which could be simplified to:

BEGIN_COM_MAP(CConnectProxy)

COM_INTERFACE_ENTRY(IDTExtensibility2)

COM_INTERFACE_ENTRY2(IDispatch, IDTExtensibility2)

COM_INTERFACE_ENTRY_AGGREGATE_BLIND(m_pConnect)

END_COM_MAP()

In other words, fix up the COM map of the shim so that all calls to non-IDTExtensibility2 interface functions get passed on to the add-in. In fact, this probably would work, right now at least. However, if you think about it, this is really no different from the InternalQI override above – we’re still breaking the QI transitivity rule. We’re asserting that we aggregate the add-in as the inner object, when in fact we don’t aggregate it at all. The add-in object (or, realistically, the multiple add-in objects that implement each of the extensibility interfaces) are crucially unaware that we’re presenting them as being aggregated.

So, why do I say it would work for now? It seems that right now, Office gets the first interface pointer on the object (the IUnknown of the object that implements IDTExtensibility2), and then always uses that pointer to QI for any subsequent interfaces. Right now, it doesn't QI on any of the subsequent interfaces. In other words, the potential QI transitivity breach of these two approaches is not in fact being hit – but there’s no guarantee that this would always be the behavior, and both approaches are technically still wrong, so it’s obviously an unacceptable risk.

The correct solution is to either (a) truly aggregate the add-in and all its inner objects, or (b) extend the existing shim containment model to cover all 7 of the new interfaces also. Which brings us back to IRibbonExtensibility. We could cover all the other new interfaces with containment, but we can’t cover ribbon customization with containment. And, how do we achieve aggregation without interfering with the add-in code?

For the skinny on this, see next week’s exciting adventure of The COM Shim Wizard!!!

COM Shim Wizards v2

andreww — Sat, 10 Jun 2006 04:10:00 GMT

Today we release v2 of the COM Shim Wizards. These are updated versions of the wizards we released in 2004 for Visual Studio 2003. The new wizards work with Visual Studio 2005.

There's a covering article here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_vsto2005_ta/html/Office2003ShimWizard2.asp

You can download the wizards here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=300A6CDB-84DD-4C62-B3BD-E79194D83494&displaylang=en

These wizards allow you to build unmanaged shims for managed Office extensions, including shared add-ins, smart tags and realtime data servers. The wizards will ask you a few simple questions and then generate all the code for the shim, so that you only have to build the shim - you don't have to write any code.

The reasons why you should use a shim for managed Office add-ins and other extensions are detailed in the article, but essentially they increase robustness by isolating each extension in a separate appdomain. Of course, this functionality is one of the main advantages of using VSTO add-ins over shared add-ins, and is built into the VSTO runtime. Unfortunately, VSTO 2005 provided add-in support only for Outlook 2003. So if you're targeting any other Office 2003 application, or any earlier version of Office, you had no choice but to use shared add-ins.

The v2 wizards are basically the same as the v1 wizards, although we did take the opportunity to fix a bug and streamline the UI. The only significant difference is that the v2 shims support unloading of the target assemblies.

Until VSTO add-ins provide support for a wider range of Office applications (which it will in the upcoming releases), you are encouraged to provide shims for your add-ins, and these wizards do cover off this requirement quite nicely.