C# 中偶发的序列化失败
我们将 Excel 导入到我们的系统中,并对其进行了非常严格的测试。最近,我们注意到零星的序列化错误。
这些错误是在我们反复使用同一文件进行导入的自动化测试中出现的。如果我们每次都收到此错误,我会理解,但相同的序列化过程可能会失败一次而不是下一次,这似乎很奇怪。
Exception: FormatException: Input string was not in a correct format.
Stack Trace:
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at System.String.System.IConvertible.ToInt32(IFormatProvider provider)
at System.Convert.ToInt32(Object value, IFormatProvider provider)
at System.Runtime.Serialization.Formatters.Binary.__BinaryWriter.WriteValue(InternalPrimitiveTypeE code, Object value)
at System.Runtime.Serialization.Formatters.Binary.__BinaryWriter.WriteMember(NameInfo memberNameInfo, NameInfo typeNameInfo, Object value)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteKnownValueClass(NameInfo memberNameInfo, NameInfo typeNameInfo, Object data)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteMembers(NameInfo memberNameInfo, NameInfo memberTypeNameInfo, Object memberData, WriteObjectInfo objectInfo, NameInfo typeNameInfo, WriteObjectInfo memberObjectInfo)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteMemberSetup(WriteObjectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo, String memberName, Type memberType, Object memberData, WriteObjectInfo memberObjectInfo)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObjectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo, String[] memberNames, Type[] memberTypes, Object[] memberData, WriteObjectInfo[] memberObjectInfos)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObjectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph, Header[] headers, Boolean fCheck)
We have an Excel import into our system that we test quite rigorously. Recently, we've been noticing sporadic serialization errors.
These errors are popping up in our automated tests against the import, using the same file over and over. If we were getting this error every time, I would understand, but it seems odd that the same serialization process can fail one time and not the next.
Exception: FormatException: Input string was not in a correct format.
Stack Trace:
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at System.String.System.IConvertible.ToInt32(IFormatProvider provider)
at System.Convert.ToInt32(Object value, IFormatProvider provider)
at System.Runtime.Serialization.Formatters.Binary.__BinaryWriter.WriteValue(InternalPrimitiveTypeE code, Object value)
at System.Runtime.Serialization.Formatters.Binary.__BinaryWriter.WriteMember(NameInfo memberNameInfo, NameInfo typeNameInfo, Object value)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteKnownValueClass(NameInfo memberNameInfo, NameInfo typeNameInfo, Object data)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteMembers(NameInfo memberNameInfo, NameInfo memberTypeNameInfo, Object memberData, WriteObjectInfo objectInfo, NameInfo typeNameInfo, WriteObjectInfo memberObjectInfo)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteMemberSetup(WriteObjectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo, String memberName, Type memberType, Object memberData, WriteObjectInfo memberObjectInfo)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObjectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo, String[] memberNames, Type[] memberTypes, Object[] memberData, WriteObjectInfo[] memberObjectInfos)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObjectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph, Header[] headers, Boolean fCheck)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您是否有机会使用依赖反射的库将 Excel 文件映射到对象图?
例如,我在映射到文本文件时遇到了 Filehelpers 损坏数据的问题。不会经常发生,但确实会发生,而且只是间歇性的。
在这种情况下,FileHelpers 的问题在于 FileHelpers.RecordInfo.RecursiveGetFields(...) ,后者又调用 FileHelpers.FieldInfoCacheManipulator.ResetFieldInfoCache(...) ,后者使用反射来修改实际 .NET Reflection 库的私有成员。尝试强制 .NET 反射按照字段声明的顺序返回字段。
然而,微软明确指出“您的代码不得依赖于返回字段/属性的顺序”http://msdn.microsoft.com/en-us/library/kyaxdd3x.aspx 和 http://msdn.microsoft.com/en-us/library/6ztex2dc.aspx
如果您使用的库执行类似的操作,则可以解释您的间歇性错误,因为该库可能会导致反序列化与不正确的源属性/字段(可能是不同的类型)不匹配。
Are you by any chance using a library that relies on reflection to map the Excel file to an object graph?
For example, I have had problems with Filehelpers corrupting data when mapping to a text file. Doesn't happen very often, but it does happen, and it is only intermittent.
In this case, the problem with FileHelpers lies in FileHelpers.RecordInfo.RecursiveGetFields(...) which in turn calls FileHelpers.FieldInfoCacheManipulator.ResetFieldInfoCache(...) which uses reflection to modify private members of the actual .NET Reflection library in an attempt to force .NET reflection to give fields back in the order they were declared.
However Microsoft explicitly states "Your code must not depend on the order in which fields/properties are returned" http://msdn.microsoft.com/en-us/library/kyaxdd3x.aspx and http://msdn.microsoft.com/en-us/library/6ztex2dc.aspx
If you are using a library that does something similar, it would explain your intermittent errors, because the library might mismatch the deserialization with the incorrect source property/field, which could be a different type.