如何解决net6.0 CLI项目引用net6.0-windows类库的依赖问题

这是个很典型的跨目标框架工具依赖问题，咱们一步步拆解解决方案，再分析你之前的思路：

正确的处理方案 #

1. 保留类库的多目标配置 #

你的类库必须维持<TargetFrameworks>net6.0;net6.0-windows</TargetFrameworks>的配置——这一步思路是对的，因为既要满足其他依赖Windows框架的项目，又要给CLI项目提供通用目标版本。

但要注意：类库中所有依赖Windows特定API（比如WPF、WinForms、Windows原生API）的代码，需要用条件编译隔离到net6.0-windows的分支里，确保net6.0目标下的代码是纯跨平台/通用逻辑。示例：

#if NET6_0_WINDOWS
// 这里放Windows特定代码，比如调用Win32 API、WPF控件逻辑等
public void WindowsSpecificMethod() { ... }
#endif

// 这里放CLI项目需要的通用逻辑
public void CommonMethod() { ... }

2. 调整CLI项目的引用配置 #

CLI项目必须保持<TargetFramework>net6.0</TargetFramework>（因为PackAsTool确实不支持带平台标识符的框架，这是.NET SDK的硬性限制），同时在CLI的项目文件里，明确指定引用类库的net6.0目标版本，避免SDK检测到Windows目标而报错：

<ProjectReference Include="..\YourClassLibraryName\YourClassLibraryName.csproj">
  <SetTargetFramework>TargetFramework=net6.0</SetTargetFramework>
</ProjectReference>

这样配置后，CLI只会引用类库的net6.0通用版本，打包工具也不会再触发NETSDK1146错误。

特殊情况：类库全是Windows特定代码 #

如果你的类库所有功能都依赖Windows平台（比如完全是WPF UI组件），那CLI项目本来就无法直接使用这类代码——因为CLI工具是设计为无UI、跨平台（或至少不绑定Windows桌面框架）的。这种情况下，你需要：

• 把类库中的通用业务逻辑抽离出来，新建一个纯net6.0的类库
• 让原net6.0-windows类库引用这个新的通用类库
• CLI项目只引用这个新的通用类库

对之前思路的分析 #

• 「把类库改成net6.0」：思路错误，因为类库必须保留net6.0-windows来支持其他依赖项目，且类库本身依赖Windows特定API，改了会编译失败。
• 「把CLI改成net6.0-windows」：思路错误，PackAsTool从.NET 5开始就明确不支持带平台标识符的框架，官方也明确工具项目必须用纯netX.0目标。
• 「类库设置多目标」：思路正确，但缺少关键的一步——在CLI项目引用时指定类库的net6.0目标，导致打包工具检测到类库包含Windows目标分支，触发了错误。

内容的提问来源于stack exchange，提问作者Josef Širůčka