Use CppWinRTClassFactory to implement DllGetClassObject?

[forderud]

I've just started modernizing some existing ATL projects to WinRT. One challenge then faced has been how to implement DllGetClassObject in a DLL-based COM server. ATL already includes boilerplate code for this, but similar functionality seem to be missing from C++/WinRT and WIL.

There's documentation on how to implement DllGetClassObject with a custom class factory on Author COM components with C++/WinRT. This works fine, but require developers to add their own class factory implementation, which leads to boilerplate.

To reduce boilerplate, I've started using the WIL CppWinRTClassFactory class to simplify the DllGetClassObject implementation, and then end up with code like this:

STDAPI DllGetClassObject(::GUID const& clsid, ::GUID const& iid, void** result) {
    *result = nullptr;

    if (clsid == __uuidof(MyServer)) {
        return winrt::make<wil::details::CppWinRTClassFactory<MyServer>>().as(iid, result);
    }

    return CLASS_E_CLASSNOTAVAILABLE;
}

This works fine, but introduces a dependency to a wil::details class, and I'm unsure if this is recommended.

REQUEST: There's already a wil::register_com_server function in this repo to ease implementation of EXE-based COM servers. It would therefore be great if something similar could exist for DLL-based COM servers. One solution could then be to endorse direct CppWinRTClassFactory usage, or provide a more complete DllGetClassObject implementation.

[sylveon]

Note that CppWinRTClassFactory::LockServer doesn't modify the module lock, and CppWinRTClassFactory is also flagged with winrt::no_module_lock. If you ask me, that probably should've been done.

I agree a public version is desirable (I have my own helper predating this, which I believed @roxk ultimately derived from), but if that where done should increase the module lock for sure.

I'm not sure we can help much DllGetClassObject without code generation, which isn't a thing we can do yet, or ugly macros, which I think maintainers would prefer avoiding.

FWIW, com_ptr has as() so you don't need to directly call QueryInterface, and you can also just directly return CLASS_E_CLASSNOTAVAILABLE, no need to construct a full hresult_class_not_available

[forderud]

I'm not sure we can help much DllGetClassObject without code generation, which isn't a thing we can do yet, or ugly macros, which I think maintainers would prefer avoiding.

I see several potential solutions to this request:

1. The simplest would be to "endorse" direct CppWinRTClassFactory usage in client code by moving it to the wil parent namespace.
2. Or, introduce some kind of new wil::get_class_object<T...>(GUID const& clsid, GUID const& iid, void** result) function that takes the COM classes as template argument(s). This would follow the same pattern as the existing wil::register_com_server<T...>() function, but for DLL-based COM servers.

I don't think any of the above alternatives would require any code generators or macros.

FWIW, com_ptr has as() so you don't need to directly call QueryInterface, and you can also just directly return CLASS_E_CLASSNOTAVAILABLE, no need to construct a full hresult_class_not_available

Thanks for the tip @sylveon! I've now updated the issue description at the top of the page to instead use .as() and CLASS_E_CLASSNOTAVAILABLE as suggested.