Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Should dotnet --info surface a global.json in the mix?
See original GitHub issueSteps to reproduce
- Create a project with a global.json in a parent folder that sets the SDK.
- Dr. Frankenstein on your creation 👹 for months (and forget the global.json is up in the parent folders somewhere).
- Prep to upgrade the project: Install a newer SDK.
- 😢 Can’t figure out why tools aren’t upgraded for the project.
Expected behavior
dotnet --info tells you that an intervening global.json (with its path) is holding back the SDK.
Actual behavior
😵 Can’t figure out why the SDK is stuck on an older version.
Source
Slack chat: This just happened to a dev today, and it happened to me once several months ago.
I understand if u lean “DNF” on this suggestion; however, consider that if it would be easy to surface that the SDK is fixed by a global.json in the output of dotnet --info, WHY NOT??? I speculate it would save many devs from some pain.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:4
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Good idea!
We are looking into a mine re-haul of dotnet --info on https://github.com/dotnet/cli/issues/7926.
I am closing this issue in favor of that one that has traction.
cc @KathleenDollard to add the idea of indicating that the SDK version is coming from a global.json.