Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support dual comhost.dll (x86, x64) generation for .NET Core assemblies using "Any CPU" #32493

Open
carlos-quintero opened this issue Feb 18, 2020 · 3 comments
Labels
area-Host enhancement Product code improvement that does NOT require public API changes/additions
Milestone

Comments

@carlos-quintero
Copy link

Currently:

  • If the .NET Core assembly uses architecture "x86" the generated .comhost.dll is for 32-bit.
  • If the .NET Core assembly uses architecture "x64" the generated .comhost.dll is for 64-bit
    So far so good.
  • If the .NET Core assembly uses architecture "Any CPU" the generated .comhost.dll is for 64-bit. This case is problematic. If you try to register it as 32-bit COM component, the client gets 0x800700C1 ("not a valid Win32 application").

If an assembly targets the architecture Any CPU then two .comhost.dll files
should be generated, because the autor may want to create both x64 and x86 COM servers from the same .NET "Any CPU" assembly (ex: consider a .NET-based add-in for Office 64-bit and Office 32-bit). That was possible with .NET Framework with a single build, but it is not possible with .NET Core: two builds are required, one for architecture x86 and another for architecture x64, and you need to move the output files before the second build.

I suggest the following approach:

  • If the .NET Core assembly uses architecture x86 a .comhost32.dll file is generated for 32-bit
  • If the .NET Core assembly uses architecture x64 a .comhost64.dll file is generated for 64-bit
  • If the .NET Core assembly uses architecture Any CPU, both .comhost32.dll and .comhost64.dll files are generated.
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-Meta untriaged New issue has not been triaged by the area owner labels Feb 18, 2020
@vitek-karas
Copy link
Member

/cc @AaronRobinsonMSFT

@jeffschwMSFT jeffschwMSFT added enhancement Product code improvement that does NOT require public API changes/additions and removed untriaged New issue has not been triaged by the area owner labels Apr 3, 2020
@jeffschwMSFT jeffschwMSFT added this to the Future milestone Apr 3, 2020
@DHowett
Copy link

DHowett commented Dec 1, 2020

This is also important for ARM64 for projects that want 3-architecture builds, like WinAppDriver.

@jozefizso
Copy link

I created new issue at dotnet/sdk#37570 as the build scripts for COM hosting are in the SDK repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Host enhancement Product code improvement that does NOT require public API changes/additions
Projects
Status: No status
Development

No branches or pull requests

6 participants