For those of you that don’t use Facebook to follow the Microsoft teams, I commented on a Facebook entry from the Denali team that pointed me to their new Denali blurb.
My initial comment:
So, it's hard to tell what's new here besides Crescent. Does this mean that Report Builder 4 is a null set? Did they incorporate cascading style sheets into BIDS? What about shared code modules? What about ReportViewer compatibility? There ...are a dozen questions but the website has few answers. Consider that my last webinar (as small cross-section of IT shops) had no-one using 2008 R2. Half were 2005 the rest 2008. There really has to be a compelling ($$$) reason to invest in a new platform.
So their response was to see the SQL Server Reporting Services Team Blog entry that describes the Denali release of SQL Server in more detail.
My response was as follows:
It does help. I helps me see that the Visual Studio ReportViewer sync issue might have a long-term fix (that's the good news). The bad news is the dependency on SharePoint as several of the new features require SharePoint integration. Unfortunately, I don't see a "Native to SharePoint" migration tool that can take the years of work invested in Reporting Services native mode to easily port the catalog and its configuration over to SharePoint. Consider that the vast majority of sites do not have SharePoint integration for a variety of reasons--and might not ever have it.
Crescent also depends on SharePoint. I also didn't see anything about the other features report developers have been asking for including cascading style sheets, better parameter management, scheduling groups of reports and more. I don't see common solution properties in BIDS or better integration of DLL expressions. I'm afraid you've been working on features that too many of the smaller companies and independent departments within larger companies can't use--not without expensive re-tooling to use SharePoint.
After having read the team blog, I find that Report Builder 3 still lives but it’s renamed “Report Builder”. It also seems that there isn’t a new version of RDL—they’re sticking with “2010” but that’s not certain. They don’t say if Report Builder can work with more than one version of RDL—somehow I think that it’s still tied to one generation of RDL. Microsoft also announced that BIDS has been incorporated directly into Visual Studio, so the cross-campus dependency is less severe and they should be able to re-integrate “…within weeks” of Visual Studio’s next release.Thanks—it’s about time. Once Denali is released, ReportViewer applications will no longer have to be second-class citizens—always a generation behind. I wonder if they have added the ReportViewer control to the set of controls available for WPF applications. That would also be nice.
But I didn’t see any indication Microsoft added the ability to set properties on a solution-level to make it easier to build a single multi-project solution to map to large (or the entire) Reporting Services catalog. But that would be integrated into the low-level details and probably not mentioned in the blog. I also don’t see mention of better support for external DLLs like inclusion of VB class-projects in BIDS. I’ll look again once I install Denali. The point is, there is so much that needs to be done—things that ordinary report developers and DBAs need. I don’t see mention of the ability to share common-use code block between reports in lieu of creating and deploying DLLs. Where are these features?
As with other groups at Microsoft, the Reporting Services team seems to be caught up in the frantic SharePoint enthusiasm driven by the largest clients that, for the most part, does not extend beyond Redmond. Sure, I expect a number of larger companies have embraced SharePoint and it’s been improved over the years (from a very rocky start) but it’s expensive to implement, it’s performance is challenged and it’s difficult to manage—at least that’s what I hear from the field. But many, if not most smaller companies I work with can’t afford to start over from scratch to retrain, reinstall, redeploy, retest and all the rest required to add SharePoint and SharePoint integration. At to what end? Will the inexperienced Crescent report tool solve their problems or return enough productivity gains to justify the migration?
So before Microsoft encourages another company to make the cross-continent journey to SharePoint nirvana, they need a migration tool to make it drop-dead easy to transmogrify their native catalogs to SharePoint. They also need to figure out how to make SharePoint easier to install, configure and manage—not to mention run on a par performance-wise with native mode (good luck with that). In other words, they need to build the bridges and railroads before selling land in far-away lands.
In my humble opinion, like the Visual Studio team that’s focusing on Entity Framework (that the vast majority of their customers don’t or can’t afford to use), the SQL Server Reporting Services team seems to have created a new version of Reporting Services that builds the foundations for new features on uncertain ground before finishing the ones they created in the last two versions.