Pinning the version of dotnet-format

[zubivan]

Hello all,

Since dotnet-format is now a part of the SDK it potentially poses an issue when upgrading the sdk might potentially change the behaviour of the tool, e.g. new rules are pickled up or introduced.

Is there a way to pin the version of the tool now? It's especially important in case of the CI/CD environment in multi-version product companies where reproducible builds are important (think patch releases for older builds).

Before the tool was moved to the sdk one could pin it in such a way:

Add .config/dotnet-tools.json in the root of your repository with the following contents

{
  "version": 1,
  "isRoot": true,
  "tools": {
    "dotnet-format": {
      "version": "5.1.250801",
      "commands": [
        "dotnet-format"
      ]
    }
  }
}

During the CI run something like

dotnet tool restore
dotnet tool run dotnet-format $ARGS

Is there a way to achieve similar behaviour with the current setup?

Thanks!

[JoeRobich]

The method you describe is also used by Roslyn to install the tool locally and invoke it in CI. Are you seeing issues with that setup?

[zubivan]

Hey @JoeRobich, thanks for your suggestion. I gave it a shot, however it looks like dotnet-format is no longer published separately to nuget. The latest version here https://www.nuget.org/packages/dotnet-format/ is 5.1.250801.

Running dotnet tool restore on that version gives me:

dotnet tool restore
...\4fvknh1i.wuz\restore.csproj : error NU1102: Unable to find package dotnet-format with version (= 6.3.317301)
...\restore.csproj : error NU1102:   - Found 14 version(s) in Nexus Rnd Nuget Group [ Nearest version: 5.1.250801 ]

Am I missing something?

Thanks.

[JoeRobich]

We do not plan to make any additional releases on NuGet.org. You can reference our development builds by adding the appropriate dotnet feed to your repo's nuget.config.

6.x builds - https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json 7.x builds - https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json

[zubivan]

@JoeRobich thanks! How stable is the content in those feeds? Can it be relied on in the CI/CD setup (assuming appropriate package caching on my side)?

Is there a good reason why dotnet-format can't be released as a separate (maybe even standalone) dotnet tool? Is it a reliance on the tooling shipped with the sdk that makes it not feasible or something else?

[ZimmerA]

I can second the requirement for this feature. It can't be expected that everyone has the same version of .net installed in an open source project. This can lead to confusing CI results that are annoying to fix.

[virzak]

We do not plan to make any additional releases on NuGet.org

Why not? That means that every year every developer is expected to change the feed if they want it pinned. It also makes it tedious checking for updates. It is totally understandable that some updates won't be perfect and tagging it as prerelease is a possibility. libraries like Microsoft/CsWin32 haven't been perfect, but used this model.

It just doesn't make sense to use a secondary feed when the primary is stuck on an outdated version.

[DennisDyallo]

Running dotnet format defaults to latest version. The latest version doesn't work for my scenario as I'm stuck on net6.0