.NET 6解决方案配置单一生成输出文件夹的技术问题

方案一：直接指定固定输出路径 #

在每个项目的 .csproj 文件中添加 OutputPath 属性，完全跳过默认的路径拼接逻辑：

<PropertyGroup>
  <!-- 可根据项目结构调整为相对路径或绝对路径 -->
  <OutputPath>..\BuildOutput\</OutputPath>
</PropertyGroup>

所有项目设置相同的 OutputPath 后，编译产物都会直接输出到指定文件夹，不受TFM、配置或运行时标识符（RID）的影响。

方案二：禁用默认的路径追加规则 #

如果想保留使用 BaseOutputPath，可以通过关闭TFM和RID的路径追加来实现统一输出：

<PropertyGroup>
  <BaseOutputPath>..\foobar\BuildOutput\</BaseOutputPath>
  <!-- 禁止添加TFM子文件夹 -->
  <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
  <!-- 禁止添加RID子文件夹（若项目指定了运行时标识符） -->
  <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
</PropertyGroup>

设置后，所有项目的编译产物都会直接放在 BaseOutputPath 指定的目录下，不会生成额外子文件夹。

关于将类库TFM改为net6.0-windows的弊端分析 #

如果你的类库仅服务于这个Windows桌面应用，这种方案的实际弊端很小，但有几点需要注意：

• 类库会间接引入Windows桌面相关基础库（如WindowsBase、PresentationCore），虽然你可能用不到这些依赖，但编译后的程序集会携带这些引用。不过因为你的WPF应用本身就会加载这些库，所以运行时不会有问题。
• 会限制类库的复用性：如果未来想把这些类库迁移到非Windows桌面的.NET6项目（比如控制台、ASP.NET Core），会因为TFM不兼容而无法直接使用。但你明确说明类库仅用于该Windows桌面应用，这个风险可以忽略。
• 部分Windows特定的编译选项会被默认启用，但如果类库没有用到相关API，不会对功能产生影响。

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