I tried, but an object reference exception occurs in LoadFromXml Method.

the layout was used with 9.2 ... then i changed the volume to 10.1 and it doesnt work anymore

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.Soap.ObjectReader.Bind(String assemblyString, String typeString) at System.Runtime.Serialization.Formatters.Soap.SoapHandler.ProcessGetType(String value, String xmlKey, String& assemblyString) at System.Runtime.Serialization.Formatters.Soap.SoapHandler.ProcessType(ParseRecord pr, ParseRecord objectPr) at System.Runtime.Serialization.Formatters.Soap.SoapHandler.ProcessAttributes(ParseRecord pr, ParseRecord objectPr) at System.Runtime.Serialization.Formatters.Soap.SoapHandler.StartChildren() at System.Runtime.Serialization.Formatters.Soap.SoapParser.ParseXml() at System.Runtime.Serialization.Formatters.Soap.SoapParser.Run() 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)

Hi,

This looks like a known issue that occurs when you try to load a layout into your application and the layout has a reference to a class that is defined in an assembly that has not yet been loaded into memory.

This could happen if you are storing a custom class as the Tag on an object in the grid, or if one of your grid columns is using a DataType that is defined in some other assembly.

Does that sounds like it could be the case here?

... and there is no problem if I use the layouts in the same volume which they were created with...

the exception occurs only when i switch to the next volume like 9.2 to 10.1

The bug in question was introduced in the service release for v9.2, and the same fix is in the release build of 10.1, so that probably explains it.

Anyway, the objects you are storing in the Tag must be getting saved along with your layout, but they must have always been lost when you loaded the layout. Loading the layout used to just ignore this and now it's raising an exception as a result of the change that was made.

This will be fixed in a future service release. But if you want to work around it for now, you have a couple of options:

1) You could make sure the assembly which defines your meta-data is loaded into memory before you load the layout into the grid. You could do this in a number of ways, the simplest of which is to simple create an instance of one of the objects.Or, another option would be to force the loading of the assembly using System.Reflection.Assembly.Load, but there might be some permissions issues there.

2) You could loop through the grid and null out the Tag properties before saving the layout.

1) the assembly is definitely loaded

2) sounds plausible, i will try it..

I define all the IG Columns in my code and enrich them with my meta-info tag...

after that, i apply the saved grid layout from xml so that the user gets the grid back as he has left it.

so all the types must have been loaded when applying the grid layout from xml.

Nolde said:

1) the assembly is definitely loaded

Are you sure? How do you know?

When I say "loaded", I mean loaded into memory, not just referenced by the project. An assembly won't typically be loaded until some code in the project tries to reference something in it.

If the assembly is, in fact, loaded into memory at the time you are calling LoadFromXML, then something else might be going on there and this might not be the same bug.