We’ve recently upgraded our Infragistics .Net UltraWinGrid references to 8.2.3.5 from 8.1.2 and have started to see some very weird behaviors in terms of layout loading.
Our grid is bound to an interface and we save our infragistics layouts as serialized XML as the user's local layout.
On app start up, the grid then deserialise the XML node into a stream and the layout is loaded from that stream (using UltraGridLayout.LoadFromXml(...).
And here is where we start to have trouble – infragistics 8.2.3.5 appears to be reflecting all referenced classes (even if it is not loaded at the time of layout loading), instead of only the classes used in the layout. The result is that if any class is broken, infragistics UltraWinGrid will throw an exception and fail to load the layout. This worked perfectly well with 8.1.2.
By “broken” I meant below (reasons we have already discovered, and there might be more - we use late binding for pretty much everything as we have a customised environment which requires run time assebmly resolving)
- the assembly cannot be loaded,
- the class is not implementing an interface properly this happens quite a lot in our late binding model: e.g. class C implement interface I, interface I got updated to include a new method M but C hasn’t been upgraded. This works well with late binding as long as M is not called (which I’d consider to be reasonable) but infragistics here won’t be happy with that.
Since pretty much everything in our .net world is late binding this can be quite dangerous in terms of future maintenance.
I’m just wondering if anyone else had seen similar problems? 8.1.2, on the othe rhand is not having this issue. Has something changed in between?
Thanks for your help!
You probably just need to get the latest service release.
How to get the latest service release - Infragistics Community
We recently converted our projects to .Net 4.0 and Infragistics 10.1. I have two projects that save grid layouts. One project saves them as binary in a database. The other saves them as binary to a file. We've been using this arrangement since at least version 6.3.
We are now testing the new version and having "strange" errors re: loading layouts. My save layout method is simple:
Private Sub SaveLayout(ByRef Grid As UltraGrid)
If Grid.DataSource IsNot Nothing Then
Grid.DisplayLayout.Save(LayoutFileName(Grid.Name),
PropertyCategories.AppearanceCollection Or PropertyCategories.Bands Or PropertyCategories
.SortedColumns)
End If
End Sub
And here's the call stack from the error we're getting. It appears there's a problem with a "type".
************** Exception Text **************System.NullReferenceException: Object reference not set to an instance of an object. at Infragistics.Shared.Serialization.Binder.FindType(Assembly assembly, String assemblyName, String typeName) at Infragistics.Shared.Serialization.Binder.BindToTypeImpl(String assemblyName, String typeName) at Infragistics.Shared.Serialization.Binder.BindToType(String assemblyName, String typeName) at Infragistics.Win.Serialization.Binder.BindToType(String assemblyName, String typeName) at Infragistics.Win.UltraWinGrid.Serialization.Binder.BindToType(String assemblyName, String typeName) at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Bind(String assemblyString, String typeString) at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name) at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable) at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record) at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum) at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run() at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream) at Infragistics.Win.UltraWinGrid.UltraGridLayout.LoadHelper(Stream stream, PropertyCategories propertyCategories, IFormatter formatter) at Infragistics.Win.UltraWinGrid.UltraGridLayout.Load(Stream stream, PropertyCategories propertyCategories) at Infragistics.Win.UltraWinGrid.UltraGridLayout.Load(Stream stream) at SAInventory.frmMenu.ResetLayout(UltraGrid& Grid) at SAInventory.frmMenu.ResetLayoutToolStripMenuItem_Click(Object sender, EventArgs e) at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e) at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e) at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ToolStrip.WndProc(Message& m) at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
We have just experienced the problem again, having upgraded from 8.2 to 9.2. It seems to only be a problem on one of the grids in our application though (the only difference I can see at the moment is one uses ASCII encoding and the other UTF8).
We've updated our code so that it gets the version number of the ultragrid assembly using reflection and then does a global replace of the old version in the layout xml (before trying to get the grid to load it). This fixes the problem for us.
danglei said: That being said, has Infragistics got any plans to investigate and think what went wrong in this process? A .net assemblie should be able to cope with multiple versions and side-by-side loading.
That being said, has Infragistics got any plans to investigate and think what went wrong in this process?
A .net assemblie should be able to cope with multiple versions and side-by-side loading.
That is not true. You cannot have multiple versions of the same assembly loading into memory at the same time and expect it to work correctly. This has nothing to do with Infragistics, it's a limitation of the DotNet framework.
In fact, if you load two instances of the same assembly (even if it is the same version) into memory at once, it will cause problems because the framework does not consider the two objects to be the same.
danglei said:As customers, we would expect it to just work. It wouldn't be acceptable if Microsoft says Word 2007 and Word 2003 cannot run at the same time - and we see this layout loading issue in the same way.
That is not the same thing. Those are two different, separate applications. You can run two different applications that use different versions of the assemblies at the same time. But you cannot have two different versions of the assemblies loaded into memory within the same application.
Back in July 09 I created a test app as Mike suggested and ran it on one of our test machines. It worked fine in that instance, so obviously there are some subtleties in reproducing this. I never investigated further due to time and our workaround was sufficient.