Microsoft Connect is where Microsoft pretends to listen to customer feedback. In my experience, you shouldn’t bother unless you’re helping Microsoft debug a beta product.
On 26 October 2008, I reported a WPF exception handling defect in Visual Studio 2008 SP1 which still persists in VS 2010 SP1. Within the VS debugger, exceptions in WPF code-behind constructors generate a meaningless XamlParseException with no indication of the faulty source code line. If you’re not aware of this issue you’ll waste hours scanning your XAML code, looking for a bug that actually occurred in your C# constructor.
So one might think that’s fairly important! Yet on 9 July 2012 – four years later – Microsoft replied that this bug won’t be fixed, allegedly because it did not “impact the highest number of WPF developers.” What, the highest number of WPF developers never write constructors or use the debugger? Ridiculous.
As it turns out, four years is normal for Microsoft Connect to procrastinate on trivial issues, whether in VC++ or .NET. This matches my experience with most Connect reports I follow. The very product in which an issue was found is usually obsolete by the time Microsoft replies, and the reply is usually “won’t fix.” Why even bother keeping up this charade?
(Weird .NET Issues: added WPF constructor exception misreporting)
2013-02-16: Another Microsoft Connect tale, this time from the C++ world. I had filed an easily reproduced VC++ x64 optimizer bug on 16 June 2011. That was closed as “duplicate” at some point, but without actually linking to the alleged duplicate. Now, on 14 February 2013, Microsoft confirms that the bug I had filed against VS2010 SP1 has been reproduced in VS2012… and may be fixed in some future version.
So true. I have lost count of the number of Connect issues I’ve entered only to have them rot for a year or more to be closed as Won’t Fix. Just this week I got the same “…doesn’t impact many devs” excuse for something that is clearly a memory overwrite:
https://connect.microsoft.com/VisualStudio/feedback/details/624320/wpf-tooltipservice-values-are-corrupt-after-odbc-query
Wow, a memory overwrite in the WPF infrastructure is a pretty serious issue. And that still gets a canned “won’t fix” reply after 20 months, even though you went through the trouble of following Microsoft’s detailed repro instructions? Unbelievable.
Aside from the dysfunctional Connect system, I have to assume this also shows that Microsoft has effectively abandoned .NET on the desktop. It’s hard to imagine how they could ignore such a bug otherwise.
@cnahr: that conclusion doesn’t follow. If “ignoring serious bugs” implies “Microsoft has effectively abandoned the technology”, then they’ve abandoned each and every technology.
There are plenty of serious bugs in their C++ compiler, in the IDE, in the debugger and in Intellisense and… countless other places. I’m pretty sure they haven’t abandoned *all* of those. ;)
So no, I think it just shows that Connect is a mess, and whichever bugs they choose to fix has next to no correlation with which bugs users report on Connect.
I’m not sure if that’s much better, but… Ah well. ;)
Good point, I was just hoping that maybe the situation with Connect isn’t quite as bad as it looks!