COM Server using WindowsDesktop will not register

[adamlonsdale]

I have a .NET Core 3.0 Preview 7 WinForms application created in Visual Studio 2019 16.3 Preview 1.

The .csproj was modified to include the <EnableComHosting>True</EnableComHosting> attribute and some targets to output the ComHostFileName to the output.

I have added a class with the ComVisible Attribute set to True and a newly generated Guid specified in the Guid Attribute.

When I build I get the files I need (including the .comhost.dll) in the bin directory.

I have installed the corresponding 32-bit .NET Core 3.0 Preview 7 runtime on a Windows 7 SP1 machine and copied the files over. Running regsvr32.exe on the comhost DLL gives me the below error message.

The module "C:\Users\Adam.Lonsdale\Desktop\netcorewinforms\WinFormsCore.comhost.dll" failed to load.

Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.

The specified module could not be found.

I believe this could be a problem with the WindowsDesktop Project SDK. It also fails to register on a Windows 10 machine that the project was built on, with the full Preview 7 SDK installed.

[adamlonsdale]

Just an update here, I didn't have the relevant prerequisites on the windows 7 box, so have installed the windows updates and now a Microsoft.NET.Sdk project will build and register, however a Microsoft.NET.Sdk.WindowsDesktop project will not.

The module "C:\Users\Adam.Lonsdale\Desktop\netcorewinforms\WinFormsCore.comhost.dll" was loaded but the call to DllRegisterServer failed with error code 0x80008096.

[hoyosjs]

@AaronRobinsonMSFT

[AaronRobinsonMSFT]

This looks like an issue with the installed framework (i.e. 0x80008096: FrameworkMissingFailure)

See: https://github.com/dotnet/core-setup/blob/6db018b7fc5c104810f5a53b538841004e099713/src/corehost/cli/fxr/fx_resolver.cpp#L434-L439

Can you share the *.runtimeconfig.json file?

[adamlonsdale]

Interesting, I installed all prerequisites for 3.0 Preview 7. I presume there is no separate runtime for Windows Desktop?

*.runtimeconfig.json is as below.

{ "runtimeOptions": { "tfm": "netcoreapp3.0", "rollForward": "LatestMinor", "framework": { "name": "Microsoft.WindowsDesktop.App", "version": "3.0.0-preview7-27912-14" } } }

Output of dotnet --info

It was not possible to find any installed dotnet SDKs
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
https://aka.ms/dotnet-download

Host (useful for support):
Version: 3.0.0-preview7-27912-14
Commit: 4da6ee6450

.NET Core SDKs installed:
No SDKs were found.

.NET Core runtimes installed:
Microsoft.NETCore.App 3.0.0-preview7-27912-14 [C:\Program Files\dotnet\shared
Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

[AaronRobinsonMSFT]

.NET Core runtimes installed:
Microsoft.NETCore.App 3.0.0-preview7-27912-14 [C:\Program Files\dotnet\shared
Microsoft.NETCore.App]

That is indeed the issue right there. The Microsoft.WindowsDesktop.App is missing. I am unsure why this would be missing. Can you point me to the installer used? If this was done via VS, then this could be an issue with the specific workloads installed.

@richlander or @livarcocc Do either of you happen to know who we could talk about installing the WindowsDesktop.App support on Windows 7? Is this scenario blocked for some reason?

[AaronRobinsonMSFT]

@adamlonsdale Are you able to build and run any dotnet core WPF application on the Windows 7 machine?

[elinor-fung]

One thing to note is that the WindowsDesktop runtime doesn't (yet) have a standalone bundle installer. It is only included as part of the full SDK right now (see dotnet/core-setup#6384), so if you only installed the runtime bundle, the WindowsDesktop runtime will not be installed.

[adamlonsdale]

@elinor-fung is correct, I had not installed the SDK, as soon as that was installed the .comhost.dll registers fine.

Follow up question though - I'm trying to write an article on VB6 <-> .NET Core interop whilst we are converting the last of our software to .NET and I noticed the registry entries created when registering the comhost DLL are very different from a netfx DLL registered via regasm.

If I register a netfx DLL I can see it in VB6 and I get a ProgID in the registry to use, if I register my .NET Core library I just get an InProcServer32 key and it doesn't appear in the references list and cannot be used by Late Binding.

To be clear - this is in-process COM. I can follow up with a new issue if needed.

[AaronRobinsonMSFT]

@adamlonsdale I would file a new bug for the ProgID issue. Thanks.