[SSRS] Support msbuild as a mechanism for deploying SSRS reports - by Jamie Thomson

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


65
0
Sign in
to vote
ID 759938 Comments
Status Closed Workarounds
Type Suggestion Repros 2
Opened 8/28/2012 1:57:04 AM
Access Restriction Public

Description

The Microsoft development ecosystem uses msbuild as its build/deployment mechanism yet the SQL Server team's support is sadly lacking.
The engine team have gone a long way to supporting msbuild through the provision of .dacpacs & SSDT database projects yet the SSIS/SSAS/SSRS teams are still lagging way behind. The teams that I work on embrace msbuild and Continuous Integration as a way to deploy their projects but getting these BI components work in the same way is very very hard.

Can I also suggest that you adopt the .dacpac/.ispac approach of the DB/SSIS teams respectively by providing a (say) .rspac file as a means for distributing the definition of a SSRS solution.

I have provided similar requests for SSAS & SSIS:
https://connect.microsoft.com/SQLServer/feedback/details/759939/ssas-support-msbuild-as-a-mechanism-for-deploying-ssas-cubes-models
https://connect.microsoft.com/SQLServer/feedback/details/759938/ssrs-support-msbuild-as-a-mechanism-for-deploying-ssrs-reports#details
Sign in to post a comment.
Posted by Mike Edenfield on 6/14/2017 at 8:50 AM
@Simon Warde: Deploying the reports can be done via PowerShell via the SSRS SOAP web services pretty easily. You need CreateCatalogItem() and SetItemDataSources().

The bigger problem is that you need to "build" the project to get reports targeted at the correct version of SQL... if you just try to deploy out of the source tree, and you're not targetting SQL 2016, it blows up.
Posted by MisterY on 11/24/2016 at 2:16 AM
Guys, the latest SSDT (2016) automatically updates the reports schema to 2016 version. We used to deploy the source version of the report files automatically but now that is no longer possible. The only way to get the correctly versioned output files is to build the projects. And not supporting building of .rptproj files is just great. Technically, we are now f****. Thanks a lot.
Posted by Simon Warde on 10/15/2014 at 4:54 PM
Strongly support this suggestion.

Every time I tell a DBA he has to deploy the shared data sources, shared data sets and reports manually, one by one, and then re-associate the data sources to the data sets and the data sets to the reports, a little piece of both of us dies.

But a bigger piece of me dies every time I think rs.exe can't be as bad as I remember and have another go at writing a deployment script for it.

rspacs - please!
Posted by Jack Corbett on 2/3/2014 at 9:37 AM
I'm currently fighting with this for SSRS. Any deploy that we do will include database and SSRS parts and I haven't found a good way to include those in a single process so that it is simple for anyone to do.