Project-system: Retargeting Winforms project from 'net5.0' to 'net3.1' cause build failure

[dreddy-work]

Visual Studio Version
D16.8 preview 3

Summary:
There are other repercussion but following is the mainline scenario.

By default, we target to 'net5.0' and project file has SDK as "Microsoft.NET.Sdk" in it.

However, when we target to 'net3.1', project file supposed to have SDK as "Microsoft.NET.Sdk.WindowsDesktop". This is not the case when create app targeting to 'Net5.0' and later change the target framework to 'net3.1'. This causing the design time build to fail and users would see compile errors. Users would need to be educated on what need to be changed to get this working.

Expected:

Steps to Reproduce:

1. Create a new .Net core winforms application from 2019 16.8 preview 3 build

2. Retarget framework to 'net3.1/net3.0'

3. Design time build fails. Compile errors shown.

User Impact:
This experience is different from desktop framework applications. Their project won't compile and users need to have knowledge on what is right SDK version and manually update in the project file.

[tmeschter]

Notes:

1. We also need to consider similar issues that WPF projects may face.
2. In figuring out if/how to change the Sdk attribute we need to consider the UseWindowsForms and UseWPF properties but we shouldn't add, remove, or change the value of the properties.
3. We are already intercepting the target framework change when it is made through the UI, so doing something smarter with the SDK at the same time shouldn't be too hard. However, I don't think we can (or even should) do anything when the project file is edited directly. We should assume at that point that the user knows what they are doing.

[cartermp]

For WPF apps it's the same problem, and manually updating the SDK attribute to Microsoft.NET.Sdk.WindowsDesktop kicks off a design-time build that does the right thing.

On (3) it would be nice if the error list didn't explode, but that's really just a nice to have. If someone is manually editing project files to go back from .NET 5 to .NET Core 3.1, they can probably figure this out on their own. I guess we could make sure there's documentation in place, or that this issue in particular can be found by people.

[davkean]

• TargetFrameworkMonikerValueProvider can handle the UI set
• We could do something if users manually changed the TFM, but agreed probably shouldn't.
• Error List exploding is difficult; Roslyn wants types to resolve, and if we can't find them == error.
  
  
  
  • I think we should at least be better at ranking the root cause of the error, maybe we should promote NuGet/MSBuild above Roslyn errors/compiles from the same project, see: https://github.com/dotnet/project-system/issues/3778.
  
  

[jjmew]

This is addressed by #6601