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 开发者_JS百科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?
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.
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.
精彩评论