search

microsoft / CsWinRT

C# language projection for the Windows Runtime
MIT License
538 stars 102 forks source link

manifest-free activation difficult for C# WinRT components #1281

Open tecnoprogram-thomas opened 1 year ago

tecnoprogram-thomas commented 1 year ago

I created a C# WinRT component (say CustomClassLibrary.dll) and I want to activate it with manifest-free activation from cppwinrt.

The problem is that C# component don't have the DllGetActivationFactory inside the assembly DLL, so the winrt manifest-free activator tryes to load the dll but fails in finding the GetProcAddress of DllGetActivationFactory . The DllGetActivationFactory in C# is actually implemented/exported by the WinRT.Host.dll, which the user can eventually rename to something like CustomClassLibrary.Host.dll I suggest that the cppwinrt activator could try to load an additional DLL with a conventional suffix (.Host.dll ?) to support this scenario, or if not fixed to give an option to customize the actually loaded DLL name.

The workaround at the moment is to implement the winrt_activation_handler detour and custom implement the library loading.

kennykerr commented 1 year ago

One of the central tenets of COM, and WinRT, is that the caller need not know anything about the implementation of the callee. If C#/WinRT wants to support this form of activation it should follow the convention so that it just works. I'm sure they could do that if it were desirable. C++/WinRT also directly provides and supports enough activation options that I'm reluctant to mess with it any further.

tecnoprogram-thomas commented 1 year ago

I can understand your point, probably the C#/C++ interop scenario was implemented having manifests in mind, as an official tutorial indicates here: https://learn.microsoft.com/en-us/windows/apps/develop/platform/csharp-winrt/create-windows-runtime-component-cswinrt (see the c++ manifest section). I also understand that when using manifests there are things not possible without them (like declaring a different DLL name), so I guess the "detouring" is the only way to go.

Do you think I should post this problem on CSWinRT side?

kennykerr commented 1 year ago

I can transfer the issue for their consideration. Thanks for the feedback!

BenJKuhn commented 1 year ago

This isn't supported today because the C++ /WinRT projection can't find the DllGetActivationFactory method in the managed assembly. A bootstrapper of some sort is required. There are a few ways we might approach this, but the feature team needs to discuss further.