Remove .NETCore <3.0 as SupportedTargetFrameworks for WinForms and WPF #3438

etbyrd · 2019-07-18T22:15:57Z

The Project System needs a way to know the correct SupportedTargetFrameworks for WinForms and WPF projects so we can display the correct TFM's in the property pages.

Is it possible that this can be done on the SDK side?

dotnet/project-system#5010

cc @nguerrera

nguerrera · 2019-07-18T22:41:19Z

cc @vatsan-madhavan @rladuca

nguerrera · 2019-07-18T22:41:27Z

cc @dsplaisted

nguerrera · 2019-07-18T22:45:10Z

Today we have a static list of supported TFMs here:

https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.SupportedTargetFrameworks.props

What I'm thinking is that the WindowsDesktop SDK could override this somehow to remove the target frameworks that it doesn't support.

Simplest form of that would be to do some Removes but then I think we want no versions of .NET Standard to be supported, and then we'd have a maintenance problem when say .NETStandard 2.2 came out and wasn't yet removed.

Another way would be for WindowsDesktop SDK to remove all and have its own fixed allow-list. But then it is in the business of taking an update for every version.

Finally, we could make the list above dynamic based on whether the WindowsDesktop SDK has set certain props.

What do you all think would be best?

vatsan-madhavan · 2019-07-18T22:45:49Z

I don't understand the request for the SDK.

We already have logic for handling TFM < 3.0 && TargetFrameworkIdentifier==.NETCoreApp. What specifically is being requested here?

See _WindowsDesktopFrameworkRequiresVersion30 - currently there is a warning shown when someone tries to use WindowsDesktop SDK and sets TFM < netcoreapp3.0

vatsan-madhavan · 2019-07-18T22:47:25Z

Today we have a static list of supported TFMs here:
https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.SupportedTargetFrameworks.props
Simplest form of that would be to do some Removes but then I think we want no versions of .NET Standard to be supported, and then we'd have a maintenance problem when say .NETStandard 2.2 came out and wasn't yet removed.

Spoke too soon.. thanks for the context.

nguerrera · 2019-07-18T22:47:34Z

The request is that the list of SupportedTargetFramework: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.SupportedTargetFrameworks.props

not include target frameworks that aren't supported by windows desktop projects. VS uses these items to populate a retargeting drop-down in property pages.

vatsan-madhavan · 2019-07-18T22:57:57Z

Remove-ing these is easy, and doesn't pose maintainability problems.

<SupportedTargetFramework Include=".NETCoreApp,Version=v1.0" DisplayName=".NET Core 1.0" />
<SupportedTargetFramework Include=".NETCoreApp,Version=v1.1" DisplayName=".NET Core 1.1" />
<SupportedTargetFramework Include=".NETCoreApp,Version=v2.0" DisplayName=".NET Core 2.0" />
<SupportedTargetFramework Include=".NETCoreApp,Version=v2.1" DisplayName=".NET Core 2.1" />
<SupportedTargetFramework Include=".NETCoreApp,Version=v2.2" DisplayName=".NET Core 2.2" />

I would expect 3.0+ .NETCoreApp TFM's to be supported.

If we don't want any version of .NETStandard to be supported, is there a way we can Remove them all without having to run a Target? That would probably be the easiest thing to do... For e.g., if we could coordinate a change with dotnet/sdk and have it define @(_NetStandardSupportedTargets) in Microsoft.NET.SupportedTargetFrameworks.props, we could probably use that and easily eliminate .NET Standard TFM's.

Thoughts?

vatsan-madhavan · 2019-07-18T22:58:01Z

How come this list doesn't include .NETFramework items? Is that because SDK-style projects "work with, but don't support" .NET Framework?

nguerrera · 2019-07-18T23:42:20Z

Good question about .NET Framework. I suppose that is why. @davkean?

nguerrera · 2019-07-18T23:54:26Z

I think I like where you were going we could have this:

<SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v1.0" DisplayName=".NET Core 1.0" />
<SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v1.1" DisplayName=".NET Core 1.1" />
<SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v2.0" DisplayName=".NET Core 2.0" />
<!-- etc. -->

