Have you ever wondered why launching an application that has Report viewer 2010 Winforms control through clickonce takes multiple times more time to render the report in Local mode? Try launching the same application directly by double clicking the EXE. Now you will understand what i’m taking about.This behavior certainly relates to the design of your report like amount of data being retrieved and the amount of expression used in the report.
Well, if you’re compiling your application in .NET framework 4.0, then you’re certainly bound to see the issue irrespective of how you launch the application. But the above observation is related when you run the application hosting report viewer 2010 winforms control in .NET Framework 3.5.
You can find more details on execution mode and the Sandbox execution model directly from Brian’s blog @ http://blogs.msdn.com/b/brianhartman/archive/2010/02/18/expression-evaluation-in-local-mode.aspx
Coming back to our scenario of running the application under .NET 3.5, then who causes this impact?
Ok. To come straight to the answer, Clickonce technology chooses Simple Sandboxing execution mode by default. You can understand more about this from http://blogs.msdn.com/b/shawnfa/archive/2006/04/19/579066.aspx
Now in report viewer 2010 control, we use certain application logic to decide whether the report viewer 2010 control should execute in the Sandbox mode or not. Because ClickOnce already set a specific flag regarding the Sandbox execution, in the report viewer when we check the flag it is set to execute in Sandbox mode. So report viewer 2010 control continues to execute the application in the Sandbox mode. Hence even in .NET 3.5 framework, you always have the feeling that your application is actually running under .NET Framework 4.0.
Unfortunately there is no workaround for such scenarios. The options are either to drop ClickOnce or to use older version of the report viewer control.
As an application developer, if you’ve an application launched through ClickOnce and using older version of ReportViewer control and you’ve plans to move to Report viewer 2010 or you’ve already moved to Report Viewer 2010, please do not be surprised if you encounter the above discussed behavior.
As an application developer, if you’ve an application using Report Viewer 2010 or above and running in .NET Framework 4.0 or above, please do not be surprised if you encounter the above discussed performance behavior. This is by design.
[The above post is AS-IS and doesn’t carry any warranty]