带有 2 个唯一数据文件的 UWP APPX1101 错误

Question

我正在将一个相当大的项目转换为 Windows 10 应用商店应用程序。我已经编译它，现在无法克服几个 APPX1101 错误 - “有效负载包含两个或多个具有相同目标路径的文件”。这些文件是项目的 .xml 文件的一部分，例如“baseDir\Assets\foo\timers.xml”和“baseDir\Assets\bar\timers.xml”。不同的文件和不同的路径。

解决方案和项目由 CMake (3.72) 创建。已修改 cmake 文件以支持创建 Windows 10 商店应用平台配置。

似乎目录树已被展平并且文件重叠。但是如何或为什么使我无法理解。我见过的每个 UWP 项目都在主项目下包含一个“Assets”文件夹，但这个没有。我在名为“资源文件”的文件夹中看到了诸如 Logo.png 和 SplashScreen.png 之类的文件。导致错误的文件位于 UWP 项目之前存在的名为“Assets”的文件夹下。

主要是： 我该如何解决这个错误？我是否错误配置了 CMake？

另外： 如何避免目录扁平化？ 有几百个数据文件占用了程序使用的几百兆字节。我需要将它们中的每一个都添加到要打包的解决方案中吗？

更新：

我收集了更多信息，但不足以完全满足这个问题。由于如何通过 CMake 将文件添加到项目以及如何打包原始 Windows 产品，导致输出中的目录扁平化。 XML 文件以 .vcxproj 中的完整路径添加到项目中。 .vcxproj.filters 还使用文件的完整路径和像“Data\foo”这样的过滤器。桌面 Windows 版本不需要关心，因为它知道在哪里可以找到与可执行文件相关的数据，并且是由外部工具打包的。

我手动添加了“资产”过滤器并修改了 .vcxproj 和 .vcxproj.filters 文件。 .vcxproj 文件需要将属性添加到文件的包含中。这使用了相对路径并消除了 APPX1101 重复错误。

.vcxproj

<XML Include="..\Base\Assets\foo\Data\timers.xml">
  <Link>Assets\foo\Data\timers.xml</Link>
</XML>

.vcxproj.filters

<XML Include="..\Base\Assets\foo\Data\timers.xml">
  <Filter>Assets\foo</Filter>
</XML>

更新 2

据我所知，不可能让 CMake 将 <Link> 添加到 XML 和其他 .vcxproj 包含类型。我浏览了最新的 CMake 源代码（3.8rc）。 <XML Include> 添加到 cmVisualStudio10TargetGenerator::WriteExtraSource() 中的 cmVisualStudio10TargetGenerator.cxx 中的 .vcxproj。其他类型可以选择设置标志来添加<Link>，但XML和其他数据类型没有设置标志的代码。

我能看到的唯一选项是修改 CMake 源或重新设计项目以使用与 vcxproj.filters 文件中匹配的包含相同的 <Filter> 匹配的相对路径添加数据文件。这只是 CMake 的一个问题。 Visual Studio 2015/2017 在树上方添加资产没有问题。 GitHub 上的 MS UWP 示例是为了在示例项目之间共享通用数据。

Answer 1

已经有一段时间了，我将其发布为答案，以防其他人遇到此问题。我没有将其标记为已接受，因为我发现解决方法相当薄弱。我对 CMake 的了解有限，而我对通用 Windows 应用的了解就更少了。

主要问题是 CMake 在设计上并未构建可重定位的解决方案。即，您不能将 Windows 解决方案 xcopy 到另一棵树并期望它能够像使用 Visual Studio IDE 中生成的解决方案一样工作。

第二个问题是，这是一个已经针对多个平台的大型预先存在的项目。巨大的，我的意思是它以双层蓝光光盘的形式提供。资产文件的位置是固定的，高于 CMake 构建文件夹的位置。当文件的位置不在预期的资产文件夹下时，这会导致文件在添加到布局时被剥夺其路径。

在当前的 CMake (3.8) 中无法在项目文件中的 include 中添加 <link> 标签。并且 CMake 会创建包含文件的完整路径的包含标记，而不是设计的相对路径。

我想出的解决方法是在批处理文件中添加一个步骤，该步骤调用 CMake 来编辑 .vcproj 和 vcproj.filters 文件以更改固定资产路径的相对路径，然后添加另一个步骤来创建符号链接/将构建文件夹下的 junction (SysInternals.com) 连接到资产所在的位置。资产现在显示为位于预期资产文件夹下，现在已正确添加到布局中。

正如我所说，并不理想，但它有效。真正的解决方案是重新组织所有数据，但当大量数据由不同的脚本、工具、来源和贡献者生成时，这对于这个项目来说是不可能发生的。