让我们考虑以下情形：我们有两个.NET Standard项目要公开并为以下项目创建NuGet包：
LibrarySolution
ClassLibrary1（CL1）
∟ClassLibrary2（CL2）
重要的是要提到CL1与CL2具有ProjectReference。
NuGet的文档指出，理想情况下，我们应该使用一个程序集生成一个包，因此我们为每个包创建一个NuGet包。
当我们需要在LibrarySolution的范围内确定CL1需要哪个版本的CL2时出现问题，因为我们有直接的项目参考。
我想到以下两种方法：
在解决方案中维护项目引用，这意味着我们需要将程序包版本存储在csproj文件中，提交版本更改等，以便版本约束和依赖项要求正确（我们目前处理版本控制）在CI管道中，并且当前版本存储在此处，而不是在代码中存储。）
将对CL2的依赖关系转换为PackageReference。这样，CL1将始终依赖于已发布的CL2版本。但是，这样做将意味着围绕发布和更新NuGet软件包（批准PR，合并，CI等）进行所有操作，这可能会非常耗时。
我认为选项1更好，但还是有点手动。是否有解决此问题的最佳方法？我宁愿不要使用包来引用位于相同解决方案内部的项目，因为这会导致不必要的间接访问。
答案 0 :(得分：0)
根据我的经验，使用PackageReference是最干净，最少的头痛方法。是的，还有更多的开销，但这使所有事情都变得明确，这是官方支持的解决方案。
（如果您对此路由犹豫不决，因为每次更改CL2时都需要更新CL1，则可能需要考虑组件化是否有意义。理想情况下，CL2应该定义相对稳定的接口，并且可以独立于CL1进行更改。 ）
否则，有两种您没有提到的方法：
在单个NuGet程序包中包含两个dll。尽管现有工具尚未正式支持此功能，但此处介绍了几种解决方法：https://github.com/NuGet/Home/issues/3891
将这两个项目合并到一个库中，因为它们似乎像我上面提到的那样紧密耦合。
答案 1 :(得分：0)
首先，您使用ProjectReference可以正确执行操作。同一解决方案中的两个项目甚至没有理由知道另一个软件包的存在。
现在，既然您在同一解决方案中拥有CL1和CL2，我想CL1需要CL2的最新版本。
考虑到前面的内容，您只需添加以下内容即可生成构建包：
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
标记，MSBuild会将其更改为该包中最新版本的NuGet依赖项。