相同的解决方案在不同的机器上产生不同的 Nuget package output

Question

I need help.

My project has recently moved from .NET Framework 4.8 to.NET 6. We have everything uplifted and compiling, including the migration from packages.config to PackageReference.

This project is somewhat unique in that it has:

1. An outward-facing Git repository that can connect to the inte.net
2. A private Git repository that is offline

This means we have two builds, one for each repository. To accomplish this, we have to copy the code and Nuget packages from the outward-facing Git repo to the private Git repo. Obviously, we only want to copy the Nuget packages that are required since some packages already exist on the systems that use the private Git repo (eg,.NET 6 packages, DevExpress packages, etc.).

Here's the issue.

When I build the solution from Visual Studio on my laptop, the global packages folder contains 204 packages. When I guild the exact same solution from Visual Studio on our public build system, the global packages folder contains 125 packages. The total number of packages should be the same regardless of outward-facing system, and for the life of me, I cannot figure out why this is happening or how to fix it.

We have a NuGet.config file located in the solution folder (content below). I have built using Visual Studio with Diagnostic output enabled and verified that the exact same NuGet config files are referenced and have the same content between my laptop and the public build system. This would lead me to believe that there is software (perhaps Visual Studio components?) installed on the public build system that are referenced from their installation location, but my laptop is having to pull them from one of the package sources. I simply don't know what else it could be, but I don't see any differences in this regard.

Can anyone suggest things to investigate?

Here's our local NuGet.config file content:

<?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>

Answer 1

(I know this isn't an answer, but it's too long for a comment... hopefully it can develop as we learn more)

A couple ideas of where to look for differences:

1. Find the project.assets.json files in the obj folder for each project and compare between the builds. This will show any differences in the restore graph that NuGet is generating.
2. Generate a binary log (binlog) from each build using the /bl flag (eg do.net build -bl or mbuild /bl depending on your build). Use https://msbuildlog.com/ for reading the binlogs. You can find the references in each project build, and compare those (more manual, but each set of references can be sorted and then copied and diffed in a text editor). This might help show if some references are coming from an install location. One place to start might be to search for $rar (this is a shortcut for $task ResolveAssemblyReferences ), and look at the different OutputItems, expanded and sorted.
3. Compare results of building on the command line vs. in Visual Studio. This can help isolate if VS is doing something to interfere or change the build.

Answer 2

The problem was that the .NET 6 SDK was not installed on our public build system. Let me see if I can explain.

Up until November 2022, we were only targeting the .NET Framework, so we never had a reason to install the .NET SDK when upgrading Visual Studio. In late November, some of the members of our team began uplifting our solution to .NET 6 using the Visual Studio version we already had installed (17.2.9, I believe). Obviously, they had to have the .NET 6 SDK installed on their local systems in order to build locally. It is unclear whether they updated their Visual Studio version locally or downloaded the .NET 6 SDK directly.

In any case, after the holidays, I began working to update our build system. One of the first things I did was update Visual Studio to v17.4.4 on my laptop, our public build system, and our various offline systems. I made sure to check the .NET SDK option on the Individual Components page. I assumed this installed the .NET 6 SDK on these systems.

I was wrong.

Visual Studio 17.4.4 delivers the .NET 7 SDK, but we are specifically targeting .NET 6 because it is the long-term support version.

At some point in my efforts, I had apparently downloaded and installed the .NET 6 SDK on my laptop, but failed to make the connection that this needed to be done across the other systems as well.

Thus, building on my laptop pulled the .NET 6 packages correctly (204). On the public build system (which did not have the .NET 6 SDK), building resulted in a cadre of packages being pulled from the inte.net and the local .NET 7 SDK (125).

Once I installed the .NET 6 SDK on the public build system, it pulled the 204 packages that I was expecting.

A huge shoutout to Jimmy for his suggestions. I hope that between his answer and this one, others might find benefit.