WinUI3项目中如何将其他项目产出的DLL复制到输出目录的指定子文件夹

我完全懂你遇到的这个痛点——WinUI3的打包机制确实和传统WPF/WinForms项目不一样，直接硬编码AppX路径肯定不是稳妥的办法，毕竟这个路径会跟着你的构建配置（Debug/Release、目标平台）变化，硬写很容易出问题。

核心问题在于WinUI3项目的构建流程：它会先把文件编译到$(TargetDir)，之后再将必要文件复制到AppX子目录（也就是最终的运行/打包目录）。所以你之前的PostBuild事件执行时机太早，而且硬编码AppX路径不够可靠。下面给你两个靠谱的解决方案：

方案一：用WinUI3内置的MSBuild属性替换硬编码路径 #

WinUI3项目提供了专门的MSBuild属性来获取最终的AppX输出目录，不用自己猜路径。你可以把PostBuild目标的执行时机调整到AppX包生成之后，同时用$(AppxPackageDir)这个内置属性来指定目标路径：

<Target Name="CopyPluginsToAppX" AfterTargets="GenerateAppxPackage">
  <Exec Command="xcopy /i /y /d &quot;$(SolutionDir)OtherProjectProducingDll1\$(OutDir)*.dll&quot; &quot;$(AppxPackageDir)Plugins\&quot;" />
  <Exec Command="xcopy /i /y /d &quot;$(SolutionDir)OtherProjectProducingDll2\$(OutDir)*.dll&quot; &quot;$(AppxPackageDir)Plugins\&quot;" />
</Target>

• GenerateAppxPackage是WinUI3生成AppX包的关键目标，在它之后执行复制，能确保文件被放到最终的运行目录里。
• $(AppxPackageDir)会自动根据当前的构建配置（比如x64/Debug、x86/Release）指向正确的AppX输出路径，完全不用硬编码。

方案二：用MSBuild的Copy任务替代xcopy（更推荐） #

如果想更贴合MSBuild的构建逻辑，避免命令行xcopy的潜在问题，可以用MSBuild原生的Copy任务来实现，它的可读性和可靠性更好：

<Target Name="CopyPluginsToAppX" AfterTargets="GenerateAppxPackage">
  <Copy
    SourceFiles="$(SolutionDir)OtherProjectProducingDll1\$(OutDir)*.dll"
    DestinationFolder="$(AppxPackageDir)Plugins\"
    SkipUnchangedFiles="true"
    OverwriteReadOnlyFiles="true" />
  <Copy
    SourceFiles="$(SolutionDir)OtherProjectProducingDll2\$(OutDir)*.dll"
    DestinationFolder="$(AppxPackageDir)Plugins\"
    SkipUnchangedFiles="true"
    OverwriteReadOnlyFiles="true" />
</Target>

这个任务会自动跳过未修改的文件（SkipUnchangedFiles="true"），还能覆盖只读文件，比xcopy的命令行参数更直观。

另外，你提到的「CopyLocal无法指定子文件夹」确实是个局限，所以自定义MSBuild目标是目前最灵活的解决方式——既能控制复制时机，又能精准指定目标子目录，完全适配WinUI3的构建流程。

内容来源于stack exchange