I recently had the immense frustration distinct pleasure of upgrading a .Net 3.5 Asp.Net web forms application using client-side reports with the old and busted ReportViewer 8.0.0.0 to the new hotness ReportViewer 10.0.0.0 that ships with Visual Studio 2010. I thought it would be a simple update to the project references and a re-compile but unfortunately it turned out to be more involved. So for anyone else, here's the lowdown.
1. Once you try to open .rdlc files in Visual Studio 2010 that were created with previous versions of Visual Studio, you'll be prompted to upgrade the file to RDL 2008 format, or else be relegated to viewing the file in the Visual Studio Xml editor. If you don't, then they'll be upgraded at runtime but you'll probably want to upgrade them anyways, and you’ll be forced to if you ever want to edit them in Visual Studio using the report designer.
2. You'll obviously want to remove your old Microsoft.ReportViewer references and add new ones to the Microsoft.ReportViewer.WebForms 10.0.0.0 assembly. The same deployment model applies though. If you run the ReportViewer 2010 redistributable on both your development and production servers than you'll only have to reference the WebForms library. However, if you can't or don't want to do that, then you'll want to extract Microsoft.ReportViewer.WebForms.dll, Microsoft.ReportViewer.Common.dll, Microsoft.ReportViewer.ProcessingObjectModel all from the GAC (after running the redistributable obviously) and add file references to them. You'll also want to update your web.config, which is mostly updating the version string in all the settings related to Microsoft.ReportViewer. When in doubt, new up a blank Asp.Net web application, add a ReportViewer control from the toolbox onto Default.aspx and look at the web.config.You may want to do that anyways, especially if you’re moving to IIS7 as well as ReportViewer 10.
3. Your existing aspx pages may not work after all this because ReportViewer 10.0.0.0 is much more asynchronous friendly and thus requires a ScriptManager control on the page now in order to function correctly. Fortunately, the orange screen of death that you get when you forget to do this is pretty self-explanatory.
4. Your existing aspx pages may still not work correctly because of a bug with the Visible property on the ReportViewer 10 control. If you have pages where a ReportViewer is initially hidden, declaratively configured in the aspx markup, that is unhidden and rendered after some user input, you'll probably run in to this. You won't get an exception, just a blank report. If you view source, you'll see some text relating to a configuration error in the web.config. Ignore it, it's misleading. The workaround is to set the LocalReport.ReportPath (or LocalReport.ReportEmbeddedResource) just after you set Visible to true. It’s on Microsoft Connect already. 100% of the reports I had in the aforementioned web application worked this way and were affected by this. Not fun.
There is at least one other gotcha I ran into but it is not specific to ReportViewer 10 so I’ll cover that in a future post. Happy reporting.