不同机器上的相同解决方案产生不同的 Nuget 包输出答案

【问题标题】：Same solution on different machines producing different Nuget package output不同机器上的相同解决方案产生不同的 Nuget 包输出
【发布时间】：2023-01-25 03:33:14
【问题描述】：

我需要帮助。

我的项目最近从 .NET Framework 4.8 迁移到 NET 6。我们提升和编译了所有内容，包括从 packages.config 到 PackageReference 的迁移。

这个项目有点独特，因为它有：

可以连接到 Internet 的外向 Git 存储库
离线的私有 Git 存储库
这意味着我们有两个构建，一个用于每个存储库。为此，我们必须将代码和 Nuget 包从面向外部的 Git 存储库复制到私有 Git 存储库。显然，我们只想复制所需的 Nuget 包，因为一些包已经存在于使用私有 Git 存储库的系统上（例如，NET 6 包、DevExpress 包等）。

这就是问题所在。

当我在笔记本电脑上从 Visual Studio 构建解决方案时，全局包文件夹包含204包裹。当我在我们的公共构建系统上使用 Visual Studio 中的完全相同的解决方案时，全局包文件夹包含125包。无论面向外的系统如何，包裹总数应该是相同的，为了我的生活，我无法弄清楚为什么会发生这种情况或如何解决它。

我们在解决方案文件夹中有一个 NuGet.config 文件（内容如下）。我使用启用了诊断输出的 Visual Studio 进行构建，并验证了在我的笔记本电脑和公共构建系统之间引用了完全相同的 NuGet 配置文件并且具有相同的内容。这会让我相信在公共构建系统上安装了从其安装位置引用的软件（也许是 Visual Studio 组件？），但我的笔记本电脑不得不从其中一个包源中提取它们。我根本不知道它还能是什么，但我看不出这方面有什么不同。

谁能建议要调查的事情？

这是我们本地的 NuGet.config 文件内容：
```
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="globalPackagesFolder" value=".\packages" />
    <add key="dependencyVersion" value="Highest" />
  </config>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
  <packageRestore>
    <clear />
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <bindingRedirects>
    <clear />
    <add key="skip" value="False" />
  </bindingRedirects>
  <packageManagement>
    <clear />
    <add key="format" value="1" />
    <add key="disabled" value="False" />
  </packageManagement>
</configuration>
```

【问题讨论】：

标签： nuget nuget-package visual-studio-2022 nuget-restore nuget-config

【解决方案1】：

（我知道这不是答案，但评论太长了......希望它能随着我们了解更多而发展）

关于在哪里寻找差异的几个想法：

在每个项目的 obj 文件夹中找到 project.assets.json 文件并在构建之间进行比较。这将显示 NuGet 生成的还原图中的任何差异。
使用 /bl 标志从每个构建生成二进制日志 (binlog)（例如 dotnet build -bl 或 mbuild /bl，具体取决于您的构建）。使用 https://msbuildlog.com/ 读取二进制日志。您可以在每个项目构建中找到参考，并比较它们（更多手动，但可以对每组参考进行排序，然后在文本编辑器中复制和比较）。这可能有助于显示某些引用是否来自安装位置。一个起点可能是搜索 $rar（这是 $task ResolveAssemblyReferences 的快捷方式），然后查看不同的 OutputItems，展开并排序。
比较在命令行和 Visual Studio 中构建的结果。如果 VS 正在做一些干扰或更改构建的事情，这可以帮助隔离。

【讨论】：