Click here to Skip to main content
12,999,633 members (43,604 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


3 bookmarked
Posted 3 May 2013

SSRS Production Deployment, Part 1

, 3 May 2013
Rate this:
Please Sign up or sign in to vote.
SSRS production deployment


So, you built your shiny and flashy SSRS report, and you hit “Deploy” in BIDS, or “SQL Server Data Tools” in newer versions. Your UAT is a breeze, and everything looks great. The million dollar question now becomes

How do you deploy your reports to production?

In most “enterprise” environments, “production” means “no direct access for developers”. Any changes to production must be carefully documented and performed by dedicated people: release managers, system administrators, DBAs, etc. These dedicated people typically do not have BIDS on their desktops, nor do they want to. Thus, simply telling them to open the project, right click and hit “Deploy” won’t work. Whatever BIDS does when you hit “Deploy”, you’ll need to duplicate it in some way that works without BIDS. This is easier said than done, because, as it turns out, “Deploy” does quite a few things under the covers.

Scripting SSRS

But first off, how do you script SSRS in the first place? It comes with the rs.exe utility which on my machine is located at "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\rs.exe" (your location may vary), and is described on this MSDN page.

The “script” file that rs.exe accepts is regular VB.NET code that can call methods on a global rs object, which is actually a proxy to SSRS web service. You can put any valid VB.NET statements in your script, including reading files, opening sockets, and the like.

WSDL definition for the SSRS web service is located at
http://reportServerName/ReportServer/ReportService2005.asmx?wsdl for 2005 version of the protocol, or at
http://reportServerName/ReportServer/ReportService2010.asmx?wsdl for 2010 version.

In fact, all rs.exe does is:

  • Download WSDL from reporting server
  • Create a proxy class (perhaps using svcutil)
  • Read your script
  • Surround it with some extra code that defines the rs variable
  • Compile and run

These steps are executed on every invocation of a script, and may take quite some time. Another limitation is that you must use VB.NET, C# is not supported. Also, you can’t have any Imports directives in your code, because it gets surrounded by the code generated by rs, and Imports in the middle of a class are not allowed. So, if you use classes like System.Xml.XmlDocument, they must be fully qualified.

If any of the above is an issue, you may want to bypass rs.exe and generate the proxy on your own. Simply create a console application and add a web reference to ReportServiceXXXX.asmx?wsdl. Your “script” will now be an executable file. The downside is that you lose dynamic compilation: quickly modifying the script “on the fly” is no longer an option.

But what exactly do you put in the script? This is going to be the topic of Part 2.


This article, along with any associated source code and files, is licensed under The Apache License, Version 2.0


About the Author

Ivan Krivyakov
Technical Lead Thomson Reuters
United States United States
Ivan is a hands-on software architect/technical lead working for Thomson Reuters in the New York City area. At present I am mostly building complex multi-threaded WPF application for the financial sector, but I am also interested in cloud computing, web development, mobile development, etc.

Please visit my web site:

You may also be interested in...

Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170624.1 | Last Updated 3 May 2013
Article Copyright 2013 by Ivan Krivyakov
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid