Is it necessary to build/compile SSRS reports?

Question

We have a 2008 R2 native installation of SSRS. I usually develop reports in one big visual studio report server project and manually upload the .rdl files via the front-end of the SSRS web site. However, I've noticed that you can build debug/release versions of the .rdl files. The only difference I've noticed so far is that the compiled .rdl is 2KB bigger than the "raw" .rdl - no performance gains noticed, etc.

Does anybody know the difference between using a raw .rdl and a compiled .rdl?

Answer 1

There are no raw vs compiled rdl in Visual Studio.

The confusion comes from other project types in Visual Studio, because every .NET developer know that there is a difference between a dll/exe if you compile it with or without the "Optimize code" checkbox.

Even if the term "build" is present in the SSRS documentation, it is easier to consider that RDL reports are not built (at least not before deployment), because building a report is a totally different thing than building a .NET application.

Reports are built before they are published to ensure that only valid report definitions are published to the report server. Project configurations include properties for building reports, such as the folder in which to temporarily store the built reports, and how to handle build issues. The configurations also have properties that you use to specify the location and version of the report server, the folders on the report server.

Source: Publishing Reports to a Report Server

Here, built should be seen as a validity check.
EDIT 2017-10-25: but not only, see the comment below from Michael Edenfield.

When are reports compiled?

When you view the report.

Stages of Report Processing

When you create a report, you define a report definition file (.rdl) in XML format. This file contains all the information that is needed to combine report data and report layout by the report processor. When you view a report, the report progresses through the following stages:

• Compile. Evaluate expressions in the report definition and store the compiled intermediate format internally on the report server.

• Process. Run dataset queries, and combine intermediate format with data and layout.

• Render. Send processed report to a rendering extension to determine how much information fits on each page and create the paged report.

• Export (optional). Export the report to a different file format.

Source: Reporting Services Reports (SSRS)

Here is a diagram showing an overview of the report processing:

Compiled report and intermediate report format

The report that uses evaluated expressions, parameters and parameter properties evaluated.

Source: Reporting Services Concepts (SSRS)

What are the Debug/Release configurations used for?

In solution/project configurations, you can store deployment settings, such as the target server URL, report path and so on.
You can use the standard one, for example use Debug to publish reports to a test SSRS server, and Release to publish reports to a production SSRS server.

SQL Server Data Tools (SSDT) provides project configurations for managing report publication. The configuration specifies the location of the report server, the version of SQL Server Reporting Services installed on the report server, whether the data sources published to the report server are overwritten and so forth. In addition to using the configurations that SQL Server Data Tools (SSDT) provides, you can create additional configurations.

Answer 2

Yes because if you don't you'll run into problems when your dev environment gets newer than your rusty old SSRS server.

SSRS 2014 report deploy issue

The bin folder copy is downgraded to a schema to match the one specified in the project properties.

This is completely bonkers as really it should just not upgrade the reports in the first place but expecting SSRS to do anything sensible is like expecting pigs to fly.

Time lost: ~1 week. I too once deployed from the source folder.