-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Open
Labels
area-HostenhancementProduct code improvement that does NOT require public API changes/additionsProduct code improvement that does NOT require public API changes/additions
Milestone
Description
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.
jozefizso, mterhorst, ThargoN, suhrab, ChristophHornung and 8 more
Metadata
Metadata
Assignees
Labels
area-HostenhancementProduct code improvement that does NOT require public API changes/additionsProduct code improvement that does NOT require public API changes/additions
Type
Projects
Status
No status