Allow dotnet commands to bypass the global.json version check

forki commented 5 years ago

Sometimes users or more importantly CI servers don't have the correct dotnet SDK installed. We wrote FAKE install scripts that would take care of installing the correct SDK version during the build. Unfortunately even dotnet tool requires to have exactly the specified version available. So we have chicken and egg situation. We can't download the tool that would fix the SDK version conflict since the downloader already requires the correct SDK. What I'd like to see is:

1) dotnet tool install --any-sdk-version --tool-path tools fake-cli 2) tools\fake.exe build --target Build 3) --> FAKE runs and installs the correct SDK with it's own functionality

As written above 1) is already failing since dotnet tool requires the SDK version from global.json

Workaround

1) Install fake-cli package with Paket or NuGet 2) dotnet "packages\build\Fake-Cli\tools\netcoreapp2.1\any\fake-cli.dll" build --target Build

Note how this dotnet command does not requirer the correct SDK version.

matthid commented 5 years ago

Install fake-cli package with Paket or NuGet

I haven't tested it but I'd say dotnet nuget probably fails as well. Therefore only nuget.exe is an option.

Regarding the cli option: I'd suggest --ignore-global-json or something like that. And I'd suggest this option to be available for all commands (not just install).

forki commented 5 years ago

even worse:

dotnet --version

A compatible SDK version for global.json version: [2.2.300] from [D:\...\global.json] was not found Did you mean to run dotnet SDK commands? Please install dotnet SDK from: https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409

you can't even get the version of what would be available.

livarcocc commented 5 years ago

cc @KathleenDollard

forki commented 5 years ago

@KathleenDollard @livarcocc is there some official recommendations on if people should use the global.json at all?

AnthonyMastrean commented 4 years ago

mid-kid commented 3 years ago

The source-built SDK does something to bypass the global.json files across the board, but I can't for the life of me figure out what.

dignite commented 1 year ago

We had a few dotnet commands that were allowed to run a different SDK than the one specified in global.json, and used the following work around

mv global.json disabled-global.json
[Some dotnet command allowed any sdk, for example dotnet tool install]
mv disabled-global.json global.json
[Some dotnet command not allowed any sdk, for example dotnet build]

purijatin commented 1 year ago

We were facing the same problem. Where the global.json (which came inbuilt with the image of the runner) was creating problems. global.json was pointing to dotnet 5 and our project was using dotnet 6.

Removing global.json fixed the issue for us.

- task: UseDotNet@2
  displayName: Use .NET 6.0
  continueOnError: true
  inputs:
    packageType: 'sdk'
    version: '6.0.x'
    #includePreviewVersions: true
    performMultiLevelLookup: true

- task: PowerShell@2
  displayName: Remove global.json
  inputs:
    targetType: 'inline'
    script: |
      cd C:\
      rm global.json

smoothdeveloper commented 9 months ago

I haven't tested it but I'd say dotnet nuget probably fails as well. Therefore only nuget.exe is an option.

this still fails today, in a repository with dotnet sdk 7 fixed, and me having 7 (but lesser than pinned version) and some 8 version installed, even issuing --roll-forward Major isn't addressing the issue.

I see two things to improve the situation in whole eco-system:

dotnet sdk analyzer that warns if repository uses a sdk version which is not among the first release of the major version, or there isn't a textual reason adorned to the sdk version in the global.json, this encourage project maintainers to only update the minimum sdk version for a reason, they'd write a text explaining "updated to 6.xxxx because of bug in embedded resource handling", etc.
dotnet command line adopting a much more lenient style of validating and issuing the commands (at large), by default, when run interactively: allow user to interact with the command and prompt for actionable solutions

baronfel commented 9 months ago

@smoothdeveloper can you try setting the DOTNET_ROLL_FORWARD environment variable to LatestMajor. Per the roll forward docs, Major will only use 8.0 runtimes if no 7.0 runtimes are present.

The SDK team is working on options for running already installed dotnet tools with a different roll forward policy, and for installing them with a roll forward policy different than the tool author intended. That would hopefully make it easier/more consistent to end users to do this kind of mixing.

smoothdeveloper commented 9 months ago

➜  FSharp.Analyzers.SDK git:(master) ✗ mv foo.global.json global.json
➜  FSharp.Analyzers.SDK git:(master) export DOTNET_ROLL_FORWARD=LatestMajor
➜  FSharp.Analyzers.SDK git:(master) dotnet fsi build.fsx

The command could not be loaded, possibly because:

You intended to execute a .NET application: The application 'fsi' does not exist.

You intended to execute a .NET SDK command: A compatible .NET SDK was not found.

Requested SDK version: 7.0.400 global.json file: /Users/gauthiersegay/dev/src/github.com/ionide/FSharp.Analyzers.SDK/global.json

Installed SDKs: 6.0.400 [/usr/local/share/dotnet/sdk] 6.0.401 [/usr/local/share/dotnet/sdk] 6.0.405 [/usr/local/share/dotnet/sdk] 7.0.100-preview.7.22377.5 [/usr/local/share/dotnet/sdk] 7.0.100-rc.2.22477.23 [/usr/local/share/dotnet/sdk] 7.0.102 [/usr/local/share/dotnet/sdk] 7.0.304 [/usr/local/share/dotnet/sdk] 8.0.100-preview.5.23303.2 [/usr/local/share/dotnet/sdk] 8.0.100-preview.6.23330.14 [/usr/local/share/dotnet/sdk] 8.0.100-rc.1.23463.5 [/usr/local/share/dotnet/sdk] 8.0.100-rc.2.23502.2 [/usr/local/share/dotnet/sdk]

Install the [7.0.400] .NET SDK or update [/Users/gauthiersegay/dev/src/github.com/ionide/FSharp.Analyzers.SDK/global.json] to match an installed SDK.

Learn about SDK resolution: https://aka.ms/dotnet/sdk-not-found
➜  FSharp.Analyzers.SDK git:(master) dotnet --roll-forward LatestMajor fsi build.fsx
The command could not be loaded, possibly because:
You intended to execute a .NET application: The application 'fsi' does not exist.
You intended to execute a .NET SDK command: A compatible .NET SDK was not found. ... (same as above)

smoothdeveloper commented 9 months ago

The SDK team is working on options for running already installed dotnet tools with a different roll forward policy, and for installing them with a roll forward policy different than the tool author intended. That would hopefully make it easier/more consistent to end users to do this kind of mixing.

@baronfel, I would suggest a mode that is replacing all those checks and just emitting warnings as it goes, ability to enable this mode in the global.json, and to interactively enable it when the command is run interactively.

smoothdeveloper commented 9 months ago

/run copilot.implement.and.ship.feature

czdietrich commented 5 months ago

Can we expect any progress here?

If built-in dotnet commands behave differently if there is a global.json file in the working directory, then there is a good reason to have a switch to bypass this behavior on-demand without the need to rename any files or alike to change the behavior.

an-dr-eas-k commented 4 months ago

I usually call dotnet build from outside the directory tree that holds the global.json file, e.g. the parent dir, then the global.json file is not considered during build.

dotnet / sdk

Allow dotnet commands to bypass the global.json version check #10311

Workaround