Show friendly names for target framework in project properties

[dsplaisted]

The project properties page looks like it's using the target framework identifier for the Target Framework dropdown for .NET Core and .NET Standard. It should be using a friendlier name instead.

For example, instead of .NETStandard 1.4, it should show .NET Standard 1.4. Instead of .NETCoreApp 1.1 it should show .NET Core 1.1.

This is probably related to #795, but could be fixed separately for the hard-coded list.

[panopticoncentral]

@tannergooding Stealing this because it is related to #1672, let me know if you disagree.

[abpiskunov]

Check this PR #1880 , you might be interested in ITargetFrameworkProvider component...

[davkean]

@abpiskunov I don't want a dependency on NuGet in paths that have never had it before, as mentioned a few times, I want this to come from either the build or a VS service such as IVsFrameworkMultiTargeting. We should not require NuGet to be serviced to add a new framework version.

[abpiskunov]

You already depend on nuget.visualstudio interop assembly and only nuget knows how correctly resolve/compare/check for compatibility for all types of target frameworks. Matching version of nuget assemblies always checked in in Vs in each release/update. I understand that you want simpler way to get data from build etc, that probably could be achieved, but how would you compare targets later? Especially if later you could get short or full names from other sources ? Why not use some API to be more flexible and independent? Thanks, Anton On Mar 28, 2017, at 5:30 PM, David Kean <notifications@github.com<mailto:notifications@github.com>> wrote: @abpiskunov<https://github.com/abpiskunov> I don't want a dependency on NuGet in paths that have never had it before, as mentioned a few times, I want this to come from either the build or a VS service such as IVsFrameworkMultiTargeting. We should not require NuGet to be serviced to add a new framework version. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1595 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABhLG6-dJ6jDDeqlyaR59brbgsKV7J-Uks5rqaY5gaJpZM4MG-42>.

[davkean]

These dlls do not depend on NuGet - this runs in the legacy project system, I'm not loading NuGet just to get data that VS already should know about - especially as it already knows about all other platforms except .NET Core/.NET Standard.

[abpiskunov]

I thought this change will be in roslyn project system. In any case, my point is that as you said newer frameworks are not supported by vs api, and when we are talking about "supported" what it really means? Can those Api answer the question : "does target A support target B"? Nuget has pretty complex logic to answer this question - vs api , i am not sure they can ... need to see how it is implemented. I am referring to nuget since we already had multiple discussions in dev14, and that was the consensus for xproj ... Thanks, Anton On Mar 28, 2017, at 6:37 PM, David Kean <notifications@github.com<mailto:notifications@github.com>> wrote: These dlls do not depend on NuGet - this runs in the legacy project system, I'm not loading NuGet just to get data that VS already should know about - especially as it already knows about all other platforms except .NET Core/.NET Standard. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1595 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABhLG0mhXSfwvlmjZAKiKGCxnQxnCvHkks5rqbXbgaJpZM4MG-42>.

[davkean]

This change lives in a dll that is shared between many projects. NuGet also isn't consulted for TFM compatibility for project references or getting the right output from the project. NuGet isn't is the right place for this code - it's not even involved in lots of these code paths, it should be consuming the VS data TFM data not the reverse.

[srivatsn]

Actually NuGet is consulted for project reference compatibility in the SDK. However, I agree that NuGet is not the right place for this logic. It should probably be extracted out into some common API that's unrelated to NuGet and then we should replace all uses of NuGet for compat check with that API.

[srivatsn]

Roslyn also uses the NuGet API for the Add using fixer and that needs to be fixed as well.

[panopticoncentral]

Fixed with #795