<SupportedNETStandardTargetFramework Include=".NETStandard,Version=1.0" DisplayName=".NET Standard 1.0" />
<! -- etc. -->

<SupportedTargetFramework Include="@(SupportedNETCoreTargetFramework);@(SupportedNETStandardTargetFramework)" />

Another idea would be to set the metadata with the TargetFrameworkIdentifier and Version separated. I think this would let you do the removes with conditions that match all .NET Standard, though I have to check what is possible in evaluation here. We can't use a target for any of this.

vatsan-madhavan · 2019-07-19T00:10:17Z

I don't think metadata will work - though I wish that it did.

   <!-- Microsoft.NET.Build.Tasks/targets/Microsoft.NET.SupportedTargetFrameworks.props --> 

    <!-- .NET Standard -->
    <ItemGroup>
        <SupportedTargetFramework Include=".NETStandard,Version=v1.0" DisplayName=".NET Standard 1.0" TargetFrameworkIdentifier=".NETStandard" />
        <SupportedTargetFramework Include=".NETStandard,Version=v1.1" DisplayName=".NET Standard 1.1" TargetFrameworkIdentifier=".NETStandard" />
        <SupportedTargetFramework Include=".NETStandard,Version=v1.2" DisplayName=".NET Standard 1.2" TargetFrameworkIdentifier=".NETStandard" />
        <SupportedTargetFramework Include=".NETStandard,Version=v1.3" DisplayName=".NET Standard 1.3" TargetFrameworkIdentifier=".NETStandard" />
        <SupportedTargetFramework Include=".NETStandard,Version=v1.4" DisplayName=".NET Standard 1.4" TargetFrameworkIdentifier=".NETStandard" />
        <SupportedTargetFramework Include=".NETStandard,Version=v1.5" DisplayName=".NET Standard 1.5" TargetFrameworkIdentifier=".NETStandard" />
        <SupportedTargetFramework Include=".NETStandard,Version=v1.6" DisplayName=".NET Standard 1.6" TargetFrameworkIdentifier=".NETStandard" />
        <SupportedTargetFramework Include=".NETStandard,Version=v2.0" DisplayName=".NET Standard 2.0" TargetFrameworkIdentifier=".NETStandard" />
        <SupportedTargetFramework Include=".NETStandard,Version=v2.1" DisplayName=".NET Standard 2.1" TargetFrameworkIdentifier=".NETStandard" />
    </ItemGroup>

<!-- WindowsDesktop SDK props -->
  <ItemGroup>
    <SupportedTargetFramework Remove="@(SupportedTargetFramework0)" Condition="'%(TargetFrameworkIdentifier)'=='.NETStandard'" />
  </ItemGroup>

error MSB4191: The reference to custom metadata "TargetFrameworkIdentifier" at position 1 is not allowed in this condition "'%(SupportedTargetFramework.TargetFrameworkIdentifier)'=='.NETStandard'"

vatsan-madhavan · 2019-07-19T00:13:20Z

We should probably do this, IMO, like you described above:

