You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
Currently:
So far so good.
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:
The text was updated successfully, but these errors were encountered: