Hello,
a few users of one of our customers currently experience the following issue when our program calls Infragistics.Win.UltraWinGrid.UltraGridLayout.LoadFromXml(Stream stream, PropertyCategories propertyCategories).
The stream is a memory stream and propertyCategories is set to PropertyCategories.All.
This results in a System.Reflection.TargetInvocationException.
The strange thing about this is, that no matter the source of the XML (in this case it is actually created in memory and loaded from anywhere) this fails. I have compared the XML with the XML on a machine where it worked and did not find any significant differences.
This issue on comes up on very few specific computers and not anywhere else.
We have checked the GAC and the folder our software has been deployed in and there are no anomalies either.
The users culture is US English.
Has anybody else experienced a similar error?
Here is the call stack
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.FormatException: Input string was not in a correct format.
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 Infragistics.Win.UltraWinGrid.SortedColumnsCollection..ctor(SerializationInfo info, StreamingContext context)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._SerializationInvoke(Object target, SignatureStruct& declaringTypeSig, SerializationInfo info, StreamingContext context)
at System.RuntimeMethodHandle.SerializationInvoke(Object target, SignatureStruct declaringTypeSig, SerializationInfo info, StreamingContext context)
at System.Reflection.RuntimeConstructorInfo.SerializationInvoke(Object target, SerializationInfo info, StreamingContext context)
at System.Runtime.Serialization.ObjectManager.CompleteISerializableObject(Object obj, SerializationInfo info, StreamingContext context)
at System.Runtime.Serialization.ObjectManager.FixupSpecialObject(ObjectHolder holder)
at System.Runtime.Serialization.ObjectManager.DoFixups()
at System.Runtime.Serialization.Formatters.Soap.ObjectReader.Deserialize(HeaderHandler handler, ISerParser serParser)
at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize(Stream serializationStream, HeaderHandler handler)
at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize(Stream serializationStream)
at Infragistics.Win.UltraWinGrid.UltraGridLayout.LoadHelper(Stream stream, PropertyCategories propertyCategories, IFormatter formatter)
at Infragistics.Win.UltraWinGrid.UltraGridLayout.LoadFromXml(Stream stream, PropertyCategories propertyCategories)
Best regards
Sebastian PeschtiesLogimatic Germany GmbH
Understood.
Fortuanately, the sub-applications are fairly self-contained and communications between them don't involve infragistics types. Hence, no further exceptions have been noted.
Thanks for taking a look.
Hi Tony,
There's nothing we can do about something like that. If your application is using multiple versions of the same assemblies, then I am very surprised that this is the only exception you are getting. Your application should be blowing up all over the place with type mismatches any time one part of the application tries to communicate with any other part with any of the Infragistics controls.
When you load a layout into the grid, the grid examines the layout file and determines which assemblies are needed and strips out the version numbers. Then it looks at what assemblies are in memory with the same names. If there is more than one assembly loaded into memory with the same name, but a different version, then it's going to just pick up the first one and there's no way we could do it any differently.
Loading two versions of the same assembly into memory is just not going to work properly no matter what.
Ok, as hard as I tried to simplify the process of recreating our issue, I could not.
However, I think I know what's going on and I'm trying to recreate the issue now in as simple a way as I can.
First, some background:
Our project is very large, consisting of multiple mini-applications written by multiple teams that run within a single MDI application. Most of the time everything is very well coordinated. However, sometimes some teams get ahead of others.
The problem:
Not all of the applications in the project are currently using the same version of Infragistics controls.
In this project, there is an application that loads up before ours that is still using infragistics 8.1 (and perhaps some that are using 6.3).This particular application always loads before my teams. I have determined that after this application loads that 9.1 grids are no longer able to import grid settings from older versions. Obviously, the best thing is for everyone to be using the exact same version of infragistics. However, I think this is still something that needs to be addressed on your end and I'll attempt to duplicate this scenario and proof of issue as simply as possible, if I can. If I discover something different, I'll post that as well.
Thanks,
Tony
Yeah, I'll work something up at lunch and get it to you.
Hi Anthony,
Can anyone provide a couple of sample project with an old version of the controls that saves a layout and then a new version which fails to load the saved file?
I do this kind of thing all the time and I have never had a problem like you are describing, so my only guess here is that it's some particular combination of property settings that is causing the errors.
There is no reason why you should not be able to load a layout from an older version of the grid into a newer version.