Question

我正在尝试创建几个nuget包供公司内部使用： OurCompany.Infrastructure.Logging.Interfaces和OurCompany.Infrastructure.Logging。

因此，我在同一解决方案中创建了两个类库项目，提供了OurCompany.Infrastructure.Logging.Interfaces的实现并创建了一个包。

现在我有一个问题：如何在OurCompany.Infrastructure.Logging.Interfaces项目中正确引用OurCompany.Infrastructure.Logging库？

我应该将其添加为nuget包还是仅添加为项目引用？

Answer 1

没有完美的解决方案。

当您使用NuGet软件包但在使用使用它的应用程序时需要在库中进行更改时，您需要在库中进行更改，发布该软件包的新版本，然后在应用程序，然后希望您在库中所做的更改能够按需工作。尤其是在使用新功能时，这非常慢，因为您的软件设计通常在您第一次启动到完成之间多次更改，并且调试更加困难。如果您的公司没有工具来检查更新并提醒团队更新可用，那么您可能会陷入碎片化的局面，有些团队仍在使用非常旧的库版本，并且他们尝试升级应用程序中断和需求额外的时间来适应着色库中的重大更改。

另一方面，如果您使用项目引用，则假定拥有足够的自动化测试，但调试和实现新功能会更容易，并且可以立即检测到重大更改，但是要求所有代码都位于同一存储库中，或者看起来确实一样（也许使用git子模块，或者有一个约定，其中总是将多个存储库克隆在同一相对路径中）。

Google和Microsoft都必须实施自己的源代码管理系统工具来处理庞大的存储库，而这些存储库对于使用单个开发人员计算机而言太大了，而且还需要加快开发箱和CI代理的编译时间，因为您需要不想在一个应用程序中更改一行代码，而导致公司的每一个应用程序都需要重建和测试。但是除非您的公司不想让工程师致力于构建系统而不为客户的应用做贡献，否则这是不可行的。

因此，子模块或具有相对路径约定的多仓库听起来很吸引人，但仍然需要在使用该库的每个CI构建上重新编译该库。没什么大不了的，但是如果更改共享库的频率非常低，那么使对库的代码更改变得容易没有什么好处。另外，当其他人更新库时，您如何知道需要更新子模块？ NuGet工具可能更适合检查更新和实际更新。

就个人而言，我总是将项目引用引用用于已经在同一解决方案中的项目，并将nuget引用用于其他所有内容。我过去所做的是当需要修复错误或向打包的库中添加新功能时，我克隆了两个回购方，将库的项目临时添加到应用的解决方案中，并将nuget引用更改为项目参考。然后，我将它们发展成一个仓库。最后，在签入之前，我需要手动撤消解决方案/项目参考更改并增加软件包参考版本号。由于这是手动操作，因此有时会出错。但这是我到目前为止找到的最佳平衡。您需要决定哪种方法最适合您自己的情况。

Answer 2

最好的解决方案是：两者都做！

使用Choose指令，您可以设置条件引用：

  <Choose>
    <When Condition="'$(Configuration)'=='Debug'">
      <ItemGroup>
        <ProjectReference Include="Path\To\Your.Awesome.Package.csproj" />
      </ItemGroup>
    </When>
    <Otherwise>
      <ItemGroup>
        <PackageReference Include="Your.Awesome.Package" Version="1.0.0" />
      </ItemGroup>
    </Otherwise>
  </Choose>

在此示例中，您的项目在Debug模式下运行时将使用直接项目引用，然后其余时间将使用NuGet包引用。

即使您仍然负责维护正确的NuGet软件包版本，也没有完美的选择。

我希望这会对某人有所帮助。

如何在基于nuget的体系结构中正确引用库

2 个答案: