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!
I will try and create a sample and test on a "clean" machine. The problem is not reproducable on our developer machines, or clients that have upgraded - it only appears where v8.3 is installed and tries to load a v8.1 layout. Also, it may only occur on Win XP machines.
You certainly should not have to do this. Layouts shoulds always be compatible if you are loading an older layout into a new version of the grid.
I tested this out and it works fine for me saving a layout in v8.1 and loading it into v8.2. So if you can duplicate this and provide a small sample project demonstrating the issue, we can take a look.
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 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
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...