Udostępnij za pośrednictwem


Upgrading Web Application Projects to VS 2010

A number of people have posted questions about upgrading their VS 2008 web applications using the ReportViewer control to VS 2010.  The upgrade process is not automatic.  Before I get into the steps required to upgrade your applications to the VS 2010 ReportViewer, I’d like to take a moment to explain why this upgrade process is not automatic.

The VS 2008 ReportViewer can be used in the VS 2010 shell.  While you won’t get the design time experience associated with the 2008 viewer, it will function correctly at runtime.  Certainly, we want everyone to upgrade to the new version, but there are a few reasons you might not want to, and therefore why we don’t upgrade everything automatically:

  • Using the VS 2010 ASP.Net ReportViewer requires ASP.Net AJAX.  While this has not been an issue for most people, it is a new requirement and requires some changes to your ASP.Net pages.
  • The VS 2010 ReportViewer will not work against a SQL 2005 report server in server mode.  If you plan to connect to a SQL 2005 report server, you will need to stay on the VS 2008 version.
  • There are a few API changes that break backwards compatibility in the strict sense.  In response to customer feedback, some methods changed from a return value of void to something more useful.  These changes don’t require you to change your code, but they do require a recompilation.  Assembly version redirection won’t work.

After you load your web application in VS 2010, you will need to perform the following manual steps to get your application back to a fully working state:

  1. In the assembly references section of the solution explorer, remove any references to 9.0 ReportViewer assemblies and add their 10.0 equivalent.  Depending on the versions of the ReportViewer you have installed on your development machine, this may have been done for you.
  2. In the web.config file, locate all references to the ReportViewer assembly and replace the 9.0.0.0 version string with 10.0.0.0.  The public key token did not change in 10.0.  In a typical web.config file, there are four references to the report viewer:
    1. A reference to Microsoft.ReportViewer.WebForms in the system.web/compilation/assemblies section
    2. A reference to Microsoft.ReportViewer.Common in the system.web/compilation/assemblies section
    3. A reference to the RdlBuildProvider in system.web/compilation/buildProviders section
    4. A reference to the HTTP handler in the system.web/httpHandlers section.  Depending on the version of IIS that you are targeting, a similar reference may also be in the system.webServer/handlers section.
  3. In each ASPX file that references the ReportViewer control, a register tag was added when you first inserted a ReportViewer control on the page.  This reference also needs to be updated from 9.0.0.0 to 10.0.0.0.
  4. If you did not already have an ASP.Net AJAX ScriptManager on the page, you will need to add one to the top of the page.  It is located in the AJAX Extensions section of the Toolbox.

Comments

  • Anonymous
    June 08, 2010
    Local reports in the VS2010 report viewer control still seem to exhibit the memory leak. Simple test performed: Create form 1 with button to open form 2 that contains a report viewer control. There are no datasources associated with the report. Click button on form 1 then close form 2. Repeat several times and note that memory increases for the exe but is never released.
  • Anonymous
    June 10, 2010
    Hi HartmanI'm really sad to see somethings changed a lot when using design mode in VS2010. I really think VS2008 is a little easier when creating table data and grouping it within a List. Now I'm struggling here to make something similar in VS2010, mainly when I'm trying to group information using a List (here says tablix?!). Perhaps report viewer guys should give the same name to this list control: or call it Tablix or call it List. Because this different names mess around with developers who are trying to understand the new features. Another think lost here is the copy and past column in this table control. On VS2008 this copy and paste funcionality was pretty easy. I may say, the report designer offered in VS2010 is a pain in the neck for who is migrating their apps. I don't think Report guys at Microsoft are going to correct these things, but at least, they could create a separated tool to design these reports without so many troubles.