使用try-convert迁移至Microsoft.NET.Sdk时命名空间冲突如何解决

冲突扩散的核心原因是SDK风格项目默认会将所有依赖标记为全局可传递，你之前在本地项目设置的引用别名仅对当前项目的编译上下文生效，不会同步给下游引用方，下游项目编译时会同时加载WPF Toolkit和标准库中的同名VisualStateManager类型，直接触发命名冲突。
按照以下步骤配置即可从构建层面彻底解决，不需要批量修改业务代码：

• 第一步：修改根项目（即直接引用旧版WPF Toolkit的项目）的对应引用配置，阻断冲突依赖的传递
  如果是直接引用本地DLL，在csproj中修改对应引用节点如下：

  <Reference Include="WPFToolkit">
    <HintPath>你的WPFToolkit.dll相对路径</HintPath>
    <!-- 替换默认Global别名，设置专属别名 -->
    <Aliases>WPFToolkit</Aliases>
    <!-- 禁止该依赖向引用当前项目的下游项目传递 -->
    <PrivateAssets>all</PrivateAssets>
    <ExcludeAssets>compile</ExcludeAssets>
  </Reference>
  

  如果是通过NuGet引用WPF Toolkit，对应配置如下：

  <PackageReference Include="WPFToolkit" Version="你使用的具体版本号">
    <Aliases>WPFToolkit</Aliases>
    <PrivateAssets>all</PrivateAssets>
    <ExcludeAssets>compile</ExcludeAssets>
  </PackageReference>
  

  本地需要使用WPF Toolkit中VisualStateManager的代码文件，保持你之前的写法即可：在文件顶部加extern alias WPFToolkit;，调用时通过别名限定全路径WPFToolkit::Microsoft.Windows.Themes.VisualStateManager，避免和标准库类型混淆。
• 第二步：处理下游项目的特殊需求
  如果部分引用根项目的下游项目本身也需要使用WPF Toolkit的能力，不要依赖传递过来的引用，直接在对应下游项目中单独添加WPF Toolkit引用，同样配置专属别名和PrivateAssets属性即可，不会再触发冲突。
• 第三步（可选）：全局统一配置减少重复劳动
  如果你的解决方案中有多个项目都需要引用WPF Toolkit，可以在解决方案根目录新建Directory.Build.props文件，写入全局配置，所有项目会自动应用规则，不需要逐个修改csproj：

  <Project>
    <ItemGroup>
      <!-- 适配本地DLL引用场景 -->
      <Reference Update="WPFToolkit">
        <Aliases>WPFToolkit</Aliases>
        <PrivateAssets>all</PrivateAssets>
        <ExcludeAssets>compile</ExcludeAssets>
      </Reference>
      <!-- 适配NuGet引用场景 -->
      <PackageReference Update="WPFToolkit" Version="*">
        <Aliases>WPFToolkit</Aliases>
        <PrivateAssets>all</PrivateAssets>
        <ExcludeAssets>compile</ExcludeAssets>
      </PackageReference>
    </ItemGroup>
  </Project>
  

注意：不要通过全局using或命名空间级using引入WPF Toolkit的Microsoft.Windows.Themes命名空间，所有用到Toolkit版本VisualStateManager的位置必须通过别名全限定调用，避免编译时类型匹配歧义。

配置完成后可以验证：打开任意下游项目的依赖列表，查看编译期依赖项，如果没有WPFToolkit程序集，说明传递阻断配置生效，不会再出现跨项目的命名冲突。

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