Add note about Any CPU usage #22531
Add note about Any CPU usage #22531
Conversation
tdykstra
requested review from
jkoritzinsky and
luisquintanilla
and removed request for
a team
|
@AaronRobinsonMSFT in the AnyCPU case will the com host always be 64-bit or will it match the bitness of the SDK running the build? |
it is an SDK setting. The confusion is warranted as the behavior is unfortunate and unexpected. The suggested documentation is very misleading and not appropriate. Let me provide some nuance in review. |
|
|
||
| Unlike in .NET Framework, there is no support in .NET Core for generating a COM Type Library (TLB) from a .NET Core assembly. The guidance is to either manually write an IDL file or a C/C++ header for the native declarations of the COM interfaces. | ||
|
|
||
| In .NET Framework, an "Any CPU" assembly can be consumed by both 32-bit and 64-bit clients. In .NET Core, .NET 5, and later versions, "Any CPU" assemblies are accompanied by 64-bit *.comhost.dll*, so they can only be consumed by 64-bit clients. |
There was a problem hiding this comment.
In .NET Core, .NET 5, and later versions, "Any CPU" assemblies are accompanied by 64-bit .comhost.dll, so they can only be consumed by 64-bit clients.
Right, that is the default because that is what the SDK represents. This is identical in behavior to how one would publish a "self-contained" feature, by default it uses what the SDK provides. The NETCoreSdkRuntimeIdentifier MSBuild property is key here. That property determines the bitness of *.comhost.dll. The managed part is actually bitness agnostic as expected, but the accompanying native asset defaults to the SDK.
I think that is the nuance needed here.
Co-authored-by: David Pine <[email protected]>
|
Thanks for the review, @IEvangelist ! |
Co-authored-by: Aaron Robinson <[email protected]>
Fixes #21173