views:

234

answers:

2

I found a bug in the .Net framework yesterday and found that it is a known bug that won't be fixed. In short the bug is that a class that contains a field of the type IComparable can't be binary serialized and deserialized when an int (and possibly other binary types) are assigned to that field:

[Serializable]
public class Foo
{
    public IComparable Value;
}

If you try to serialize (and deserialize) the following two objects the first one will succeed and the second one will fail:

var s = new Foo { Value = "foo" };
var i = new Foo { Value = 1 };

I describe this in more detail here: http://ondevelopment.blogspot.com/2009/11/fix-that-bug-will-ya-no.html

And the bug report you can find here (note that this report is from 2006 and not filed by me): http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=91177

This will not be fixed because "the risk of the fix outweighs its benefit". I fail to see any (feesible) scenarios where this would be a breaking change. So my actual question is, can anyone think of a real scenario where this would be a breaking change?

+1  A: 

I fail to see any (feesible) scenarios where this would be a breaking change

I don't think there would be any intentional breaking change, but there are other risks involved in fixing bugs that might introduce regression.

Your example looks contrived, so I think they concluded that the risks outweighed the benefits. They also gave you an opportunity to contact PSS if this is genuinely causing you a problem.

Joe
It wasn't I who filed the bug, as you see the bug report is four years old. It's not a big problem for me, I'm only interested in what problems the bug fix might cause. I'm in no way implying that they're wrong, I'm just saying I can't come up with a scenario where it's a breaking change and I'm curious to see if anyone else can.
Patrik Hägne
"I can't come up with a scenario where it's a breaking change" - the internals of how serialization is implemented are complex, and you don't need to come up with a scenario to understand that changing complex code has risks.
Joe
How is my example contrieved? The example here in the question is a simple bug repro, check the blog post for more in detail description of a real problem. What you're saying is that they're afraid to fix this issue because it might break something completely unrelated? Without checking the source of the binary serialization implementation I can't tell you if I think that's likely or not. But to me that seems contrieved.
Patrik Hägne
You can contact PSS to see if anything can be changed in your code to work around this issue. Just don't expect PSS can resolve the bug for you.
Lex Li
@lextm-MSFT if you read my blog post I provide a workaround. This question is not about that, it's about - out of curiosity - finding an example of a scenario where fixing this bug would break other working code.
Patrik Hägne
+2  A: 

My bet would be that they have made some very contrived optimisations in the case of native types like int for serialisation or even other parts of the system.

Undoing that might be risky in that it may correctness or performance regressions, or both.