PowerShell: PowerShell 7 distributed via dotnet tool broken by upgrade to .NET 8
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues.
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
With today’s release of .NET 8, I updated Visual Studio 2022 to install .NET 8 and removed the .NET 7 runtime. After the suggested reboot, PowerShell 7 was broken, and reinstalling it didn’t help:
Uninstalling the dotnet tool
distributed version and using the WinGet
distributed version was an effective workaround.
Expected behavior
PowerShell works.
Actual behavior
PowerShell crashes on launch.
Error details
No response
Environment data
Name Value
---- -----
PSVersion 7.3.9
PSEdition Core
GitCommitId 7.3.9
OS Microsoft Windows 10.0.22631
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Visuals
No response
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Comments: 15 (3 by maintainers)
That’s because you’re using the root user. It’s private to the account you’re using (and I’d strongly disrecommend using the root user as your interactive account).
“Global” means “not tied to a specific project”, not “global to the machine”. That’s also true on Windows, as installing a global tool places it into your user folder. Here is an example that illustrates that (and also shows how a tool that needs a specific runtime should properly surface that requirement, rather than just outright crashing):
Note where the executable is located.
Looking back at the original error message it suggests that it finds and uses the 8.0 runtime but fails to find a suitable Microsoft.Management.Infrastructure assembly.
Thank you @bradwilson for reporting this! There is another workaround for it. In the pwsh.runtime.config file under $pshome, change the value of rollForwardOnNoCandidateFx from 2 to 1.
The problem isn’t that it requires .NET 7, it’s that installation via
dotnet tool
when .NET 7 isn’t installed isn’t blocked and/or indicates the .NET 7 requirement.