Consider removing this component completely

[natemcmaster]

The API provided in this package has been whittled down so much that it's no longer really useful as a standalone assembly. We can simplify our dependency graph by using .NET APIs such as AppContext.BaseDirectory and System.Runtime.InteropServices.RuntimeInformation, or making this a .Sources package instead.

[natemcmaster]

@Eilon @BrennanConroy I think this worth considering for 2.0.

[Eilon]

It seems to have a ton of downloads in even just the last 6 weeks - over 1.2 million: http://www.nuget.org/stats/packages/Microsoft.Extensions.PlatformAbstractions?groupby=Version

Is it just because we have dependencies on it from core components? If so, what are those components?

[davidfowl]

Lets just never ship an update. As @natemcmaster says, it's been replaced by the BCL APIs which are also in netstandard.

[natemcmaster]

Is it just because we have dependencies on it from core components? If so, what are those components?

Yes, I think this is more likely the case. It is used in Scaffolding, Hosting, WebSockets, MvcPrecompilation, SignalR, Logging, Localization, and probably a few others I missed in my quick GitHub search.

[hishamco]

Is that mean, there's no code change needed in this repo?!!

[muratg]

@anurse Let's sync up later on this one.

[analogrelay]

Tracking for removal:

Branches and changes made:

• Caching
• Common
• Entropy
• Hosting
• Localization
• Logging
• MusicStore
• Mvc
• Razor
• Scaffolding
• ServerTests
• SignalR
• WebSockets

Issues Identified

• Some components require netstandard1.5 in order to use Assembly.GetEntryAssembly: Hosting

[analogrelay]

First major problem is going to be Assembly.GetEntryAssembly which is only publicly exposed on .NET Standard 1.5. We cheat in PlatformAbstractions and call it with reflection since .NET Core does have this method, but if we want to get back on the path of righteousness we'll have to set some repos to a minimum of .NET Standard 1.5 (Hosting is the first I've found)

/cc @davidfowl @Eilon @muratg

[hishamco]

So that's why I asked before, Assembly.GetEntryAssembly & AppContext.TargetFrameworkName needs NET Standard 1.5

[natemcmaster]

IMO we should take this opportunity to get back on the "path of righteousness". netstandard1.3 does not accurately reflect runtime requirements for this API.

Background: reflecting out Assembly.GetEntryAssembly was introduced as a workaround during the 1.0.0 RC1 release. The API became available in 1.0.0-rc2 but we never updated our code. (see https://github.com/dotnet/corefx/issues/4146)

[Eilon]

@natemcmaster are you suggesting we bump up certain projects from netstandard1.3 to 1.5? If so, which ones, and what down-stream ones would also need to get bumped up?

We're not opposed to raising the min-reqs, but it's also not as simple as just flipping some bits, because there's obvious customer impact on this.