I think that these two paragraphs conflict with each other:

We will use the same mechanism for determining installed SDKs and runtimes as the dotnet --info command, as differing information on installed SDKs between these two commands would be confusing for users. As a result we will use APIs provided by host fxr to determine what SDKs and runtimes are installed.

As the current implementation of the dotnet --info command determines installed bundles based only on directories being present, it is possible for it to wrongly report that a bundle exists. We will mitigate this issue by adding some further sanity checking to ensure that a given bundle is present, for example, by ensuring that the bundle's directory is not empty.

I think dotnet hosts (and dotnet --info) could be smarter without losing performance, for example if the framework is Microsoft.NETCore.App then it could verify that the Microsoft.NETCore.App.deps.json file exists instead of checking that the directory exists.

@vitek-karas @sfoslund In WiX, we are working with @japarson and @MSLukeWest to detect whether a specific runtime is currently installed on the machine. Unlike dotnet/runtime#36479, we really are trying to answer the question "is the runtime installed?" and not the question "Will application requiring framework XYZ run on this machine?". I believe that the SDK here in this issue is also interested in "is the runtime installed?".

Like I mentioned in the comment above, the current spec disagrees with itself. Either the SDK in this new command "will use the same mechanism for determining installed SDKs and runtimes as the dotnet --info command" or it won't. Mitigating the issue of "wrongly" reporting that bundle is installed by verifying the directory is not empty will cause it to no longer agree with the dotnet --info command.

In dotnet/runtime#46128, it sounded like there was internal discussions about this. Like I said there, I think that matching dotnet --info command (and therefore matching what will actually be used when running an application) should be the goal. I am interested to know what the .NET team is thinking on this. I think it would be beneficial to the .NET ecosystem if dotnet.exe, the SDK, and WiX can all agree when a runtime or SDK is "installed".

I absolutely agree that the behavior needs to be consistent. I think that's the main concern - any additional checks we perform on the installed frameworks (to make sure they're really there) will be a perf cost on almost every application launch. That's obviously a rather touchy subject...

Just curious what's your thoughts @rseanhall on the necessity to "validate" frameworks. We have seen cases of empty folders (which cause failures), so that's probably the most likely candidate for validation - simply make sure there's at least something in that folder. I don't think we've seen cases of any other corruption (like most files there, but only some missing and so on).

@vitek-karas What did you think about what I said in my initial comment?

I think dotnet hosts (and dotnet --info) could be smarter without losing performance, for example if the framework is Microsoft.NETCore.App then it could verify that the Microsoft.NETCore.App.deps.json file exists instead of checking that the directory exists.

There will always be "some" perf hit - because currently the code doesn't do a "Exists" check, it does directory enumeration (it needs to in order to implement all of the roll-forward capabilities). So any additional check on top of what directory enumeration returns will be "more work". In theory you're right that the .deps.json check will eventually happen anyway already, but unfortunately that's much later on - not during framework resolution.

Currently the perf impact of this would be hardly noticeable - since the host does LOT of file checks in the hostpolicy phase. Hopefully we will be able to get rid of this one day - so I don't want to sign up to a behavior which would mandate more file checks.

That said - maybe we could merge this with the version resolution and only perform the check when we actually consider the version as viable - that should cut down the number of checks to low single digits at worst.

I personally also prefer something like the check for .deps.json - this would fix two cases - empty directory, and also "random files there, which are not .NET Core at all".

These appear to be directory checks during framework resolution:

https://github.com/dotnet/runtime/blob/1daa25753f5824acb1f67f306ff5abf3a3daebeb/src/installer/corehost/cli/fxr/fx_resolver.cpp#L229

https://github.com/dotnet/runtime/blob/1daa25753f5824acb1f67f306ff5abf3a3daebeb/src/installer/corehost/cli/fxr/fx_resolver.cpp#L256

You're right - that code is just... oh well. The first one is not that interesting (that's only for basically disable roll-forward which is rarely used), the second one is the interesting one. I have no idea why we do directory check there, since the value we use come directly from directory enumeration... https://github.com/dotnet/runtime/blob/1daa25753f5824acb1f67f306ff5abf3a3daebeb/src/installer/corehost/cli/fxr/fx_resolver.cpp#L240

In that case you're absolutely right - just replacing that check with the .deps.json check would basically solve this.

Implementation has been finished with #16141