The framework resolution in hosting layer which finds the right version/location of for example Microsoft.NETCore.App framework relies solely on directory enumeration. If there's a directory with the right version number it will be selected. If the framework in that directory is somehow corrupted, the app will fail to start - there's no attempt to fallback to another version of the framework which might not be corrupted.

Based on feedback there are cases where uninstalling a framework sometimes leaves behind an empty directory. If this happens apps will fail to run, even though there's a perfectly valid version available. It's unclear what causes the empty directory.

The validation would consist of checking if the framework's .deps.json is present (the host will fail to load such framework anyway). If the file is not there, host will ignore the framework and move on to the next candidate version - effectively behaving as if that framework doesn't exist.

This change of behavior would apply to all framework resolution functionality, so framework resolution for running apps, component loading/hosting, dotnet --info and similar enumeration APIs.

It might make sense to apply similar logic to SDK versions, in that case the presence of dotnet.dll might used as the check (since host requires that file to exist in order to run any SDK commands).

Note that this is "a change" in that there will be cases where apps failed to run and they will run but on a different version. This sounds like a positive change (just wanted to be explicit about it).

The performance impact of this change should be negligible (if any at all).

This has been already discussed in multiple places: #46128 (comment) and dotnet/sdk#15021 (comment).

Similar validation is also part of the SDK CLI proposal in dotnet/sdk#15021