Microsoft Connect - FAIL (yet again)
I really think that Microsoft should close Connect. Because it is pretty obvious that they aren't managing that properly.
Let us take a look at yet another interesting bug report. This is related to a bug in System.Data that makes using System.Transactions even trickier than you would initially believe.
It was acknowledged as a bug by Miguel Gasca (from Microsoft), and a connect was reported.
That was in 2007(!), it was resolved, a month later, by "Microsoft", because it is "External" issue.
That bug is till here today, two years later, and still impacting customers. That is after a full release and SP1. The situation is that now I have to work around this bug because Microsoft cannot manage its own bugs database in a way that would allow it to... oh, I don't know, fix bugs!
FAIL
And you know what, I wouldn't be annoyed with this if this wasn't an ongoing pattern with Connect.
FAIL
Comments
Heh, I commented about this before- I basically believe they can arbitrarily label a report as 'by design'.. I made one regarding routing, and how its impossible to map a url outside of a http context, purely because they make two stupid assumptions:
cannot determine app path outside of a http context (you can via a static environment class)
you MUST have previous request data that can be used to fill in any blanks (what if I don't have any blanks?)
Aparently its purposely designed to be sh- ah nevermind!
The problem is that Microsoft Connect is not Microsoft's real bug tracker. There seems to be no integration, they simply copy stuff back and forth between their internal database and Connect. Developers are not even required to look at Connect, only the people who are responsible for managing Connect are. So that means there are already two levels of indirection(Connect, the person at Microsoft who reads your bug in Connect and the real developer) between you and the developer who would need to fix it.
Connect is a huge failure and they need to scrap it and expose the real deal with real developer interaction. Currently, the best way to get anything done is to get the ear of the direct developer through their blog or some other non-official(and thus unsupported and non-binding) Microsoft means, which is a shame.
Sometimes they do listen. Sometimes I even feel bad for posting not so important suggestions, and then watching MS implement them, but not those I consider more important. ;-)
On of the most feedback-resistant teams at MS is the C# team. OK, they listened when they were asked for optional parameters and automatic properties, I believe those were officially added due to customer feedback. (I don't like the word "customer" in that context, when I give feedback I'd like to be treated as a member of a language's community, not someone who's allowed to speak for the .0001% of market share he represents...)
Other times they seem to listen to other teams at MSFT - the legacy crowd brought us COM support in the language, the designer-happy VS teams brought us partial methods. Wonder how they made the necessary + 100 points ( blogs.msdn.com/.../57985.aspx).
The stuff they do is usually well thought through and very consistent. I am still impressed by the way they created LINQ on top of some very clean and individually useful language features. And I am really excited about their intention to explore meta-programming in C#5.
However, I believe the language would benefit a lot if there was a way to discuss features and their priorities between the C# team and the community.
For instance, I think it's a shame that in terms of meta-programming, they are already looking into ways to build something that just might be as impressive as LINQ has been, but at the same time turn a blind eye to problems with the current meta-programming infrastructure that could probably be easily solved. Just remove those limitations on attributes, for god's sake!
connect.microsoft.com/.../ViewFeedback.aspx
And even LINQ has a problem that makes me think that maybe it should be considered at least a bit broken: When you're dealing with the IQueryable version (i.e., anything but LINQ to Objects), expensive transformations between LINQ and the target query language (e.g. SQL) need to take place. However, the way LINQ is built, automatic caching of those transformations is all but impossible.
MS's answer was to use compiled queries, but they are so awkward to use, they really defy the purpose of LINQ (LI is for Language Integration, not for creating ugly, error-prone and verbose compiled query delegates!)
It's like, hey, look how simple and beautiful LINQ is (but if you really want to use it for anything significant, please turn the page and look at this ugly workaround you're going to have to use for every single query that matters!)
connect.microsoft.com/.../ViewFeedback.aspx
Of course, I'd be too happy about every vote these bugs get. Maybe votes do mean something after all. However, they cannot replace a conversation.
Yes, I love LINQ, I am excited about co/contravariance, I really want you to find solutions for meta-programming and I think that people like Erik Meijer are made of the right stuff. But please don't forget that there are people out there, using your existing stuff, and hitting walls. We really need some attention from time to time down here on earth.
I've actually submitted 3 bugs through Connect, and had all of them fixed. It took a while, sure, but they worked with me to understand what was going on, and provided a solution, and a workaround when the solution wouldn't be until the next product.
For not being a Premier customer, I was quite happy with their response.
Ayende -- you might be surprised to learn that people other than yourself actually log connect bugs as well. And sometimes, gasp, those bugs might be deemed higher priority and more important than your personal pet peeves.
I've seen bugs on there with steps to reproduce, and MS have labeled them as not being able to reproduce, and then closed. Then a bug opened for the same issue, and MS reporting it as not being able to reproduce.
Following the steps exactly you can reproduce the bug...
An example would be the DataGrid paging feature, when you select the first item the colspan ends up 1 on the paging item, if you select the 2nd item the colspan ends up being the number of total columns...
anon,
a) it is not my bug
b) did you see what annoyed me? That a confirmed bug was closed as an external issue
They seem to be closing bugs these days... They just killed my bugs about unicode not really working in SQL server if you use COLLATE that are different from the DB collate.
Couldn't disagree more - two bugs, two 'fixes' - and in one case they couldn't even reproduce because it only happens in very strange circumstances:
connect.microsoft.com/.../ViewFeedback.aspx
and
connect.microsoft.com/.../ViewFeedback.aspx
Sure I have one or two suggestions that haven't made it, and also a couple of bugs - but typically the issues in question are by design, and other alternatives are available.
I think to say that the whole thing should be shut down just because a few bugs slip through the net sometimes is childish and, frankly, for somebody who has such a presence as your good self, irresponsible.
How many people, upon coming across this blog post, will now not bother to post a potential bug on Connect, because they value your opinion?
If I'd done that, then tonnes of people who try to use the entity framework (I'm not here to argue about that - I know your views) alongside dynamic assemblies would have been stuck for potentially a lot longer than they will be (see the first bug report).
I agree - it is a strange state in which this bug was left - but if you try to reproduce the bug in VS2008 with .Net3.5 now, you'll find that it has been fixed. Clearly, the fix was done to the framework - but the bug was not updated.
I can't speak on behalf of every team, but for the few teams that I saw dealing with bugs from connect you wouldn't believe how serious they are taken. It's just that some times many things are in the table, and a fix is not as clear cut as it might appear..
Teams should give more feedback, though, so the decisions dont look arbitrary.
I agree. It seems more like a marketing thing for me: "We care about our customers."
I submitted 3 bugs and 2 suggestions so far.
4 in SQL Server (SSIS + SQL CE) and 1 bug in .Net's OleDb Wrapper.
4 of the 5 are active and 1 was inexplicable closed: "[Won't Fix]". :-(
The 4 active are promised to be solved in the future. I guess if pigs could fly. ;)
1 of them is active since July 2008 and it's a bad Blocker for us. :-(
Comment preview