Using ReportViewer in Local Processing Mode in Azure Web Sites/Apps

SUMMARY

Microsoft ReportViewer (WebForms) doesn’t work out-of-the-box in Local Processing Mode (RDLC) in a .NET web app/api deployed to Azure Web Sites/Apps. This sad fact is also confirmed by one of the recent, official Azure blogs.
However, there’s a way to make it work, and here is a summary of steps to do it:

1. Add ReportViewerCommon + ReportViewerWebForms NuGet packages to the web app/api project utilizing client-side reporting.
2. Install Microsoft ReportViewer Runtime matching the version of the NuGet packages installed in (1).
3. Access Microsoft.ReportViewer.ProcessingObjectModel.dll file by pressing ‘Start’ key/button and typing “C:\WINDOWS\assembly\GAC_MSIL\” into search (in Windows 8+/2012+).
4. Copy Microsoft.ReportViewer.ProcessingObjectModel.dll file anywhere outside its GAC folder (i.e. project’s \Dependencies folder etc.).
5. Add the copied Microsoft.ReportViewer.ProcessingObjectModel.dll file as a reference to the project.
6. Set Copy Local = True on all three referenced ReportViewer assemblies (under References: Microsoft.ReportViewer.***).
7. Deploy web app/api to Azure.

For more details about the need for these convoluted steps, read on below.

DETAILS

According to an official Microsoft blog post, ReportViewer in Local Processing Mode (RDLC) is not supported in Azure, which, if true, would prevent any backend (API) or front-end (web app) usage of client-side (RDLC) reports:

statement on official Azure blog

While Local Processing Mode may not be officially supported by Microsoft, fortunately, packaging all of the dlls comprising ReportViewer as part of Azure Web Site/App deployment makes it work.

Microsoft Azure Web Sites/Apps (app/api) currently don’t have ReportViewer installed in their servers’ GAC. So, to make use of ReportViewer, the three dlls comprising it have to be referenced and deployed as part of the application:

1. Microsoft.ReportViewer.Common
2. Microsoft.ReportViewer.WebForms
3. Microsoft.ReportViewer.ProcessingObjectModel

(NOTE: WinForms-based ReportViewer won’t work when hosted in Azure as it’ll be looking for a whole slew of other dependencies that are absent, but it’s easy to switch to the WebForms one.)

Since Microsoft created NuGet packages for the first two, it’s best to reference them using NuGet

Microsoft-built NuGet packages for Common and WebForms DLLs (unclear why ProcessingObjectModel is missing)

It’s puzzling why ProcessingObjectModel dependency is missing from their NuGet packages, but it still must be referenced from a non-GAC location and included as part of the deployment to Azure. Whenever ProcessingObjectModel is missing, the web app/api will throw somewhat misleading exceptions like the following (which are even more misleading if none of the ReportViewer dependencies are included as part of the deployment package):

An error occurred during local report processing.
The definition of the report 'D:\local\Temp\tmp38A6.tmp.rdlc' is invalid.
An unexpected error occurred in Report Processing.
Could not load file or assembly 'Microsoft.ReportViewer.ProcessingObjectModel, ...' or one of its dependencies. The system cannot find the file specified.

After installing Report Viewer Runtime, ProcessingObjectModel will be hiding under the following folder:
(NOTE: Make sure to install the same version of runtime as the Common and WebForms references added using NuGet — i.e. 11.0.0.0)

C:\WINDOWS\assembly\GAC_MSIL\

The last remaining roadblock to extracting and referencing ProcessingObjectModel dll is the GAC Cache Viewer shell extension: By default, Windows hides GAC subfolders and only displays custom GAC viewer under assembly folder, preventing direct referencing or copying of the installed dlls.

Windows GAC view hiding raw GAC_MSIL folders and DLLs

Fortunately, there are several ways to gain direct access to underlying subfolders and dlls by either disabling GAC view of the assembly folder, mapping its subfolder to another drive, or simply directly browsing to the subfolder using Start =>Run (or its equivalent in Windows 8/10/Server):

Start=>Run=>C:\Windows\assembly\GAC_MSIL way to access the hiding folders and their DLLs

After gaining access to all of the subfolders under assembly folder, ProcessingObjectModel dll can be copied and directly referenced inside the web app/api project:

Raw view of GAC assemblies

After referencing the remaining ProcessingObjectModel dll, make sure that all three ReportViewer assemblies have Copy Local property set (so they are all included as part of the deployment), and finally publish to Azure.

Ensure Copy Local = True on all three ReportViewer references

Hopefully ReportViewer will be fully supported out-of-the-box in one of the upcoming Azure updates.

REFERENCES

1. Microsoft article stating that ReportViewer is not supported in Local Processing Mode in Azure Web Sites/Apps (04/14/2016): https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-classic-sql-server-reportviewer/
2. Three ways to disable GAC viewer and access raw files: http://geekswithblogs.net/pavelka/archive/2006/05/05/WindowsExplorerAndTheGlobalAssemblyCache.aspx
3. How to map GAC subfolder to virtual drive using subst command: http://weblogs.asp.net/jkey/3006
4. Report Viewer Runtime installer (get the version matching NuGet): https://www.google.com/search?q=microsoft+report+viewer+runtime&gws_rd=ssl
5. Post that set me on the right path, but which is missing a couple important steps: http://kyawlo.blogspot.com/2011/07/dll-missing-with-rdlc-reportviewer.html