Maintain WinForms support
Many companies have heavily invested in WinForms since the introduction of .NET, and as a mature and stable platform, both developers and 3rd party control vendors are continuing to produce WinForms solutions despite the availability of WPF.
With this in mind, it's regretful that Microsoft have prematurely cut support levels to such shockingly low levels that almost no WinForms issues are being addressed on Connect. This includes breakage introduced in .NET 4 / VS2010 and the lack of resources to address those issues. Almost *every single* issue is being closed with the same automated cut and paste response about limited resources, which is resulting in a completely unacceptable level of support.
Please restore at least some additional resources to the WinForms team so they can provide decent levels of support and fix bugs that are causing a great deal of aggravation.
Please don't take this as an attack on WPF by the way. WPF is fantastic for what it's aimed at, but it's just not currently suitable for every type of project and everyone's cup of tea.
Unless Microsoft release an official statement to the contrary, I, along with many other developers will continue to regard WinForms as a viable alternative technology to WPF in a similar way to the debate between ASP.NET WebForms vs. MVC.
In summary, please don't just ditch your large and active WinForms developer base, leaving us in the lurch.
Daniel Smith
shared this idea
We will certianly continue to maintain the product. Today we released Visual Studio Express 2012 for Windows Desktop which demonstrates our continued support for Windows Forms. Please continue to report bugs on Connect (http://connect.microsoft.com/visualstudio). Individual issues are evaluated carefully – we consider many aspects of the change including the cost, implications, and number of requests.We are closing this issue so you can have your votes back. Thanks for your feedback!
8 comments
-
Victor Zakharov
commented
Every single WPF program I have seen so far, sucks, except for maybe Visual Studio 2010 itself. WinForms to stay.
-
Philippe
commented
In my case, I had very few new problems after upgrading my project and I consider them minor comparatively to the improved stability of the designer and far better handling of errors while loading a form.
Also for some problematic case, the best solution might be to simply execute some code at run-time. And if a form is complex, uses user controls.
My main problem with WinForms is that the designer does not always works when the forms contains a C++ component from a project Inside the solution. One workaround is to temporarily change the reference to the actual DLL.
Otherwise, after upgarding to Visual Studio 20110 and .NET 4.0 (from 2008 and 2.0), I had a issu with reports where I get some extra blank pages... and I was able to handle that with a compromise which finally is not that bad.
-
Chaware
commented
Guys there is a seperate user's voice for Winforms -- please go and check this link <http://windowsforms.uservoice.com/forums/133946-ideas-suggestions/suggestions/2371661-continue-with-winforms-and-actively-mainatin-suppo>
And most important -- 'vote as well' to drive home the point.
-
EricF (MSFT)
commented
We appreciate the feedback and understand that Windows Forms’ Connect users feel that their voice isn’t being heard. As part of our effort to address this issue, we have set up a UserVoice site dedicated to Windows Forms. UserVoice is set up quite differently than Connect and we feel that it is well suited to surface the most popular ideas and requests to the the community and the Windows Forms team. If you want more support via Connect, visit the Windows Forms UserVoice site and vote for it. If you want a new feature, you’re welcome to vote for that too. We want to understand the kind of issues that you want to see addressed. Please cast your votes at http://windowsforms.uservoice.com .
-
Nicole Calinoiu
commented
@Visual Studio Team: To add to Daniel's list, I found the boilerplate "won't fix" response to https://connect.microsoft.com/VisualStudio/feedback/details/607381/windows-forms-bindingsource-only-prevents-object-leaks-for-first-level-of-nested-property-binding a bit hard to swallow. A big, old pile of resource leakage despite use of the component that was introduced to avoid it doesn't merit a fix or at least some sort of published workaround? Given that the proportion of the client base that will encounter the problem is likely to increase as developers move to using Microsoft-supplied ORM frameworks, and that identifying and fixing this sort of problem is potentially very painful (if not essentially impossible) for most of the target client base, I find it hard to imagine a scenario in which it doesn't merit some sort of serious attention (well, at least not as long as you're actually supporting WinForms as a UI framework).
-
David Nelson
commented
Please do not confine discussions about these issues to private email. The whole point of using a public feedback site like UserVoice is so that the WHOLE community can participate. A lot more people are interested in this subject than just the OP, and they should all have the opportunity to participate in the discussion.
-
Daniel Smith
commented
@Visual Studio Team, sure no problem, I'm more than happy to help so feel free to get in touch either here or via email.
I'm currently monitoring over 800 issues on Connect from various teams so I can pick out a sample of recent WinForms issues from my watch list for you. It's issues like the first few in the list below where there isn't even a follow up process or any kind of human response; just a generic cut and paste auto reply with the issue being closed as "won't fix".
-
Hi Daniel - regarding the breakage introduced in .NET 4 - may we email you for more information on that, per your email on file?
