Design capability APIs

[terrajobst]

We need to list & drive a design of capability APIs as explained here:

https://github.com/dotnet/designs/blob/master/accepted/compat-pack/compat-pack.md#non-goals

Instead of writing code like this:

private static string GetLoggingPath()
{
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
    {
        using (var key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam\AssetManagement"))
        {
            if (key?.GetValue("LoggingDirectoryPath") is string configuredPath)
                return configuredPath;
        }
    }

    var appDataPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
    return Path.Combine(appDataPath, "Fabrikam", "AssetManagement", "Logging");
}

we should be promoting code like this:

private static string GetLoggingPath()
{
    if (Registry.IsSupported)
    {
        using (var key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam\AssetManagement"))
        {
            if (key?.GetValue("LoggingDirectoryPath") is string configuredPath)
                return configuredPath;
        }
    }

    var appDataPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
    return Path.Combine(appDataPath, "Fabrikam", "AssetManagement", "Logging");
}

[JonHanna]

Perhaps relevant: #17973 Here people can "do the thing", but impacts of implementations might mean they don't want to.

[danmoseley]

Note that your first example has also the problem that it throws PNSE on UWP.

We may want to prefer a loosely typed system like IsSupported("Registry") so that we don't need to update all platforms before a new value becomes useable. AppContext/quirks seem to do this.

[terrajobst]

We may want to prefer a loosely typed system like IsSupported("Registry") so that we don't need to update all platforms before a new value becomes useable. AppContext/quirks seem to do this.

Yes, but this would require a centralized place, which I don't think we want. The registry is a great example: it doesn't ship in-box with UWP or .NET Core -- it's a NuGet package. If the support inside the package changes, we shouldn't be forced to update the runtime for that.

Having a centralized override for quirking seems desirable but I don't see how this would work. If the library returned false from its capability API overriding it to true doesn't make more stuff work IMHO. And the reverse seems nonsensical to me.

[stephentoub]

@terrajobst, are you still working on this or can it be closed?

[dakersnar]

@terrajobst bump on the above question

[terrajobst]

Not at this point, no