Bug: cswinrt uses wrong architecture runtime dll and will cause a runtime exception

[hoshiizumiya]

Description

This issue is related to the following ones. I recommend you must have a check on these. Please review them, as I don’t want to repeat the details here: #1522 #1097 #1874 I believe the cswinrt nuget package used in the project has an architecture mismatch issue. Whether I manually assigned x64 or anyCPU(I'm not entirely sure what's the anyCPU's actually meaning, and it also doesn't work either), running the solution will cause '%1 is not a valid Win32 application.' hresult error. Only when all build configurations are set to x86 does the solution run successfully. Please review all the related issues and make sure you’ve readgithub link for more details! Some related CsWinRT DLLs appear to have been built for the wrong architecture. I have checked some dlls using Visual Studio dumpbin tools and the results are as follows. There are also some others dlls you can check by yourself. I'm not sure if this is the root cause of the x64 issue, but if CsWinRT uses runtime DLLs built for the wrong architecture, it could trigger a runtime exception.

And I don't know why the project is automatically linked with .net6.0 but my project is .net10 and it has a .net8.0 in the same folder. maybe you should update the .net dependence version for nuget? I'm not sure it's good or not.

And I always occure this error, maybe it's vs bug

Steps To Reproduce

All CsWinRT projects must assigne as x86 architecture will run without error. So the arm and x64 solution can't use

I create two projects. And my goal is to use C# compoent by cswinrt for WinUI3 cppwinRT, so I create a WinUI class library And I made a small example that you can easily verify as what I said before, please check https://github.com/hoshiizumiya/WinUI3-CppWinRT-CsRuntimeComponent-Sample.git

Expected Behavior

Each architecture build option should run property, specific anyCPU effect.

Version Info

CsWinRT 2.2.0 VS 2026 11121.172

Additional Context

And I mostly referred these guides

https://learn.microsoft.com/en-us/windows/apps/develop/platform/csharp-winrt/create-winrt-component-winui-cswinrt#reference-the-component-from-a-windows-app-sdk-cwinrt-app https://github.com/microsoft/CsWinRT/blob/master/docs/authoring.md#consuming-from-c-applications-1

[hoshiizumiya]

I noticed the known issues in MS Word at the end of the page and the link told that it's an MSBuild problem. I don't think we need to communicate the build platform from one project to another, current project nuget should refer current project platform target. Besides, we do have x64/arm WinRT.Host.dll/WinRT.Host.dll.mui architecture at the hosting folder to support building. But at C:\Users\<Username>\.nuget\packages\microsoft.windows.cswinrt\2.2.0\lib\net6.0 WinRT.Host.Shim.dll with WinRT.Runtime.dll we only have x86 build. And these nuget targets files are wrong. I found that even whenever I choose x64/arm, the files that have all platform build but eventually will always be x86 dll at output folder.

Here, line 20-21 are not good. AnyCPU option directly leads to a unexpected result. we should use $(PlatformTarget) or $(RuntimeIdentifier) to replace. And there are also many problems in different nuget target files.

Obviously, building a solution that can only use up to 4GB of RAM is ridiculous and unacceptable, as many application scenarios require x64 to perform better.

So now I check nuget target files again. Summary: When switching the project/solution platform to x64, the “References” node in Solution Explorer does not change, and the output artifacts remain unchanged even after Rebuild. This is due to the CsWinRT NuGet targets removing WinRT.Host.dll/WinRT.Host.Shim.dll references without providing architecture-aware copy logic in the non-authoring path. As a result, platform changes (x86/x64/arm64) often do not reflect in references or outputs, and in multi-RID scenarios the host architecture may be mismatched at runtime.

Repro steps:

Install Microsoft.Windows.CsWinRT 2.2.0 in a .NET project consuming WinRT projections (not an authoring component). Set Solution Platform to x64 (and optionally add RuntimeIdentifiers: win-x86;win-x64;win-arm64). Rebuild the solution and observe: In Solution Explorer, the “References” node does not show architecture-specific host assets. The output folder does not include an architecture-specific WinRT.Host.dll, nor does it change when switching x86/x64 and rebuilding. Expected:

Either: The references/output should reflect the selected platform/RID when the project needs WinRT.Host.dll; or CsWinRT should provide a clear, architecture-aware selection/copy mechanism for WinRT.Host.dll in the consumer path (not only in authoring). In multi-RID scenarios, the correct host architecture should always be selected based on RuntimeIdentifier/PlatformTarget, avoiding mismatches. Actual:

Microsoft.Windows.CsWinRT.targets removes host references: Target CsWinRTRemoveHostingDllReferences (around lines 124–136 in v2.2.0): Removes runtimes**\native\WinRT.Host.dll from ReferenceCopyLocalPaths/RuntimeCopyLocalItems/RuntimeTargetsCopyLocalItems. Removes lib\net6.0\WinRT.Host.Shim.dll from Reference/ResolvedCompileFileDefinitions/RuntimeCopyLocalItems. There is no corresponding architecture-aware copy logic in this file for consumer projects (no usage of PlatformTarget/RuntimeIdentifier). Architecture-specific copying exists only in authoring targets: Microsoft.Windows.CsWinRT.Authoring.targets chooses hosting\native\WinRT.Host.dll based on $(Platform), mapping AnyCPU → x86. Microsoft.Windows.CsWinRT.Authoring.Transitive.targets uses a _NormalizedPlatform based on $(Platform) (Win32 → x86). Neither uses (PlatformTarget)or(RuntimeIdentifier) for robust RID-based selection. Consequently, switching solution platform in consumer projects does not affect references or outputs, and in multi-RID setups a fallback/mismatch can occur at runtime. Why this is a problem:

Consumers that need WinRT.Host.dll at runtime can end up with the wrong architecture or with no host copied at all. VS design-time experience is confusing: changing platform appears to have no effect. AnyCPU is implicitly treated as x86 in authoring, which is surprising and error-prone in x64/arm64 environments. Proposed fix:

Add architecture-aware selection for WinRT.Host.dll in the consumer path, with the following precedence: RuntimeIdentifier (win-x86/win-x64/win-arm64) → map to x86/x64/arm64. PlatformTarget as a fallback. Platform as a last resort; avoid mapping AnyCPU to x86 by default. Ensure that if consumer projects actually need WinRT.Host.dll, the correct binary is copied post-removal, so that references/output reflect the architecture. Optionally, emit a warning when AnyCPU and no RID is set but the host is needed, instead of silently picking x86. Reference snippets:

Removal logic in Microsoft.Windows.CsWinRT.targets: Target “CsWinRTRemoveHostingDllReferences”, removes: $(CsWinRTPath)runtimes**\native\WinRT.Host.dll from ReferenceCopyLocalPaths/RuntimeCopyLocalItems/RuntimeTargetsCopyLocalItems $(CsWinRTPath)lib\net6.0\WinRT.Host.Shim.dll from Reference/ResolvedCompileFileDefinitions/RuntimeCopyLocalItems Authoring-only copying logic: Microsoft.Windows.CsWinRT.Authoring.targets: AnyCPU → x86 mapping via CsWinRTAuthoring_Platform Copies hosting$(CsWinRTAuthoring_Platform)\native\WinRT.Host.dll Microsoft.Windows.CsWinRT.Authoring.Transitive.targets: Uses _NormalizedPlatform derived from $(Platform), not RuntimeIdentifier/PlatformTarget Impact:

Architecture mismatch for WinRT.Host.dll in multi-RID or mixed-platform environments. VS references/output do not reflect platform changes for consumer projects.

Thanks!

[hoshiizumiya]

I'm working on fixing it. Any ideas will be helpful.