Question

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)
Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top