Shimming Managed Automation Add-ins
Since blogging about the COM shim wizards, I've had a few emails asking whether the shim can be applied to managed automation add-ins. Before we consider shims, some context is in order. Automation add-ins were introduced for Excel starting with Excel 2002 (XP) - the point of automation add-ins is to allow you to develop custom functions which can be called directly from cells in Excel worksheets.
An Excel automation add-in can also be an Office COM add-in, but it doesn’t have to be. In a broader sense, all automation components are by definition COM components, and certainly Excel automation add-ins are built on COM. Managed automation add-ins talk with Excel through COM interop. So, the distinction between the terms "automation add-in" and "COM add-in" is a semantic one. It comes down to two things: how the add-in is loaded by Excel; and which interface is used between Excel and the add-in.
Office COM add-ins must be in-process COM servers that support the IDTExtensibility2 interface; however, automation add-ins can be in-process or out-of-process COM servers and implementation of IDTExtensibility2 is optional. Typically, automation add-ins will expose a custom automation interface, and not IDTExtensibility2. If you expose a custom automation interface and also IDTExtensibility2, then your add-in can be loaded as either (or both) a COM add-in and/or an automation add-in. Designing such a dual-purpose add-in would rarely make sense. Typically, a COM add-in will enhance the host application's UI by building custom commandbars etc, and will provide other more complex functionality (also possibly UI related). Typically, an automation add-in will purely supply additional cell functions and will not mess with the UI. There may be all sorts of complex functionality behind the functions, but the only things that get surfaced are the cell functions themselves.
Recall that when you build a COM add-in, you specify in the registry how the add-in should be loaded, using the LoadBehavior value. This value governs how and when a COM add-in is loaded. If you use this value for an automation add-in, it will be loaded as a COM add-in, and Excel will talk to it via IDTExtensibility2 (if your automation add-in implements IDTExtensibility2). If you register the add-in under HKCU (as opposed to HKLM), then it will also appear in the COM Add-ins dialog, allowing the user the load/unload and potentially unregister the add-in.
If you want to use your automation add-in as an automation add-in, you need to load it via the Automation Add-ins dialog. For it to appear in this dialog, you need to add a couple of additional registry entries. Specifically, you need to create an additional subkey of HKCR\CLSID, with the GUID of your add-in's primary class, delimited with braces. As a child of this GUID key, you need to create a final key named Programmable. This needs no value.
Office applications use the \Software\Microsoft\Office\<Host Application>\Addins subkey of either HKCU or HKLM to find the list of add-ins to load. An automation add-in doesn't need this registry information at all – that is, unless you want it to be loaded both as an automation add-in and as a COM add-in. So your three options are: load as an automation add-in only; load as a COM add-in only; load as both an automation add-in and a COM add-in. If you set it to load as both, you'll get two independent copies loaded and used in the two different ways – which probably isn't going to be useful, and may even cause conflicts.
For an automation add-in, you also need to build and register a type library (a step that's not required for COM add-ins). One easy way to get this is to attribute your primary class with the ClassInterface attribute, specifying AutoDual as the type. Using AutoDual class interfaces is normally discouraged because such interfaces allow clients to bind to a specific interface layout that might change as the class evolves, thereby breaking the client. Instead of using class interfaces, you should normally define a custom interface explicitly. However, one of the crucial things that using an AutoDual classinterface does give us is that type information is produced for the interface and published in a type library, and the type library is registered.
Coming back to shims, the current implementation of the COM shim for managed Office extensions supports COM addins, Smart Tag recognizers, Smart Tag actions, combined Smart Tag recognizer+action DLLs, and Excel RealTime Data servers. These are all precisely-defined protocols, and the wizard understands all the relevant interfaces – that is, IDTExtensibility2, ISmartTagAction, ISmartTagRecognizer, and IRtdServer. The problem with automation add-ins is that they expose custom automation interfaces – that is, interfaces which the wizard cannot possibly have prior knowledge of.
Does that mean you cannot provide a COM shim for a managed automation add-in? Of course, the answer's "No". You can shim a managed automation add-in. You can certainly do this manually. The COM shim model is also basically OK to use with automation add-ins. The only difference is that instead of exposing the IDTExtensibility2/ISmartTagAction/etc interface and providing a wrapper function in the shim for the IDTExtensibility2/ISmartTagAction/etc methods, you expose and provide a wrapper function for the methods of your custom automation interface. You can take a standard COM shim, and modify it to wrap your custom methods. The basic plumbing of the shim – and the key benefits of AppDomain isolation and security support – still hold good.
Automating the shimming of a custom interface is a little more interesting. I have branched off a version of the shim wizard which does its initial assembly reflection, and then goes on to load the registered typelib for the automation add-in to generate C++ wrapper methods in the shim for the custom interface. I'm still testing this, and also considering alternative designs. In the meantime, don't let the lack of an easy shim process deter you from developing managed automation add-ins, nor from shimming those add-ins. For both COM add-ins and automation add-ins, a shim is a good thing.