WinForms visual inheritence issue in VS2010

394 views Asked by At

Quick bit of background to the project in question: it's C# .Net 4, WinForms with smart client factory and unfortunately a lot of visual inheritance.

Here's a brief outline of the problem the team I'm working on are experiencing which seems to be fairly intermittent:

Someone will open up one of the client module projects to begin work on one of the views, double click on the view to open up the designer and Visual Studio will give them a design time error such as:

There's no way back from this; if you rebuild from here without doing the following work around then the error will still persist. The only work around we've found is to clean the client solution, close Visual Studio (you have to do that), reopen Visual Studio and rebuild the solution. Next time you try to open the view it will work. But the error will come back again - it seems to be after X amount of rebuilds (possibly only while the view is open in the designer whilst you're building the solution?)

No one has taken the time out to really dig into this problem and at the moment no one has the time! So I was wondering (bit of a long shot) if anyone might have an idea about what could be going on? Or perhaps an inkling of where to start digging once we get a bit of time to look into this?

1

There are 1 answers

0
Igby Largeman On

If you use visual inheritance, these problems are a fact of life and they're not likely to ever go away.

I make extensive use of UserControl inheritance in my current project. I used to get the problem you're describing very frequently. Over time I've refined the design down to the point where it only happens occasionally now, and I rarely have to do the clean-restart-rebuild dance anymore.

You mileage will probably vary, but I think the main thing I did to reduce this problem was to get rid of design-time inter-assembly data bindings.

An example of this is when you drop BindingSource on your form and set its datasource to a type from another assembly.

(Well, it's always from another assembly because I never define types in the same assembly as my UI. So for all I know, the inter-assembly thing may not even be a factor.)

Anyway I ended up getting rid of most or all of these design-time bindings and setting up all my bindings at runtime. The problem has 99% gone away. It still happens occasionally but I don't bother to try to troubleshoot it.

And whatever you do, don't inherit a form/control from a generic base class. That breaks it 100% of the time. If you need to do this, there's a workaround which you can find with quick search.

Microsoft will almost certainly never fix these problems, so get used to them.