Hi,

Nothing has changed in terms of the saving and loading of layouts from one version to another as far as I know.

I wonder if perhaps the project itself is still holding on to some reference to the older assemblies - perhaps in the licx file. Or perhaps the assembly references have CopyLocal set to true?

Thanks Mike.

The licenses.licx file haven't changed for a long time - and didn't reference any of the assemblies/objects that infragistics complains.

The licenses file did refer to the 8.1 versions of Infragistics assemblies though.

The only difference between the "working" and "non-working" versions of our app is now the referenced/compiled version of infragistics assemblies:

8.1 (8.1.20081.1000) is working while 8.2 (8.2.20082.1000) isn't...

None of our referenced assemblies has CopyLocal set to true - all assembly binding in our environment is done via late binding. By stepping through the code we're under the impression that when UltraWinGridLayout 8.2 was loading the layout and deserialising it with a soap formatter, it tried to bind all loaded assemblies, which was not a behavior that we had seen in 8.1...

We have a somewhat similar problem.

We have opgraded to Crystal Reports 10.5 - but some of the users haven't had the appropiate assemblies installed yet.

They get an ReflectionTypeLoadException (assembly: 'CrystalDecisions.CrystalReports.Engine, Version=10.5.3700.0, ...') when they execute an UltraGrid.DisplayLayout.LoadFromXml(...).

It's not really a problem, we just have to deploy the proper assemblies - I was just very supprised.

/Klaus

We recently encountered the problem of the ReflectionTypeLoadException because of upgrading our Infragistics controls. It seems that layouts serialized with 8.1 include a reference to v8.1 in the namespace of the xml schema (i.e. "xmlns:a1=http://schemas.microsoft.com/clr/nsassem/Infragistics.Win.UltraWinGrid/

Infragistics2.Win.UltraWinGrid.v8.1") that the newer versions cannot cope with.

As a workaround we have had to catch the ReflectionTypeLoadException and try and update the version numbers in the layout, before trying to load again. e.g.

string layout = ... get layout from database/file...

using (MemoryStream stream = new MemoryStream(Encoding.ASCII.GetBytes(layout) ))

{

try

{

ultragrid.DisplayLayout.LoadFromXml(stream, PropertyCategories.All);

}

catch(ReflectionTypeLoadException ex)

{

string upgradedLayout = layout.Replace("v8.1","v8.3");

using (MemoryStream stream2 = new MemoryStream(Encoding.ASCII.GetBytes(upgradedLayout) ))

{

ultragrid.DisplayLayout.LoadFromXml(stream2, PropertyCategories.All);

}

}

}

This fixes the problem, but is not ideal. If this issue is going to reaccur in future releases we will have to determine the version numbers at runtime.

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 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.