Open forki opened 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
).
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.
cc @KathleenDollard
@KathleenDollard @livarcocc is there some official recommendations on if people should use the global.json at all?
Possibly related: https://github.com/dotnet/sdk/issues/10603
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.
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]
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
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
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@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.
➜ 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)
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.
/run copilot.implement.and.ship.feature
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.
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.
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 functionalityAs 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.