Microsoft.NET.Build.Tasks/targets/Microsoft.NET.SupportedTargetFrameworks.props

    <!-- .NET Core -->
    <ItemGroup>
        <SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v1.0" DisplayName=".NET Core 1.0" />
        <SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v1.1" DisplayName=".NET Core 1.1" />
        <SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v2.0" DisplayName=".NET Core 2.0" />
        <SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v2.1" DisplayName=".NET Core 2.1" />
        <SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v2.2" DisplayName=".NET Core 2.2" />
        <SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v3.0" DisplayName=".NET Core 3.0" />
    </ItemGroup>

    <!-- .NET Standard -->
    <ItemGroup>
        <SupportedNETtandardTargetFramework Include=".NETStandard,Version=v1.0" DisplayName=".NET Standard 1.0" />
        <SupportedNETtandardTargetFramework Include=".NETStandard,Version=v1.1" DisplayName=".NET Standard 1.1" />
        <SupportedNETtandardTargetFramework Include=".NETStandard,Version=v1.2" DisplayName=".NET Standard 1.2" />
        <SupportedNETtandardTargetFramework Include=".NETStandard,Version=v1.3" DisplayName=".NET Standard 1.3" />
        <SupportedNETtandardTargetFramework Include=".NETStandard,Version=v1.4" DisplayName=".NET Standard 1.4" />
        <SupportedNETtandardTargetFramework Include=".NETStandard,Version=v1.5" DisplayName=".NET Standard 1.5" />
        <SupportedNETtandardTargetFramework Include=".NETStandard,Version=v1.6" DisplayName=".NET Standard 1.6" />
        <SupportedNETtandardTargetFramework Include=".NETStandard,Version=v2.0" DisplayName=".NET Standard 2.0" />
        <SupportedNETtandardTargetFramework Include=".NETStandard,Version=v2.1" DisplayName=".NET Standard 2.1" />
    </ItemGroup>


    <ItemGroup>
        <SupportedTargetFramework Include="@(SupportedNETCoreAppTargetFramework);@(SupportedNETtandardTargetFramework)" />
    </ItemGroup>

Microsoft.NET.Sdk.WindowsDesktop.props

  <ItemGroup>

    <SupportedNETCoreAppTargetFramework Remove=".NETCoreApp,Version=v1.0" />
    <SupportedNETCoreAppTargetFramework Remove=".NETCoreApp,Version=v1.1" />
    <SupportedNETCoreAppTargetFramework Remove=".NETCoreApp,Version=v2.0" />
    <SupportedNETCoreAppTargetFramework Remove=".NETCoreApp,Version=v2.1" />
    <SupportedNETCoreAppTargetFramework Remove=".NETCoreApp,Version=v2.2" />
    
    <SupportedTargetFramework0 Remove="@(SupportedNETtandardTargetFramework)" />
  </ItemGroup>

nguerrera · 2019-07-19T00:38:07Z

That works for me.

(I assume the 0 in SupportedTargetFramework0 is a typo.)

vatsan-madhavan · 2019-07-19T00:39:13Z

That works for me.

(I assume the 0 in SupportedTargetFramework0 is a typo.)

yeah, typo ...

nguerrera · 2019-07-19T00:41:45Z

@davkean Any concerns here? Shall we go ahead?

vatsan-madhavan · 2019-07-19T00:49:47Z

Do we need a separate issue to puzzle out whether to add .NETFramework to SupportedTargetFramework items in Microsoft.NET.Build.Tasks/targets/Microsoft.NET.SupportedTargetFrameworks.props ?

Unless we have documented it as unsupported, I'm starting to think that it ought to be supported.
The very first example at How to: Use MSBuild project SDKs shows how to target .NET 4.6 using SDK style project. Additions to the csproj format for .NET Core also describes how to leverage it for .NET Framework. These seem to suggest strongly that the SDK style projects are both supported and encouraged for use by .NET Framework projects.

nguerrera · 2019-07-19T00:55:07Z

I assume the project system doesn't use this data for .NET Framework and instead looks in a more classical place for versions of .NET Framework to offer. I'm fine adding it, but if it's not going to be used, it doesn't seem to be high priority.

vatsan-madhavan · 2019-07-19T00:56:56Z

I assume the project system doesn't use this data for .NET Framework and instead looks in a more classical place for versions of .NET Framework to offer.

If the project system doesn't use it, then I agree that it doesn't matter. We should probably add a comment that .NET Framework is missing because the project system doesn't use it...

nguerrera · 2019-07-19T00:57:56Z

.NET Framework is supported by us. In fact, ASP.NET Core 1.x, 2.x projects could even target .NET Framework from File -> New Project.

nguerrera · 2019-07-19T00:59:22Z

It already shows the full list:

It is quite possible that the oldest ones in that list don't work so maybe we should get them out of there?

vatsan-madhavan · 2019-07-19T01:00:23Z

It is quite possible that the oldest ones in that list don't work so maybe we should get them out of there?

If the project system used SupportedTargetFrameworks, this would be so easy ;-)

