I don't think you can always expect your users to do the reduction and the debugging for you, they pay you for a bug free product. In this case it's a developer-centric product, so I guess the bug reports are more geeky, but customers are not here to serve the developers.
A nitpick but it's really important that HNers understand it: users do not, in fact, pay for bug free products. They pay for products which achieve the benefits promised to them, bugs and all. If they wanted to buy bug-free products, they'd a) make decisions about software adoption driven primarily by externally visible indicia of bug-freeness and b) pay prices similar to that paid by e.g. the Space Shuttle or flight control systems. Users do neither of these things for most software.
Agree, I should have made that clear in my comment. in fact I've found that a) the product devs should be able to find the cause much faster than you can, b) it's more effective for you to spend your time developing a repro script/code/etc, because unlike describing a bug, this is unambiguous and the devs can run it very quickly to verify tat the issue can be reproduced on their end.
Agreed but I was confused by the MS response of "Thank you for submitting feedback on Visual Studio and .NET Framework." It seems like the bug is in VS and not .NET. Are they that interweaved these days?
The bug report frontend is for both. The Thank you is just an automated response that it was seen. Generally, lots of the official replies on Connect seem to be either text building blocks or canned responses. Not terribly surprising, either, I might add.
in 1998 I was working with VS and had a bug with OCX and was told that the bug was due to VS not working with the current IE version as well in places and was fixed in the new release of VS due out.
So I'd say very interweaved if history has its design legacy mantra.
IIRC Internet Explorer used to overwrite the shell DLLs which contain a lot of random helpers and stuff that is not strictly shell related but tempting to make your application depend on. I remember this being a frequent source of "app not working, probably works on the developer's machine" type issues, especially in the time period where this was changing a lot.