AppContext.TargetFrameworkName differs between CoreRT and CoreCLR

[danmoseley]

dotnet/coreclr#13266 (review)

In CoreCLR, AppContext.TargetFrameworkName will always return null. On CoreRT/ProjectN, it will return attribute value from main exe https://github.com/dotnet/corert/blob/ff7eba504516fa0bc0a50357ad559c19b45d1d51/src/System.Private.CoreLib/src/System/AppContext.cs#L45

If we are OK with updating CoreCLR, we return return Assembly.GetEntryAssembly()?.GetCustomAttribute<TargetFrameworkAttribute>()?.FrameworkName; from AppDomainSetup.TargetFrameworkName

this will cause AppContext to parse ".NETCoreApp,Version=v2.0" and have an identifier and version instead of empty/null as it currently has and I don't know what that will do downstream.

[danmoseley]

@AlexGhiondea is this a type you have context on? It's the Core equivalent of Quirking? Should we take this change?

[clairernovotny]

This would be very useful, as there's no current reliable way at runtime to get the currently executing framework and version.

Created a new issue for this https://github.com/dotnet/corefx/issues/23197

[AlexGhiondea]

@danmosemsft the AppContext type is primarily used for quirking but has also a few other uses.

On CoreCLR we don't return null. We actually look at AppDomain.CurrentDomain.SetupInformation.TargetFrameworkName.

On CoreCLR I am not sure we want to read the value from the main exe as a) there might not be an entry assembly and b) the host can choose to put a different TFM on the default AppDomain.

/cc @jkotas

[jkotas]

We should return value from the TargetFrameworkName attribute in CoreCLR, I think. It is one line change - copy the implementation from CoreRT:

        public static string TargetFrameworkName => Assembly.GetEntryAssembly()?.GetCustomAttribute<TargetFrameworkAttribute>()?.FrameworkName;

[Anipik]

@jkotas I tried this change. But still the value being returned in the Corefx Tests is null. Currently Debugging to get more info

[danmoseley]

This is because xunit.console.netcore.exe is the entrypoint assembly for your test and it is missing the attribute. I assume it does work when you do "dotnet.exe myapp.dll" as myapp.dll is the entrypoint assembly and should have it.
For testing purposes I would either update the xunit exe's or better still use RemoteInvoke(), adding the TargetFrameworkAttribute manually into https://github.com/dotnet/corefx/blob/master/src/Common/tests/System/Diagnostics/RemoteExecutorConsoleApp/AssemblyAttributes.cs if you need to