davkean · 2019-07-24T21:55:41Z

We can use it for desktop, assuming you won't return < .NET Framework 3.0 for WPF/~~WInForms~~? It would be great if you return all of the TFMs from all frameworks so that we can switch between .NET Framework -> .NET Core as we've had quite a few bugs on this.

nguerrera · 2019-07-24T21:59:15Z

@davkean OK, we can add supported .NET Framework TFMs with the same pattern and WindowsDesktop can remove accordingly there too.

So you're good with this plan?

davkean · 2019-07-24T22:00:32Z

Yep, does this overlap with the existing infrastructure we already use to retrieve the frameworks?

vatsan-madhavan · 2019-07-24T22:02:00Z

We can use it for desktop, assuming you won't return < .NET Framework 3.0 for WPF/~~WInForms~~?

Why not WinForms?

davkean · 2019-07-24T22:02:23Z

WinForms is supported on .NET Framework 2.0.

vatsan-madhavan · 2019-07-24T22:04:41Z

Ah, got it. We have the right rules in place for WinForms for that in WindowsDesktop SDK.

@nguerrera We should see if we can do this correctly for WindowsDesktop.WindowsForms (netfx 2.0+) vs. WindowsDesktop.WPF vs. WindowsDesktop (same as WPF).

peterhuene · 2019-08-07T22:33:34Z

Ah I missed that part. I can add that to this change now rather than deferring that work.

Do we have a list of the expected supported .NET Framework TFs?

nguerrera · 2019-08-07T22:35:09Z

I don't know. I'm pretty sure older ones and client platform don't work. @dsplaisted Do we have a list?

nguerrera · 2019-08-07T22:35:54Z

I'm guessing we should use the same set as what was used for the full framework targeting packs as nupkgs? Where is that?

vatsan-madhavan · 2019-08-08T00:38:42Z

For WPF and WinForms, the .NET Framework support list can be found indirectly at https://github.com/dotnet/wpf/blob/8a234021a4e697f7e4999c282bde42d2473131f0/packaging/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.props#L77.

In short,

WPF: .NET Framework 3.0+
WinForms: .NET Framework 3.0 +

The exact reference set varies from net30, net35 to net40, net45 etc. , but they are all supported all the way to net48.

I can build a WPF and WinForms app in Visual Studio for any of the following targets:
- net30, net35, net40, net45, net46, net472, net48
- edit: the ones I haven't listed here in-between these values would also surely work.
I can build the same projects using dotnet for TFM net40+
- dotnet has trouble finding ref-assemblies for net30, net35. If they are supplied carefully in the projects, they build as well. (I tried this a while back but did not check again now). I think it suffers from Cannot find reference assemblies for .NET 3.5 or lower using core msbuild msbuild#1333

There are corner cases that need some special handling. For e.g., if you try to use SplashScreen with net30, you'll get an build-error (unsupported), but those are small issues.

peterhuene · 2019-08-08T18:40:43Z

@nguerrera @dsplaisted I couldn't find references to any enumeration of valid .NET Framework target framework values in sdk/core-sdk. It seems if we can't locate the reference assemblies we just fail with The reference assemblies for .NETFramework,Version=vX.Y.Z were not found.

peterhuene · 2019-08-08T18:50:22Z

Should I just add the corresponding TF values for https://dotnet.microsoft.com/download/dotnet-framework?

- Completes work started in dotnet/sdk#3438 Removes unsupported TFM's from SupportedTargetFramework.

vatsan-madhavan · 2019-08-08T19:27:50Z

I have a PR out at dotnet/wpf#1578. We will deal with netfx in another round... I don't want to hold the immediately-useful part of the work for the maybe-useful-in-the-future part of the work :-D

peterhuene · 2019-08-08T19:30:37Z

@nguerrera I've pushed 13ab14b to the PR. If that's not what we want, I'll delete the commit.

vatsan-madhavan · 2019-08-08T20:45:08Z

We should have 3.0 too, right?

vatsan-madhavan · 2019-08-08T20:47:28Z

