A third-party report generator (Pebble Reports) sent me this IBM presentation (see page 71) when I asked if their tool supported 2005, 2008 or 2010 RDL (they only support 2005).
“We depend on ReportViewer control for printing purposes and we are as miffed as you are that ReportViewer is always out of sync with ReportServer. Even MS competitors are taking advantage of this situation, for example see slide 71 of this IBM presentation where they talk about Microsoft's version incompatibilities.”
This further adds to the argument that Microsoft is not seen as capable of keeping their various development paradigms and the metadata they support in sync. I pounded on this issue two years ago when Visual Studio 2008 was getting ready to ship. However, two years later Visual Studio BI and ReportViewer developers are facing the same lack of compatibility with the latest RDL (about to ship with SQL Server 2008 R2). Are developers expected to wait another two years before the ReportViewer control will work with RDL 2010 in local mode? By then I expect additional innovations to be out of reach as RDL evolves—leaving the ReportViewer control perpetually one version behind.
I also hear from other pundits (SQL Server Contributing Editors) that this is just the tip of the iceberg. Apparently, there are a number of other serious compatibility issues regarding data types and other issues that have not been addressed by the soon-to-be-released Visual Studio 2010 development tools.
I’m disappointed that MS has not done a better job keeping the tools and the engines like SQL Server in sync. Generally, I attribute this to the relatively short development cycle where versions of SQL Server and Visual Studio are pumped out in rapid succession as if they were new versions of a video game.
I’m also disappointed that very few changes seem to have been made to the litany of issues I’ve raised based on customer feedback that comes to me over the years. My customers work with data and the “ordinary” data tools exposed by Visual Studio. Not nearly all of them want to retrain on the unproven Entity Framework and while I’m told it has merit, I’m still unconvinced that I should endorse it given Microsoft’s penchant to create a product and then abandon it years later when they have dreamed up a “better” solution. Perhaps this emphasis on the new EF, the “traditional” tools have been left unrepaired, unimproved and generally ignored.
I was at a user group meeting the other night listening to Lisa Feigenbaum extol the virtues of the changes in Visual Studio 2010 for C# and VB.NET developers. I saw a number of innovative and glitzy features demonstrated—and yes some that I asked for many years ago. What I also heard in side conversations was that “Microsoft pretends to listen but does what it wants to do anyway.” and “While we try to reach people in the development teams to lobby for this feature or that, they aren’t there long enough to champion the features we’ve asked for given the turnover and reorganizations.” And “The new people at MS have their own personal agendas and want to make a mark on the product. No one wants to work on the old stuff, to fix long outstanding issues—the new stuff is more fun.” And “Yes, these are cool features, but it’s not what we asked for five years ago to fix our problems.” I hear these same stories from long-time Microsoft employees, pundits, trainers, authors, consultants, community developers all over the world, my clients and my students working in the industry. They’re bothered, hobbled or stopped cold by these issues—which is why I keep bringing them up.
What we got this time in VS2010 is a “new and improved” UI based on WPF—swell. It’s a bit slower than the old VS2008 UI and is mostly compatible, but it did give MS a chance to get some of the bugs out of WPF which is good for those developers that need it—most still don’t. We got C# and VB.NET with almost all of the same features but still no tool to import from one language into another (which is problematic as the majority of the examples are written in C#--especially for new technology). On the other hand, I can’t see any significant changes in how TableAdapters are built, how the Server Explorer works or how SQL Server Compact Edition (a star performer IMHO) is supported. These are “ordinary” tools that far more developers use or would like to use—far more than the EF or the giant corporation tools that seem to be the current focus.
For the last 20 years or so (working for Microsoft and since), my focus has been on the seam between the development tools like Visual Studio and SQL Server. I like to think my dozen books on the subject have helped developers learn to use these products as well as possible showing what works and what doesn’t. Over the last 8 years (since I left MS) I’ve had more feedback than ever about some pretty fundamental issues, but I have seen precious little done about them—and less at each new version. The same mistakes keep happening (like the RDL to RDLc disconnect and lack of support to capture a WHERE clause in the TableAdapter wizard).
I really don’t know if it’s worth the effort, but the people I support keep asking, so I keep prodding.