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

[paul1956]

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

[paul1956]

This issue is related to having a DataGridView on the form BUT not specifically related to changing anything with the DataGridView.

[elachlan]

Related: #3652

[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.

[paul1956]

@merriemcgaw @KlausLoeffelmann this issue went away for the most part until Preview 2 (or my design file got bigger) when its back. I think to save time on large designer files over 3,000 lines you don't format the designer file. but on code cleanup it gets formatted and for formatting on things like font size they get changed back and forth with every edit/save/Commit, Local variables in designer get renamed," Me." is added and removed. Unfortunately, my Designer file is now over 3,000 lines long.

Below are just a few examples from different files Changes go From

Dim DataGridViewCellStyle1 As DataGridViewCellStyle = New DataGridViewCellStyle()
Me.AboveHighLimitMessageLabel.Font = New Font("Segoe UI", 12F, FontStyle.Bold, GraphicsUnit.Point)

To

Dim DataGridViewCellStyle2 As DataGridViewCellStyle = New DataGridViewCellStyle()
Me.AboveHighLimitMessageLabel.Font = New Font("Segoe UI", 12.0F, FontStyle.Bold, GraphicsUnit.Point)

then back

Dim DataGridViewCellStyle1 As DataGridViewCellStyle = New DataGridViewCellStyle()
Me.AboveHighLimitMessageLabel.Font = New Font("Segoe UI", 12F, FontStyle.Bold, GraphicsUnit.Point)

Reformatting .Designer file fixes one issue like Me. disappearing and causes another.

[KlausLoeffelmann]

I am working on a considerable improvement for Forms/UserControls which result in more than 3,000 lines of code. That counts both for code quality and performance. They will be maybe already going into 17.6 Preview 3 but Preview 4 at the latest. We have not decided yet, if the change meets the bar to service them back to 17.5, also since the next service date and the update to 17.6 are less than a month apart.

By the way: These are the issues which have been fixed by the service update (these are internal Designer repo issues).

It's important to know that you have those now fixed in 17.5 through servicing. They will be still present in 17.6 Preview 1 and some in Preview 2, because they were ported back for servicing after the 17.6 Preview 2 cut-off date.

[KlausLoeffelmann]

I am closing this now.

If you see any odd behavior in particular, which you are not sure if it may be covered by the list above, please open a new issue and call me and @merriemcgaw out in it explicitly. Also keep in mind: we're trying to make the code-reducing work for all Form sizes, but there may be very few remaining corner cases (depending on size and some characteristics) where the workload to do that just becomes unfeasible. If a Form then borders the threshold limit, 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).

Also, I really want to mention in that context: Thanks so much for the support here, especially with everything around VB. We really, really appreciate all your help and your invaluable experience with real-world Visual Basic scenarios!

[paul1956]

@KlausLoeffelmann @merriemcgaw you seem to miss the point. I don't care (anymore) if there are major changes in Designer file with each new release as you improve the designer. It's the fact that every edit causes 100's of changes in the file and then the next edit reverses some and causes new changes. It's impossible to edit a form (manually or with designer) without huge numbers of formatting differences. Semantics (mostly) don't change so code works before and after. I say mostly because there is still issue with BeginInit not working with designer bound DataGridView.

Right now I edit in designer, diff the old vs current, find the (few) lines I intended to change, save the changes in Notepad, close VS, open the designer file in another Notepad and copy the changes and save. Then reopen VS.

If you want all the specifics I can open 1 or more issues for each area of difference.

Short summary of key ones

Font size 12.0F to 12F to 12.0F

Style variable names change with every edit and then back with next.

DataGridView Row and Column styles increase with every edit by (row/column)style.count

Random control initializations move around file and then back.

[elachlan]

I raised a not too different issue: https://github.com/dotnet/winforms/issues/3652

Which was about the reordering of code with each change causing unnecessary churn.

I have been dealing with it for a long time. I usually use a visual got diff tool to only keep the changes that are needed. But if more than a few changes are made that's impossible to do.

[KlausLoeffelmann]

OK, here is something that I want to point out again:

If a Form then borders the threshold limit, 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).

If, @paul1956, is not the case I would need to dig into that deeper.

I have been dealing with it for a long time.

This again is not caused by the latest change.

So, are we talking here now about a recent regression or the same problem we dealt with all along?

Also @paul1956: What's the line count of the Designer file you are referring to in the context of this issue.

[paul1956]

@KlausLoeffelmann 3000 lines

The Font changing from 12F to 12.0F to 12F with every edit is something I have never seen before. I sent a Gif showing all the changes as VS Feedback. Project is Open Source on GitHub. I believe it happens when Designer.vb file is open in Visual Studio when the Form is updated by Designer. ^K^D also sometimes fixes it. Below is after change Form TItle.

[KlausLoeffelmann]

Can you post the link (didn't see it, but since on my phone I might have missed the link in the thread). Thx!

[paul1956]

The project used in the image is https://github.com/paul1956/CareLink. Form1 is the one where adding 1 character to Form1.text causes the above. But most of the forms show major changes with any minor edit.

Except for below nothing requires more then opening Form1 and editing anything then doing a Git/compare with unmodified.

Also Form1 crashes during initialization after any edit I believe due do DataGridView not respecting BeginInit, I have been working around that by manually reordering a few lines in designer file which has to be done in notepad to prevent VS from undoing my change.

[paul1956]

I just noticed that if I open Form1 in new designer and then view Form1.designer.vb with no edits after a short time I get some of the same differences without making any changes. If I then make a change using Visual Designer some of the changes get undone but others new ones appear.

[paul1956]

@KlausLoeffelmann @merriemcgaw An issue related to the topic, the first time a new control is added to a form parts of the need code is added at the bottom of each appropriate section. When something unrelated on the form changes the previously new items are move to a different place, probably where they belonged to begin with. I like where they eventually end up but if there is a commit in-between it causes lots of unneeded change. I removed a lot of lines in a branch and the font changing from 12.0F to 12F to 12.0F repeatedly disappeared so it is related to file lines. I am working in a branch until you confirm that you have what you need from GitHub Main Branch. I am also removing dependency on BeginInit for DataGridView by doing data binding in Form1.Shown (in branch), Main still has issue.

[merriemcgaw]

Thanks @paul1956 we're working on getting to the bottom of the 12.0F to 12F issue.

[paul1956]

@merriemcgaw I wonder if some of the thrash issues are related to VS or VS Extensions (CodeMaid, Reshaper, some of MADs...) doing automatic formatting on save (or edit) and using preferences in editor.config (I don't use Reshaper any more).

Where on large files the designer skips formatting and if you are close to threshold the reformatting pushes you over or under it, so changes get done and undone with each save. Just a thought because when I removed many lines (100's) from designer file in branch many formatting differences go away and designer is mostly stable after second edit except for DataGridView issues. It still takes 2 edits/saves for controls to end up where I think they should be.

[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.