3.5 and 4.0 had Client Profile IIRC; is there a way to represent those? Does it matter?

peterhuene · 2019-08-08T20:48:36Z

3.0 doesn't appear in the project properties currently when I switch a .NET Core project to a .NET Framework TFM. Starts with 3.5.

Only 4.0 shows as "client profile" in the drop down. I don't think we represent it in the target framework, but perhaps it should be in the display name?

nguerrera · 2019-08-08T20:49:52Z

It doesn't work in SDK, but there was net40-client in NuGet. I would exclude it. I think it's ok to exclude some things that can be made to work with some workarounds and only show the things that will actually work when you pick them.

peterhuene · 2019-08-08T21:05:27Z

@nguerrera should we take the additional .NET Framework values commit in the SDK PR? Any requested changes (perhaps "client profile" in the 4.0 display name to match the project system)?

nguerrera · 2019-08-08T21:05:38Z

3.0 doesn't appear in the project properties currently when I switch a .NET Core project to a .NET Framework TFM. Starts with 3.5.

I think this may depend on what you have installed?

I get this:

peterhuene · 2019-08-08T21:06:17Z

Doh, that makes sense. How far back does the rabbit hole go?

nguerrera · 2019-08-08T21:07:55Z

The only versions I know of that are not in my screenshot are 1.0, 1.1, and 4.8. I think we can ignore 1.x for sure.

The client profiles don't work, so let's definitely exclude those.

If I pick them:

Severity	Code	Description	Project	File	Line	Suppression State
Error	NETSDK1013	The TargetFramework value 'net40-client' was not recognized. It may be misspelled. If not, then the TargetFrameworkIdentifier and/or TargetFrameworkVersion properties must be specified explicitly.	t	C:\Program Files\dotnet\sdk\3.0.100-preview8-013640\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets	93

peterhuene · 2019-08-08T21:08:51Z

Ok, I'll add 2.0 and 3.0 then and we'll not add any client profile versions.

vatsan-madhavan · 2019-08-08T21:09:44Z

https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework

netfx 2.0 is the oldest supported value. My 2c - I don’t think we should consider something older than even that.

peterhuene · 2019-08-08T21:12:30Z

Amended with 9a2c0c5.

dsplaisted · 2019-08-08T21:34:05Z

Currently the dropdown is at least partially based on what targeting packs you have installed (there are no targeting packs for .NET 2.0 and 3.5 though). I think the static list you currently have is fine though, and will be better once we update the SDK to implicitly reference the targeting pack NuGet packages as needed.

nguerrera · 2019-08-08T21:42:56Z

When this is in, can you file an issue on dotnet/project-system to actually consume the .NET Framework supported list?

vatsan-madhavan · 2019-08-08T21:43:28Z

I updated dotnet/wpf#1578 to incorporate netfx tfm exclusions as well.

peterhuene · 2019-08-09T00:34:46Z

I've merged #3516 for the SDK side of the fix.

* - Addresses #1567 - Completes work started in dotnet/sdk#3438 Removes unsupported TFM's from SupportedTargetFramework. * Add netfx exclusions * Update comment describing supported version of WPF and WinForms (for netfx) better.

