+972 52-548-6969
Microsoft ConnectRedefining bugs as features as a standard operation procedure
This and this bugs are really pissing me off. Both those bugs are related to the same source, and one of them was originally a Rhino Mocks issue. They both stems from the CLR runtime bugs. Basically, trying to inherit from a generic interface with generic method parameters that has constraints causes the runtime to puke with a TypeLoadException.
I am not one to cry that select() is broken, but in this case, it most certainly is. It is verified using both the C# compiler and Reflection.Emit, so it is definitely a runtime bug.
The really annoying parts that they were acknowledged and verified as bugs by Microsoft, and then closed By Design. No communication whatsoever about the reasoning for that, just the customary "By Design" response that I have seen all too often in the past.
I personally have had to track down the root cause when it was first submitted to me as a Rhino Mocks bug. If this is a By Design bug, then either the design is broken, or we deserve a lot more information about this, because no way your turn this, it should be legal to do this.
As you can probably tell, I am very angry about this, not the least because I spent many hours with it before admitting that it was a runtime bug that I had no way around. I am pretty sure that some of the bugs in connect are resolved to their reporters satisfactions, I just have to meet such a thing.
More posts in "Microsoft Connect" series:
- (18 Sep 2007) Redefining bugs as features as a standard operation procedure
- (14 Sep 2007) Without Words
Comments
Here is the perfect argument for staying away from closed-source software. Not only have you found the bug, are able to reproduce it, I don't doubt that you could fix it as well. It's just that you can't.
@LukeB
Unfortunately that is not the perfect argument. Just because you are able to find a bug in an open source project doesn't mean you will be able to fix it. And even if you are able to fix it, your "fix" may introduce other bugs because you don't have a complete understanding of the code base (something that someone working with it day to day would have).
So, let's say that you don't have the skill to fix it, or don't have the time to go over the code-base to fix it properly and instead you ask the people working on the project to fix it. They may or may not see the bug as the same priority as you do. Just because it is a critical issue for you, doesn't mean it is for the 99% of the other people using the project. And besides, they might be buried at work this month and not be able to get to any of the bugs, cause let's face it, a lot of the best projects out there are done by people in their spare time. For the sake of brevity we won't get into what happens when the maintainers get burned out.
And with that, unless you are able to fix the problem correctly and have the time to do so, you are really left in the same boat as with closed source software. At least with closed source software, more often then not, there are people that are paid to maintain it and to support it. It's their job day in day out.
I'm not saying that closed source software is better than open and I'm not saying that open source software is better than closed... It's just software and all software is going to have problems that you may or may not be able to get fixed, either by your hand or by involving another party. That's just the way it is. Throwing around "open source software" as the "fix all" to all software bugs will only lead one to trouble. No software is perfect... It's all written by humans in one way or another.
Your code should produce a StackOverflowException not because you tried to implement a generic interface method with stronger constraints than the interface definition, but because the CLR does not recognize that ICollection<T> is implemented by List<T>, so adding ICollection<T> doesn't actually change the constraint. However, the spec seems to indicate that neither the compiler nor the CLR does this. The spec says "When a generic method implicitly implements an interface method, the constraints given for each method type parameter shall be equivalent in both declarations...": http://en.csharp-online.net/ECMA-334:_25.6.2_Virtual_generic_methods
Why is this necessarily bad design/a bug? Requiring the CLR to determine that ICollection<T> can be ignored because List<T> implements it seems unnecessary work that can be done statically by the programmer or, in your case, the person emitting IL. Am I missing something?
Luke,
The constraint is for T2 : T, where T is List<string>
It is not on T2 : T where T : IEnumerable, because you already have defined T to be list<string>
The constraint should be T2 : List<string>, but you have it as T2: List<string>, ICollection<string>. As I pointed out above, theoretically this ICollection<string> should not affect anything as List<string> implements it, but the CLR isn't smart enough to figure this out. I argue this isn't necessarily a terrible thing, as the IL-emitting code could remove superfluous constraints and/or match exactly the constraint found in the generic interface definition.
Some WCF, that i found out in the net ... :)
http://sendhil.spaces.live.com/Blog/cns!30862CF919BD131A!927.entry
Luke: If the CLR were required to be smart enough to figure out that the constraint fits, it would be a verifier bug. Otherwise, it is a bug in the C# compiler, because the compiler shouldn't assume the CLR was smart enough.
All: The links above aren't actually related to RhinoMocks, see the RhinoMocks group (http://groups.google.com/group/RhinoMocks/browse_thread/thread/e0307787e810fde7?hl=en).
However, I'm also often annoyed at bugs being closed without any further information, especially as "By Design". That's just not satisfying at all, and it rather discourages people from reporting bugs in the first place. I wonder whether there is a place to lobby for better feedback...
I mean, the first stage of Connect works alright - the bugs I've reported so far are usually reproduced/acknowledged and sent to the appropriate group in a few day, sometimes even hours. If there's something missing, I get contacted and asked for more details - that's all great. But as soon as the bug has been forwarded to the group, the flow of feedback stops all too often.
Have you tried calling them directly as it's suggest? You could probably try commenting on CLR developers' blog to get better feedback (not sure if it'll help).
Rhino Mocks is really an amazing piece of software. Does it also happen in Mono? I'm just crossing my fingers not to step into such runtime exceptions - otherwise I might have to run my tests on linux :p
Rhino Mocks should works well on Mono 1.2.5
Yeah Microsoft Connect is useless, when bugs are closed you get no feedback. The whole approach seems to be completely broken and I've given up on reporting things.
I agree don't think open source is the solution either though, I've logged plenty of bugs/feature suggestions in open source projects and not really gotten much feedback. I can understand why but and I guess I could do the change myself...
Comment preview