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.