I'm disappointed not many people here seem active with Reporting Services. Is that a sign of just lack of use, or that it did not meet expectations?
Here is where we are. I had someone well versed in ASP and ASP.Net pages try to use it for a complex reporting project that we needed done. The task was to produce a variable sized spreadsheet of data that would be used as something like a PO to vendors. Of significance is that it needed to be displayable as a web page and also be able to produce an excel file to ship off, so the export-to-excel feature was very handy.
It worked very well. She was frustrated it took so long to learn it, cursing the documentation, but from my perspective it was about 3 days to get a working prototype including server-side production of the excel download. This means NO NEED FOR AUTOMATION WITH EXCEL. We have fought so many battles with reasonable approaches to export web data to excel it is sad -- OLEDB works the best, but is limited in what you can do, CSV an similar is very limited in formatting and fairly tied to web upload, and automation works best but seems practically impossible to make work reliably server side (and microsoft agrees and recommends against it).
Reporting services seems to solve that.
Deployment is still not done, but we think we have a strategy. For us the web server will also be the report server, so we are going to treat the output RDL's as though they were web pages, and then when we deploy the web pieces we will run a script to upload them into the report server. The reports will then be a project in the general Intranet solution we have in VS2003. Or I should say projects -- you can't have any structure within a report project, so you are stuck doing multiple projects if you wanted (as we do) to basically have output web pages be reports. So I think we'll have a directory structure under a ASPX project, and a parallel structure of projects for the reports. That's ugly -- and not at all sure how many projects are practical in VS2003.
For separate, application-only (non-web-related) report projects we will do something else, not sure yet. But this so far seems the best bet for us to keep the reports tied to the web projects they relate to, and be modifiable and installable together with them.
I'd still love to hear what others are finding as good practices, especially in terms of deployment, version control in conjunction with associated applications or web projects, etc.