为什么接口IMsoErrorBars没有注册为COM接口？

Question

When using the ErrorBars property in Microsoft.Office.Core.IMsoSeries using COM automation, I get a COM exception "Interface not registered" while it works fine using the property within an add-in.

I noticed that the interface IMsoErrorBars is not registered in Windows Registry like all other Office API interfaces are (or at least the ones if have been using so far). I checked several machines with Office 2010 or 2013 installed and they all missed the IID {000C1721-0000-0000-C000-000000000046} in HKEY_CLASSES_ROOT\\Interface .

Does anybody know why it's missing?

UDPATE

Here's as example in C# ...

IEnumerable<int> ErrorBarsColors(Microsoft.Office.Interop.PowerPoint.Shape shape)
{
    var seriesCollection = shape.Chart.SeriesCollection() as IEnumerable;

    foreach (Microsoft.Office.Core.IMsoSeries series in seriesCollection)
    {
        if (series.HasErrorBars)
        {
            var errorBars = series.ErrorBars;
            yield return errorBars.Format.Line.ForeColor.RGB;
        }
    }
}

... that fails with the mentioned COM exception at the series.ErrorBars access when it's called in a stand-alone application using some code like this:

var application = new Microsoft.Office.Interop.PowerPoint.Application();
var presentation = application.Presentations.Open(SOME_PRESENTATION);
var shape = presentation.Slides[1].Shapes[1];
var colors = ErrorBarsColors(shape);

But the same code works perfectly when using it in a PowerPoint Add-In.

Meanwhile I found some other interfaces that neither are registered and show the same behavior.

Answer 1

The fact that the interfaces are not registered makes them unable to work for calls across apartments (the COM objects could use custom marshaling, but in this case, it seems they don't). It works when you use it as an add-in because it's running in the same apartment (at least, that's my wild guess).

You may want to register the interfaces yourself in HKCR\\Interface\\{IID} with key ProxyStubClsid32 having a default value of {00020424-0000-0000-C000-000000000046} (the universal marshaler that looks up for the interface definition in a typelib) and the key TypeLib having a default value of {2DF8D04C-5BFA-101B-BDE5-00AA0044DE52} and a Version value with the installed Office typelib version, such as 2.3 for 2003, 2.4 for 2007, 2.5 for 2010, 2.6 and 2.7 for Office 2013 (look for point 8). It shouldn't matter which, the interface should remain the same between versions.

But that doesn't make it right, the underlying operations may require some sort of same-apartment, hence in-process, data access. With a separate process, you may be violating both assumptions. It's better to contact Microsoft and ask if this is a bug or an unintended omission. Or just try it out, with the risk of falling prey to the "it works on my machine" phenomenon.

The sure way around is to have the Office application create an object to which you can dispatch calls to the ErrorBars property given a Series object. Maybe have an add-in for it, since you've already tried and it worked.

Answer 2

Not all COM interfaces are registered. Only COM interfaces that can be directly created via CoCreateInstance have to be registered. If the COM interface is obtained from some other method (in this case, from the ErrorBars property), it does not have to be registered.

Answer 3

There is no mandatory registration for COM interfaces. Those mentioned in registry under HKEY_CLASSES_ROOT\\Interface\\{CLSID} are typically interfaces that either require/use custom proxy/stub handlers, or registered along with registration of type library which contains them.