…102.3 (dotnet#3438) - Microsoft.NET.Sdk.Web - 3.1.100-preview3.19552.3

etbyrd mentioned this issue Jul 18, 2019

Correctly show supported frameworks for .NETCore WPF and WinForms projects dotnet/project-system#5011

Closed

nguerrera added this to the 3.0.1xx milestone Jul 19, 2019

nguerrera added the Feature Request label Jul 19, 2019

vatsan-madhavan mentioned this issue Aug 8, 2019

Remove .NETCore <3.0 as SupportedTargetFrameworks for WinForms and WPF dotnet/wpf#1567

Closed

vatsan-madhavan added a commit to dotnet/wpf that referenced this issue Aug 8, 2019

- Addresses #1567

733a460

- Completes work started in dotnet/sdk#3438 Removes unsupported TFM's from SupportedTargetFramework.

vatsan-madhavan mentioned this issue Aug 8, 2019

Remove unsupported TFM's from SupportedTargetFramework. dotnet/wpf#1578

Merged

peterhuene closed this as completed Aug 9, 2019

etbyrd mentioned this issue Aug 21, 2019

For WPF and Winforms .NETCore projects, versions lower than 3.0 should not be shown on the Application property page dotnet/project-system#5010

Closed

dsplaisted pushed a commit to dsplaisted/sdk that referenced this issue Feb 19, 2020

Update dependencies from https://github.com/aspnet/websdk build 20191…

a01b891

…102.3 (dotnet#3438) - Microsoft.NET.Sdk.Web - 3.1.100-preview3.19552.3

Remove .NETCore <3.0 as SupportedTargetFrameworks for WinForms and WPF #3438

Remove .NETCore <3.0 as SupportedTargetFrameworks for WinForms and WPF #3438

Comments

etbyrd commented Jul 18, 2019

nguerrera commented Jul 18, 2019

nguerrera commented Jul 18, 2019

nguerrera commented Jul 18, 2019

vatsan-madhavan commented Jul 18, 2019

vatsan-madhavan commented Jul 18, 2019

nguerrera commented Jul 18, 2019

vatsan-madhavan commented Jul 18, 2019

vatsan-madhavan commented Jul 18, 2019

nguerrera commented Jul 18, 2019

nguerrera commented Jul 18, 2019

vatsan-madhavan commented Jul 19, 2019 • edited Loading

vatsan-madhavan commented Jul 19, 2019 • edited Loading

nguerrera commented Jul 19, 2019

vatsan-madhavan commented Jul 19, 2019

nguerrera commented Jul 19, 2019

vatsan-madhavan commented Jul 19, 2019

nguerrera commented Jul 19, 2019

vatsan-madhavan commented Jul 19, 2019

nguerrera commented Jul 19, 2019

nguerrera commented Jul 19, 2019

vatsan-madhavan commented Jul 19, 2019

davkean commented Jul 24, 2019 • edited Loading

nguerrera commented Jul 24, 2019

davkean commented Jul 24, 2019

vatsan-madhavan commented Jul 24, 2019

davkean commented Jul 24, 2019 • edited Loading

vatsan-madhavan commented Jul 24, 2019

peterhuene commented Aug 7, 2019 • edited Loading

nguerrera commented Aug 7, 2019

nguerrera commented Aug 7, 2019

vatsan-madhavan commented Aug 8, 2019 • edited Loading

peterhuene commented Aug 8, 2019 • edited Loading

peterhuene commented Aug 8, 2019

vatsan-madhavan commented Aug 8, 2019

peterhuene commented Aug 8, 2019

vatsan-madhavan commented Aug 8, 2019

vatsan-madhavan commented Aug 8, 2019

peterhuene commented Aug 8, 2019 • edited Loading

nguerrera commented Aug 8, 2019 • edited Loading

peterhuene commented Aug 8, 2019

nguerrera commented Aug 8, 2019

peterhuene commented Aug 8, 2019

nguerrera commented Aug 8, 2019

peterhuene commented Aug 8, 2019 • edited Loading

vatsan-madhavan commented Aug 8, 2019

peterhuene commented Aug 8, 2019

dsplaisted commented Aug 8, 2019

nguerrera commented Aug 8, 2019

vatsan-madhavan commented Aug 8, 2019

peterhuene commented Aug 9, 2019

vatsan-madhavan commented Jul 19, 2019 •

edited

Loading

vatsan-madhavan commented Jul 19, 2019 •

edited

Loading

davkean commented Jul 24, 2019 •

edited

Loading

davkean commented Jul 24, 2019 •

edited

Loading

peterhuene commented Aug 7, 2019 •

edited

Loading

vatsan-madhavan commented Aug 8, 2019 •

edited

Loading

peterhuene commented Aug 8, 2019 •

edited

Loading

peterhuene commented Aug 8, 2019 •

edited

Loading

nguerrera commented Aug 8, 2019 •

edited

Loading

peterhuene commented Aug 8, 2019 •

edited

Loading