I am seeing lots of churn (via GitHub) when anything in Designer changes

Environment

All

.NET version

All

Did this work in a previous version of Visual Studio and/or previous .NET release?

No

Issue description

This is a tracking issue; it worked this way in Framework, but it really threshes GitHub

These changes happen constantly they don’t break anything they just renumber CellStyles The next change restores the original values

_Originally posted by @paul1956 in https://github.com/dotnet/winforms/issues/7602#issuecomment-1225044377_

Changing anything in a WinForms Form when the Designer file is recreated. You will see large changes if you use Git to compare current with history. An example is shown in the image above. This is just 1 example.

Steps to reproduce

Create a Form, add a DateGridView and something else like a TextBox, save Push, to GitHub, Open Form in Designer change anything like move textbox. and then use Git to do a Diff and you will see the difference shown above.

Diagnostics

N/A

[KlausLoeffelmann]

Yes, that’s what I have tried to point out, but maybe did not phrase it precisely enough.

If a Form then borders the threshold limit [I meant 3,000 lines of code at the time], and while working on it, goes back and forth with resulting lines of code, there may be bigger changes or inconsistencies in the resulting designer code. But we will be at least pushing the lines-of-code limit far out (if we need to have it at all).

I just released a patch for that, addressing a number of issues. Longer story short: The culprit is a performance issue in a Roslyn with the method Simplifier.ReduceAsync. Simplified (ha!), this guy is responsible to applying all sorts of optimizations, and it is REALLY good at this. The problem: In certain combinations (and the number of lines of code is not necessarily the main factor alone, although it has to do with it), its causing workloads increasing exponentially. Optimizing type names (global::System.Windows.Forms.Button -> Button) is one of the biggest performance impacting factors. So, to mitigate that:

1. We will use a Pre-Simplifier, which shortens the type names and eliminates Me or this with a different, way faster strategy.
2. If the code is now less than 10,000 lines of code (in contrast to 3,000 lines before), we’ll do run Roslyn’s simplifier. We can do this, because now - pre-simplified - ReduceAsync is WAY faster than before.
3. Over 10,000 lines of code, we still bypass ReduceAsync, but: Since the Pre-Simplifier did a huge amount of work already (and also takes care of non-reduced code which would end up with Syntax Errors in VB), the difference is not as dramatic as before.

You will see this when 17.6 releases at the latest.

[merriemcgaw]

We’re working on moving our CodeDom serialization to Roslyn, which is a huge undertaking (so no ETA but it is in progress). Once that is done, we can investigate if this still happens to the same degree, and further investigate. At this point, it’s better to wait until we have the Roslyn serialization to invest much because this is a very old issue that has always been here, Git makes it much more visible.