如何让实际UWP应用本身兼容.NET Standard 2.0？

这个问题确实挺反直觉的，当初我刚接触.NET Standard的时候也懵了好久，其实核心思路是把业务逻辑和UI层彻底分离，再配合工具检查来规避问题，下面一步步说清楚：

1. 核心方案：将业务逻辑封装到.NET Standard 2.0类库 #

这是最靠谱的做法，原因很直接：

• 当你创建一个目标框架为.NET Standard 2.0的类库时，Visual Studio的编译器会直接限制你只能使用该标准定义的API，一旦你调用了.NET Core（或UWP专属）的API，编译阶段就会报错，从根源上避免越界。
• 你的UWP项目（目标框架为.NET Core）只负责UI交互、页面导航这类平台相关的逻辑，所有业务代码都通过调用这个类库来实现。这样UWP项目本身几乎不会接触到非.NET Standard的API，就算有也是平台必需的UI相关代码，完全可控。

2. 验证UWP项目是否合规的工具 #

如果担心UWP项目里不小心写了超出.NET Standard的业务代码，可以用这些工具检查：

• Visual Studio内置兼容性检查：右键UWP项目→属性→应用程序→找到“兼容性”区域，勾选“针对.NET Standard 2.0进行兼容性检查”。之后编译或运行时，只要代码里用了不在.NET Standard 2.0范围内的API，就会弹出警告或错误。
• Roslyn分析器：可以使用社区维护的.NET Standard合规检查插件，或者自定义分析规则，扫描代码中引用的API是否属于.NET Standard 2.0的范畴。
• 手动排查依赖：使用命令dotnet list package --include-transitive查看项目的所有依赖，确认没有引入依赖非.NET Standard API的包，但这种方法比较繁琐，不如工具高效。

3. 为什么不能直接把UWP项目设为.NET Standard 2.0？ #

这是因为UWP本身是基于.NET Core的平台特定实现，它包含大量专属的API（比如XAML控件、UWP特有的文件访问权限、系统通知等），这些API并不属于.NET Standard的规范范畴。所以UWP项目必须以.NET Core为目标框架，才能支持这些平台必需的功能——但这并不影响你让核心业务逻辑严格遵守.NET Standard。

额外小技巧 #

• 把单元测试项目也设为.NET Standard 2.0，这样在测试业务逻辑时，也能同步验证代码是否符合标准，避免后续移植或扩展时出问题。
• 尽量保持UWP项目的“轻量化”，除了UI相关代码，不要在里面写任何业务逻辑，从架构层面降低越界的风险。

内容的提问来源于stack exchange，提问作者Dean Roddey