Hosting UserControl via ActiveX does not work correctly

• .NET Core Version: 5.0

• Have you experienced this same bug with .NET Framework?: No

Problem description: I am experimenting with doing Office Addins without VSTO and using .NET 5. So far, I have succesfully manged to add ribbon buttons and I’m now working on a custom TaskPane, hosting a Winforms UserControl.

So far, so good. However, when instantiating the UserControl, an exception is thrown here: https://github.com/dotnet/winforms/blob/cb03d37fe73fb178d3c3827ad895bb3e7c50fe4c/src/System.Windows.Forms/src/System/Windows/Forms/Control.ActiveXImpl.cs#L841

_inPlaceUiWindow is null here and there is no check for that case.

Comparing to .NET Framework 4.8 reference source (https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Control.cs,17065), the implementation is different and I suspect that a regression has snuck in.

Expected behavior: No NullReferenceException should be thrown.

Minimal repro: You can download the project here: https://1drv.ms/u/s!AkwgkpetCvCpr4JeJeZfCGlKlHs4qA?e=PeB0So You need to manually run regsvr32 OutlookAddinNet5.comhost.dll in the bin folder and register the addin in outlook:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\Addins\OutlookAddinNet5]
"CommandLineSafe"=dword:00000001
"Description"="OutlookAddinNet5 description"
"FirendlyName"="OutlookAddinNet5 name"
"LoadBehavior"=dword:00000003

Then Open Outlook and click the [2] button added to the ribbon.

[weltkante]

Can you register/unregister the comhost.dll with Core 6? I had also issues here.

@1R053 I’ve successfully done that while debugging the above, but I had to install the 32 bit SDK for some reason to get the addin registering in a 32 bit office installation (just building 32 bit worked via 64 bit SDK, but registering did not; I did have both 32 bit and 64 bit runtimes installed) - I wonder if these addins even register via regsvr32 on machines where the SDK is not installed in the first place?

If regsvr32 is broken without an SDK installed matching the bitness of the DLL then it probably needs to be reported on the dotnet runtime repo.

Also note that AnyCPU builds probably won’t work for COM libraries, since the comhost.dll is likely to be a native DLL so you need to build twice for specific bitness to get both variations of the comhost.dll if you want to support both 32 bit and 64 bit office. For Desktop Framework this was not necessary because mscoree.dll, the equivalent of the comhost.dll, was built into the framework and available in both bitness variations out of the box.

[weltkante]

Personally I’d suggest to move “implementing ActiveX controls in WinForms and hosting them in external environments” into “unsupported” territory

• doing it properly requires generating a type library (TLB) which is no longer supported by the dotnet ecosystem. You can get it to work by using the Desktop Framework to compile against a similarly shaped API and generate the TLB, then use that TLB with your .NET Core code (is that the current terminology?) But this is already doing things on your own, the tooling itself doesn’t support it.
• in the Office scenario vital undocumented infrastructure was removed/lost in the migration process and there is no intention to restore it (as mentioned in other issues), so hosting user controls in Office this way will not be supported by your roadmap regardless of what you do with ActiveX controls
• the non-desktop dotnet runtime doesn’t support side-by-side hosting, making COM a bad API/ABI to base new controls on, as multiple different such controls cannot coexist inside the same process

PS: the reverse scenario, hosting external ActiveX controls inside a WinForms control or form, is supportable.

also if there are bugs reproed/identified they can still of course be fixed, but the overall scenario itself cannot be supported given the current capabilities of dotnet, its always going to be a hack job for the one using this capability