Update Winforms C#/VB templates designer code in InitializeComponent() for modernized CodeDom Serialization

[Olina-Zhang]

.NET version

8.0.100-alpha.1.22607.6

Did it work in .NET Framework?

N/A

Did it work in any of the earlier releases of .NET Core or .NET 5+?

N/A

Issue description

WinForms Designer GH https://github.com/microsoft/winforms-designer/pull/4425 for OutOf-Proc Designer had modernized CodeDom serialization, code for InitializeComponent(), is generated taking into account .editorconfig preferences and <ImplicitUsings>enable</ImplicitUsings> project property. However, Winforms C#/VB templates do not respect these settings.

Template Winforms C# designer code: --- need to update After added a button with modernized CodeDom serialized code

Template Winforms VB designer code: --- need to update After added a button with modernized CodeDom serialized code

Steps to reproduce

1. Just create a Winforms .Net C#/VB application
2. Go to Form designer file, check the code in InitializeComponent()

[dreddy-work]

@Tanya-Solyanik / @KlausLoeffelmann , what would be user experience if they use older VS version (that has legacy serialization) but with new updated templates from .NET 8.0 if we do this change?

[KlausLoeffelmann]

Other than that saving with a previous version of Visual Studio would simply revert the InitializeComponent code to a previous coding style - nothing. I would totally be in favor of doing this.

And this is a real good suggestion by @Olina-Zhang!

[dreddy-work]

Other than that saving with a previous version of Visual Studio would simply revert the InitializeComponent code to a previous coding style

To me, that may cause confusion given the scenario is more common (for the fact that VS is paid, and .NET is not).

[KlausLoeffelmann]

To me, that may cause confusion given the scenario is more common (for that fact that VS is paid, and .NET is not).

What? I don't understand what you mean. The Code in InitializeComponent is technically an implementation detail and can be understand as a black box. I know, there are some scenarios around HighDPI, where it makes sense to patch that code directly when it comes to change coordinates - but nothing changes here conceptually, and we're not moving any cheese for customers. So, I don't really know what you mean. But I may be missing your point completely and thinking in the wrong direction... 😸

[Tanya-Solyanik]

When the same project is opened in both VS2022 and VS2019, the workaround is to ensure that code-gen follows the same rules by opting out from this - <ImplicitUsings>enable</ImplicitUsings>. This will reduce code churn in the designer file.

This change could be conditioned in the same way as the implicit usings are: <ImplicitUsings Condition="'$(csharpFeature_ImplicitUsings)' == 'true'">enable</ImplicitUsings>

We could also consider adding editconfig to the template and enforcing its settings in the generated code.

Or we could add a wizard and code-gen this code on the fly.

[dreddy-work]

So, I don't really know what you mean.

My concern was about code churn they see when they open project in older VS versions.

[KlausLoeffelmann]

We should do it via .editorconfig, but there will be things, which will not be picked up or be configured. And that's fine. There will be differences, and ultimately, we will introduce even breaking changes. (Think of NameOf).

That's what we knew and wanted when @DustinCampbell started the work on it.

The whole point IS to modernize, and introduce modern styles, approaches and paradigms. Let's please not be afraid of reasonable breaking changes. There will be no confusion for customers, as long, as we're documenting and reason our changes. @merriemcgaw FYI.

[merriemcgaw]

I'm OK changing the templates in .NET 8 to match the new codegen. In fact it looks much cleaner. We'll do a brag blog to talk about the modern codegen and that should alleviate a lot of the confusion from most people.

[merriemcgaw]

@KlausLoeffelmann do you think we really need this one in .NET 8?

[JeremyKuhne]

@KlausLoeffelmann moving to 9 as we've run out of runway for this sort of change.

[JeremyKuhne]

@KlausLoeffelmann if we intend to do this we should bring it back in. Moving to future for now as we've punted this a few times.