Any sense in marking an IUnknown-derived interface as dual in IDL?

问题

Reviewing our code I've found a curious definition in one of .idl files:

[
    object,
    uuid(uuidhere),
    dual,
    nonextensible,
    oleautomation,
    hidden
]
interface IOurInterface : IUnknown {
    //methods here
};

How can an interface derived directly from IUnknown possibly be a dual interface? Will anything break if I remove the dual attribute?

回答1:

In this answer to another question concerning marshaling user voyce points to this article that basically states the following:

When any interface (IDispatch-derived or not) is marked either dual or oleautomation (or both) it is treated specially when RegisterTypeLib() is invoked (which is typically done by DllRegisterServer). For each such interface an HKCR\Interface{InterfaceId} key is created under which {00020424-0000-0000-C0000-000000000046} class is referenced as proxy/stub. This class id corresponds to typelib marshaller also known as oleautomation marshaller.

回答2:

I can't see a reason that that would work, given the docs here: http://msdn.microsoft.com/en-us/library/aa366807(VS.85).aspx

Interfaces identified by the dual attribute must be compatible with Automation and be derived from IDispatch. This attribute is not allowed on dispinterfaces.

It could be that the [dual] attribute implicitly adds IDispatch to the interface.

What you could do is check the code implementing the interface (assuming this is ATL) if it derives from IDispatchImpl. If so, it actually responds to QI for IDispatch and might be used as such.

Another alternative is to instantiate an object implementing IOurInterface and QI it for IDispatch -- if it succeeds, you probably can't remove it.

Actually, come to think of it, maybe [dual] doesn't technically require that you derive from IDispatch as long as you implement both your custom interface and IDispatch?

来源：https://stackoverflow.com/questions/1636148/any-sense-in-marking-an-iunknown-derived-interface-as-dual-in-idl