Add new API to expose framework information about the current app

[vitek-karas]

Add a public API which would expose information about the frameworks the app is using:

• The framework name
• The framework version
• The location of the framework (directory path)
• Maybe: Roll forward information - what version the app asked for (and what it ended up getting as above)

This should work for both framework-dependent and self-contained apps. Self-contained apps include frameworks in them, starting with 3.1 the SDK writes this information into the .runtimeconfig.json and the host reads it. Such frameworks would not have location - we could return either null for location or the path to the app. (I would prefer null to make it easy to distinguish between the framework-dependent and self-contained cases).

The API may look like this (needs more work):

namespace System.Runtime.InteropServices
{
    // New class - represents information about one framework
    public class FrameworkInformation
    {
        public string Name { get; }
        public Version Version { get; }
        public string Location { get; }
        public Version RequestedVersion { get; } // maybe?
    }

   public static class RuntimeInformation
   {
       public static IEnumerable<FrameworkInformation> GetFrameworksInformation();
   }
}

[vitek-karas]

#644 will expose frameworks for framework-dependent apps to the runtime (and can be used to feed the above API).
We could modify the behavior to also include frameworks for self-contained.

/cc @swaroop-sridhar

[DamianEdwards]

This would be very useful for cases where the app wants to emit this information for diagnostics purposes at runtime, e.g. in a log message at startup, in the footer of a web site, in a diagnostics API response payload, etc.

[AaronRobinsonMSFT]

@vitek-karas Would this API align with Mono? I am not sure how closely aligned the Mono hosting scenarios are with CoreCLR, but seems like any API should be able to handle both runtimes.

[vitek-karas]

The current thinking about running console apps (or similar) on Mono will have it using the exact same hosting layers as CoreCLR - so this would "just work" if Mono propagates runtime properties from the hosting layer to the AppContext.GetData (and if it doesn't we should fix that).

Other scenarios for Mono are obviously a bit trickier - as there's no notion of frameworks really in those cases. That said the hosting layers are completely different as well. In those cases I think it would make sense for this API to report one framework only which would describe the "runtime and framework" used.

That still leaves scenarios where the runtime is hosted directly without hosting layers. In those cases the API would return empty list. Or the host could still populate the right runtime property (assuming we pick that implementation, but that's very likely) and let it report whatever it wants.

So in general I think the API will make lot of sense on most configurations and the places where it doesn't make sense, it can return empty enumeration. I agree that we should try to have APIs which work everywhere, but I don't think it needs to be 100% (but I'll leave that call to the API review committee).

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.