打包WinUI3应用构建ProcessorArchitecture报错原因及修复方法

这个错误来自Windows App SDK 1.1.2版本内置的MSBuild打包校验逻辑：使用MSIX打包、带原生app host入口的.NET WinUI3应用不支持输出为ProcessorArchitecture中立（AnyCPU）架构，必须明确指定目标运行时架构才能完成打包。

你虽然在csproj里写了<PlatformTarget>x64</PlatformTarget>、在Pipeline变量里定义了Build Platform为x64，仍然触发报错的核心原因是：

• WinUI3打包流程判断输出架构的核心依据是RuntimeIdentifier（RID）参数，仅设置PlatformTarget不会自动注入对应RID，校验逻辑仍会判定架构未明确指定
• Azure DevOps默认的dotnet构建步骤不会自动把Pipeline中定义的Build Platform变量映射为MSBuild识别的RuntimeIdentifier参数，你虽然在csproj里声明了所有支持的RID列表（RuntimeIdentifiers复数属性），但构建时未选中具体值，会默认回退到AnyCPU架构配置，触发校验拦截。

按优先级从高到低选择即可：

• 显式在构建步骤中传入RuntimeIdentifier参数
  这是最稳定的方案，直接在Pipeline的dotnet publish（推荐用publish而非build做打包流程）步骤中，根据当前构建平台传入对应RID参数，示例配置：

  - task: DotNetCoreCLI@2
    displayName: 构建打包WinUI3应用
    inputs:
      command: 'publish'
      projects: '**/你的项目名.csproj'
      arguments: '-c $(BuildConfiguration) -r win10-$(BuildPlatform) --self-contained true'
  

  注意如果你的Pipeline变量名是带空格的Build Platform，参数里要写为win10-$(Build Platform)，建议把变量名改为无空格格式避免MSBuild解析异常。如果要做多架构并行构建，直接把RID参数和构建矩阵的平台值绑定即可。
• 在csproj中添加平台到RID的自动映射逻辑
  如果不想每次构建都手动传参，可以在csproj的全局PropertyGroup中添加如下配置，让构建过程根据传入的Platform值自动匹配对应RID：

  <RuntimeIdentifier Condition="'$(Platform)' == 'x64'">win10-x64</RuntimeIdentifier>
  <RuntimeIdentifier Condition="'$(Platform)' == 'x86'">win10-x86</RuntimeIdentifier>
  <RuntimeIdentifier Condition="'$(Platform)' == 'arm64'">win10-arm64</RuntimeIdentifier>
  

  配置完成后，只要构建时传入/p:Platform=x64这类明确的平台参数，就不会再出现架构中立的报错。
• 排查配置映射的默认回退问题
  检查解决方案的配置管理器，确认x64解决方案平台下对应的项目平台没有被错误映射为AnyCPU；同时检查Pipeline的构建步骤是否引用了你自定义的Build Platform变量——很多Azure DevOps内置构建模板会默认把Build Platform设为Any CPU，如果自定义变量没有被步骤正确引用，会直接使用默认值触发报错。可以通过构建日志开头的Initial Properties输出，确认实际生效的Platform和RuntimeIdentifier值是否符合预期。

注意：不要为了绕过校验直接设置<UseAppHost>false</UseAppHost>，该配置会导致打包后的应用没有可执行入口，安装后无法正常启动。

内容的提问来源于stack exchange，提问作者Sascha Manns