SVN单仓迁移多Git仓遇困境：Project与Package引用冲突

针对你遇到的同时使用ProjectReference和PackageReference导致的Assembly重复问题，分享几个实际用过的解决思路：

1. 条件化引用（推荐） #

在.csproj里通过编译条件切换引用方式，本地开发用ProjectReference，CI/发布用PackageReference，兼顾本地调试效率和环境一致性：

<Choose>
  <When Condition="'$(LocalDev)' == 'true'">
    <ItemGroup>
      <ProjectReference Include="..\Path\To\Your\Library.csproj" />
    </ItemGroup>
  </When>
  <Otherwise>
    <ItemGroup>
      <PackageReference Include="YourLibrary" Version="x.x.x.x" />
    </ItemGroup>
  </Otherwise>
</Choose>

本地开发时，通过VS的「项目属性→生成→常规→条件编译符号」添加LocalDev=true，或者编译时加参数dotnet build /p:LocalDev=true，就能直接引用项目文件修改调试；CI构建或者发布时不设置这个参数，自动切换为NuGet包引用。

2. 严格集群内聚性 #

核心库集群内部的依赖必须全部用ProjectReference，只有跨集群/未迁移的外部依赖才用PackageReference。迁移核心集群时，先梳理内部依赖链，把所有集群内的库都纳入同一个Git仓库，确保内部没有跨仓库的包引用，从根源上避免同Assembly的双重引入。

3. 临时Assembly别名（过渡用） #

如果个别场景必须同时引用项目和包，可以给其中一个引用加别名，代码里通过别名区分调用：
在.csproj中给包引用加别名：

<PackageReference Include="YourLibrary" Version="x.x.x.x">
  <Aliases>NuGetLib</Aliases>
</PackageReference>

然后在代码文件顶部声明别名：

extern alias NuGetLib;

使用时指定别名：

var instance = new NuGetLib::YourLibrary.YourClass();

这个方法适合短期过渡，长期维护成本高，不建议大面积使用。

4. 本地NuGet源加速打包 #

搭建本地私有NuGet源（比如BaGet），本地修改库后，快速打包推送到本地源，其他项目引用本地源的包。相比推送到远程源，这个流程快很多，同时能避免项目引用的冲突，适合集群间依赖还未完全迁移的过渡期。

5. 阶段性冻结依赖修改 #

迁移核心集群期间，暂时冻结SVN中对应核心库的代码修改，先完成核心集群的迁移和内部依赖梳理，确保集群内全部用ProjectReference后，再逐步处理对外依赖的迁移和切换，减少版本混乱导致的冲突。

内容的提问来源于stack exchange，提问作者mario-dg