Nate Johnson had a bad experience with Visual Studio-based SQL Server Reporting Services projects:
So, what have we learned? Well, for one, this is a crappy situation born of poor in-product support. I should be able to configure Solution-level shared Data Sources, use them in as many Projects (within said Solution) as I want, and have VS configuration management support them; bonus points for doing so with saved & encrypted credentials. Ideally, when we check this into source-control, we’d check in the “DEV” environment flavor connection-configs. Then, when the reports get deployed to the “PROD” SSRS server, the same globally shared Data Sources are already present (and they don’t get over-written, thankfully by default!), configured by the DBA with prod credentials, and nobody in the development pipeline needs to know said credentials. Yay?
Not exactly a ringing endorsement.
To be fair, it’s not all bad, and it’s still better than using Report Builder w/ no source-control. It’s just frustrating to not have native multi-project-shared Data Sources support. =)