Winforms designer misbehaving, essentially broken

0
votes

We have a complicated legacy form built in Winforms that recently has started seriously misbehaving and it gets worse and worse as time goes on. Just opening the form in design view will alter the layout of the form, sometimes in minor ways (a control is resized to be a pixel smaller) and sometimes in major ways (a component is moved to X position -6582). Due to the size of this form and the nature of the generated .Designer.cs referring to the diff is almost usually useless to determine whether the changes that were made to the form were the changes that you actually intended.

Based off a number of suggestions I found in other questions:

AutoScaleMode is set to None. I experimented briefly with various monitor resolutions, to no avail. Ultimately we decided to stop relying on anchors and instead use a combination of TableLayoutPanels and Dock properties. And that's when the trouble really started...

After heavily redesigning one of the hairier tabs on this form, when I tried to save Visual Studio spun for 2-3 minutes and reported "Could not load file or assmbly 'MyProject, Verion=X.X.X.X, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified" (as seen here: Visual Studio 2013 Can't save, build, or rebuild solution). This happened whenever the form attempted to save. After following the advice in the accepted answer, I was able to save/build again.

Attempting to run not much later resulted in a very, very long build time and a completely empty form (as seen here: All controls on a form are invisible and https://stackoverflow.com/a/5524183/1015495 ). All calls to Controls.Add had been removed from the designer (I assume this massive change is what resulted in the long build time). I restored the form to a previous version and began recreating my changes. Now, much more insidiously, certain controls have had all of their children removed.

Working within this form is becoming a timesink at best and unfeasible at worst. The solutions that I've found online basically boil down to "recreate the form manually" or "don't use Winforms". Unfortunately neither of these are an option right now. How can we mitigate the problems that we're having with this form in the mid-term future until we can come up with a proper fix?

1
c#winformsvisual-studio-2012windows-forms-designer
Are you using any 3rd party controls? It's possible that one of them is not interacting correctly with the designer. Also, have you considered breaking the form into separate UserControls in order to compartmentalize the complexity? If nothing else, that would reduce the amount of time it takes to rebuild the thing when needed. Better yet, if one of those UserControls starts to misbehave then you will have narrowed the problem to a smaller set of the controls (which are hopefully easier to analyze). – RogerN
I am unaware of any 3rd party controls and a quick scan of the document outline didn't show up anything. We do have some user controls in use (not enough but there you have it). Realistically breaking it down into more user controls is going just as bad as recreating the entire thing but might be possible in chunks. Ultimately we just want to get rid of Winforms. – Mike G
You could try to start a second instance of VS and then attach to the running instance, and let it break in the debugger when an exception is thrown (for all exception types). That might catch code that doesn't handle design-time very well. – rene
Are there subclassed controls on the form? Some errors come to light only after a while.. – TaW
@TaW just to clarify, you mean controls that have subclasses? Not controls that are subclasses? – Mike G

1 Answers

0
votes

I am working through an almost identical problem at the moment and mine seems to be a bug in Visual Studio 2013 related to having a "linkLabel" control on a User Control, which is on one of the tabs of a tab control on the main form.

I had other linkLabel controls on the parent form that did not cause any issues. The weird thing is that not ALL of the tabs were messed up, only some of them. I can only conclude that it gets through part of the layout restructuring, hits the user control, and bombs out, failing to finish the layout correctly. I attached a second version of visual studio to try to catch exceptions, and saw various status lines showing up in the debugger, but did not see any exceptions thrown. I am not that familiar with doing that, so it's possible I did that wrong though.

I could revert the code back to after I had added the user controls, but before VisualStudio opened the form in the designer and automatically re-generated the designer code. At this point, opening the form in the designer will always cause exactly the same design failures. As long as I never opened the code in the designer again, everything would work correctly at run time.

If I removed any reference to the custom user controls with link labels, the designer would also open without any trouble. At first I assumed I had an error in my own code so I started commenting things out, but it was still happening even with just the basic elements dragged on. So then I started removing elements and adding them back one at a time to see what broke it. In my case this turned out to be the "linkLabel" control. I am not sure if there are other controls that will do this yet. For now I just plan on re-writing the code to not use a link label on the user control though and see how well that goes.