WindowsAppSDK 1.6 中类库引用WebView2的构建问题分析

在WindowsAppSDK 1.6版本中，开发者遇到一个特殊的构建问题：当一个类库项目通过间接引用的方式（即通过另一个NuGet包）引用WindowsAppSDK 1.6时，项目构建会失败。这个问题主要影响那些希望将WebView2功能封装在独立类库中的开发场景。

问题现象

当开发者尝试构建一个三层结构的解决方案时会出现构建错误：

1. 基础类库项目（直接引用WindowsAppSDK 1.6）
2. 中间层类库项目（通过NuGet引用基础类库）
3. 最终应用项目（引用中间层类库）

构建过程中会报错提示找不到WebView2Loader.dll文件，错误信息表明系统尝试从错误的路径位置复制这个文件。

技术背景

这个问题源于WindowsAppSDK 1.6对WebView2加载机制的改动。在1.6版本中，WindowsAppSDK团队将WebView2包解耦，使其可以独立更新。这种架构变化虽然带来了灵活性，但也引入了一些构建时的依赖关系问题。

根本原因分析

深入研究发现，当WebView2作为间接依赖时，构建系统无法正确处理其原生DLL文件的复制逻辑。具体表现为：

1. 构建系统错误地将WebView2Loader.dll识别为资源文件而非运行时依赖
2. 文件复制路径生成不正确
3. 中间层类库无法正确继承基础类库的WebView2依赖关系

解决方案

目前有两种可行的解决方案：

方案一：直接引用WebView2包

在基础类库项目中显式添加对最新版Microsoft.Web.WebView2包的引用（1.0.2903.40或更高版本）。这种方法简单直接，但会强制类库项目声明一个它可能并不直接使用的依赖。

方案二：等待WindowsAppSDK 1.7

微软团队已确认将在WindowsAppSDK 1.7版本中彻底解决此问题。对于不急于发布的项目，可以等待官方修复。

最佳实践建议

1. 对于新项目，建议直接使用WindowsAppSDK 1.7（当可用时）
2. 如果必须使用1.6版本，应在类库项目中显式声明WebView2依赖
3. 构建前清除NuGet缓存可以避免一些潜在问题
4. 考虑将WebView2相关功能隔离到专门的类库中，减少不必要的依赖传播

技术影响评估

这个问题主要影响以下场景：

• 多层架构的WinUI 3应用程序
• 将WebView2功能封装在独立类库中的设计
• 使用NuGet包分发WinUI组件的场景

对于简单的单层应用或直接引用所有依赖的项目，通常不会遇到此问题。

总结

WindowsAppSDK 1.6中的这个构建问题展示了组件解耦可能带来的复杂依赖关系挑战。开发者需要理解这种架构变化对构建系统的影响，并采取适当的应对措施。微软团队已经意识到这个问题，并承诺在后续版本中提供更完善的解决方案。