What is the function of "nugetPackages" in .nx-dotnet.rc.json?

[Tungsten78]

TLDR; why is this file important?

When using the nuget-reference generator, the package is added to both the target project (.csproj) and this file.

Initially, after having used the application generator with type webapi, "nugetPackages" is empty despite containing package references:

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="7.0.2" />
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.4.0" />
  </ItemGroup>

Using sync looks reconcile this by scrubbing all csproj files.

[AgentEnder]

We track packages here as a way of enforcing single version principle, which is a concept and practice that the team at Nx and Nx users tend to favor.

For the use in nx-dotnet, this issue may clear up some of the confusion: #562

[bcallaghan-et]

Nx has a "single version policy" by default to ensure that (in a JS workspace), all projects use the same versions of npm packages. We wanted to adopt a similar policy for .NET projects contained within an Nx workspace. However, .NET requires that all packages used by a given project must be listed in that project's .csproj file. The solution we reached was to create a separate file, .nx-dotnet.rc.json, which contains a full list of all packages installed in all projects, along with the version number of those packages. The first time you install a package via nx-dotnet, it asks for the version number and saves it to that file. On subsequent installs to other projects, nx-dotnet pulls the version from .nx-dotnet.rc.json, to ensure that all projects use the same version. This file is only used by nx-dotnet, and not by Nx or .NET themselves.

You have discovered a rather interesting bug in this approach. nx-dotnet can only save the versions for packages that were installed through its generators. The two packages in your example were pre-installed by the .NET template you chose. Thus, nx-dotnet didn't know to save them to its config file. Similarly, the config file won't contain any packages that were installed through the dotnet CLI or through Visual Studio.

One alternative we are considering is to use Central Package Management, a native .NET feature for accomplishing the same goal. Instead of the .nx-dotnet.rc.json file, we would have a Directory.Packages.props file that contains the same information. However, this new format would be directly supported by the .NET SDK and by Visual Studio; any new packages added through those tools would automatically update the root config. This feature is being tracked by #562.

[Tungsten78]

Thank you both.

So it's clear what we're trying to do, but I'm trying to understand from the app's point of view what the recourse would be the file were to fall out of sync.

AFAIK,

• .NET build will balk if it encounters mismatches in a dependency chain.
• outside of this, the principle violation (while important) wouldn't pose any immediate issues would it?

Is there any benefit to having the generators force sync in certain situations? or perhaps a dependency of restore?

[AgentEnder]

There shouldn't be an immediate issue so long as things still build. Generally speaking, it's almost akin to a formatting or lint error...

Sync generator is not super efficient IIRC, I wouldn't want to force it for two reasons.

• for large workspace e.g. >100 or so projects, I could see it being slow
• some folks just take issue with single version principle

[AgentEnder]

That said, perhaps a good improvement would be adding a --project option to sync and running it automatically for the newly generated project.