Hi,
One of our web projects have been using the Infragistics controls for quite some time (since 2003 I think?) and we use both the old UltraWebGrid and ExcelExporter throughout the site. We have decided that it is time to start switching over to the new AJAX WebDataGrid for performance reasons and to make sure we are not left behind once Infragistics stops supporting the old controls.
Usually we would like to be able to have both controls referenced side be side, to help stagger the upgrade process across all the screens (and still allow the project to compile). So we have made sure all the existing Grids are using the latest 2010.2 version.
Unfortunately we have found that due to the Infragistics.Excel namespace used in both the Infragistics4.Web.v10.2.dll and Infragistics2.WebUI.Excel.v10.2.dll (required due to strong binding to the Infragistics4.WebUI.UltraWebGrid.ExcelExport.v10.2.dll) that we are unable to reference both controls in the same project...
There are over 151 grids that need to be updated and most of those use the ExcelExporter. How can we reference both assemblies and controls without causing namespace conflicts and/or still retain the Excel Export functionality on the old grids? (my assumption is that the new Excel Export control will not work with the old WebGrid)
Cheers!Craig Wilson
Hello Craig ,
There is an technique called "Extern Alias" which probably you should use in order to use the the controls without conflicts.
There is conversation about "Extern Alias" at the following forumn thread: http://community.infragistics.com/forums/t/43077.aspx
Please let me know if you have any further questions.
Hi Danko,
That would work but unfortunately the project has been written in VB and not C#, therefore you can't alias an assembly in that way.
I have managed to grab the source code and recompiled Infragistics4.WebUI.UltraWebGrid.ExcelExport.v10.2.dll against Infragistics4.Web.v10.2.dll instead of Infragistics4.WebUI.Excel.v10.2.dll and this seems to work (although not ideal considering that I'm creating a custom version of the assembly).
It would have been more practical to be told in a release, that you will need to remove the old excel assembly and add the new one in it's place, instead of causing this type of upgrade nightmare... How come this wasn't done in this way?
Cheers,Craig Wilson
Hello,
Taz have already mentioned our plans for fixing this issue in the next service release. You will be notified accordingly when this behavior is changed.
Please let us know if you have any further questions.
We have tested the 2010.2.2018 service release which resolves this issue and we have no further problems at this stage. Thank you to you and the rest of the team for the helping out with this problem.