You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has been a long-standing problem. It came up when .NET 6.0 previews became available and again with .NET 7.0. Each time we fixed it by adding the new version to the code. It will surface again when .NET 8.0 previews are installed. The worst thing about this is error is that it appears whenever we run the console on a machine, even if the tests don't reference the non-supported runtime.
We should change the way we handle this situation entirely. If an install directory contains a runtime we don't recognize, we should simply ignore it. The engine will no longer recognize that version (e.g. 8.0) as an installed runtime. An error will only appear if we try to run tests built against that new runtime, saying it is not yet supported.
In order to facilitate debugging, we should log an error in the internal trace when such a runtime is discovered.
Note that for 4.0, I"m hoping to move away from the complex analysis of the registry and the install directories and to just rely on "dotnet --list-runtimes."
The text was updated successfully, but these errors were encountered:
This has been a long-standing problem. It came up when .NET 6.0 previews became available and again with .NET 7.0. Each time we fixed it by adding the new version to the code. It will surface again when .NET 8.0 previews are installed. The worst thing about this is error is that it appears whenever we run the console on a machine, even if the tests don't reference the non-supported runtime.
We should change the way we handle this situation entirely. If an install directory contains a runtime we don't recognize, we should simply ignore it. The engine will no longer recognize that version (e.g. 8.0) as an installed runtime. An error will only appear if we try to run tests built against that new runtime, saying it is not yet supported.
In order to facilitate debugging, we should log an error in the internal trace when such a runtime is discovered.
Note that for 4.0, I"m hoping to move away from the complex analysis of the registry and the install directories and to just rely on "dotnet --list-runtimes."
The text was updated successfully, but these errors were encountered: