复用Directory.Build.props并添加-windows配置WPF项目可行吗？

这种通过$(TargetFramework)-windows拼接的方式是可行的，但存在几个需要留意的潜在问题：

• 属性优先级与覆盖问题
  Directory.Build.props会在项目文件之前导入，你在WPF项目csproj里写的<TargetFramework>$(TargetFramework)-windows</TargetFramework>会覆盖props里的原始值。但如果项目后续还有其他导入文件（比如Directory.Build.targets）或者其他配置节点修改了TargetFramework变量，可能会导致拼接结果不符合预期。建议确保WPF项目的这个配置放在所有可能修改TargetFramework的节点之后，避免被意外覆盖。

• SDK与NuGet包的兼容性
  大部分现代.NET SDK和WPF相关NuGet包能正确解析拼接后的框架名称，但少数老版本的包或工具可能无法识别这种动态生成的TargetFramework标识符，可能出现编译警告或依赖加载失败的情况。如果遇到这类问题，需要确认相关包是否支持net8.0-windows框架，或者临时改为直接写死框架名称。

• 多目标框架场景冲突
  如果你的解决方案里有项目配置了多目标框架（比如<TargetFrameworks>net7.0;net8.0</TargetFrameworks>），这种拼接方式会把所有目标框架都加上-windows后缀，导致非WPF项目也被配置为Windows专属框架，这显然不符合需求。这种情况下，WPF项目需要单独明确配置多目标的Windows框架，比如<TargetFrameworks>net7.0-windows;net8.0-windows</TargetFrameworks>，不能依赖props里的多目标值拼接。

更稳妥的替代方案 #

建议不在Directory.Build.props里直接设置TargetFramework，而是定义一个框架版本变量：

<!-- Directory.Build.props -->
<PropertyGroup>
  <BaseFrameworkVersion>net8.0</BaseFrameworkVersion>
</PropertyGroup>

然后普通项目中使用：

<!-- 普通类库/控制台项目csproj -->
<PropertyGroup>
  <TargetFramework>$(BaseFrameworkVersion)</TargetFramework>
</PropertyGroup>

WPF项目中使用：

<!-- WPF项目csproj -->
<PropertyGroup>
  <TargetFramework>$(BaseFrameworkVersion)-windows</TargetFramework>
</PropertyGroup>

这种方式逻辑更清晰，能彻底避免上述潜在问题，同时也保留了统一管理框架版本的优势。

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