Sql Reporting (SRS with Report Builder and Report Designer) is really cool.  However, the other day I cracked it open to do some reports for an application I am working on and felt that it is already showing age.  This is not to slam SRS at all because it is great and progress happens in stages.  However, as always, progress in other areas has progressed so fast (i.e. linq, wpf, etc) that now using SRS seems a dated and difficult.  Here is my current list of thoughts:

• LINQ - Linq support tops the list. Linq with it's type safe entities, compile time checks, and simple syntax make you want to use it everywhere.  Have deep linq support (instead of text sql queries) seems a natural fit.  Report Data sources should be LINQ queries.
• Report Fields - The late-bound text based fields (e.g. =Sum(Fields!Sales.Value)) feels really old school and difficult to use.  No intellisense and no compile time checks make this an obvious need for improvement.
• DSL - The Domain Specific Language (DSL) functions inside reports takes us out of our language into a whole other language.  Things like =SUM(), DateDiff(), DateAdd, etc, are all specific to reports.  What we really need is to have all expressions be lambda functions so we have use our .Net language of choice and framework to return values.  Each expression would be a lambda that passes the current row as a stongly typed object, such as:
     r=>(r.EndDate - r.StartDate).TotalMinutes
  Things like this are trivial with access to .Net, but more difficult with pre-cast set of Common Functions and Operators allowed in the Report.
• WPF and report controls - At this point, it seems the whole report structure should be changed to use WPF instead of the one-off specialized designers used today.  Actually it has always confused my why a separate report designer was even used.  Reports and forms really kinda the same thing, and they should be designed with the *same designer.  All we need is a Table/Matrix WPF control and we can create reports right in the WPF forms designer.  This would allow you to create reports same way you create forms and leverage all the same tools and knowledge. You could create a report and import the XAML into an Expression tool, the designer could pretty-up the report and save new XAML back and report (i.e. form) just runs the same.  This would also allow you to "skin" reports with different styles for different needs (holidays, customers, etc)  We also have access to all the other goodness such as 3D, video, graphics, etc. Reports can then have all the interactivity of as any form, because it is just a form.  The XAML can get rendered on the server side or the client side using same WPF technology.  Export can be XPS, PDF, Excel as normal.  This seems like a no brainier to me with all wins.

Proposed Solution

1. Make a Table/Matrix report grid control for WPF. Now I can drop that on a form and hook up to its events and work in a very familiar way.
2. The grid's DataSource can be populated with Linq entity collections and will understand their nesting.  It would also understand and use *Named anonymous classes.  Names anonymous classes will need to be added to the framework.  This would allow us to populate the DataSource with a projection and use that projection in a type-safe way inside grid's events and grid fields.
3. Use Lambda expressions for field values instead of late-bound strings. This allows us to use the power and ease of the CLR.  Every field becomes a lambda (anonymous method) that returns a result. Standard textbox formatting can be applied as normal in other controls.
4. Create a new (XAML based) Report Designer that uses the same as above, but simplifies it for the simple and quick reports.  However the report still becomes XAML instead of RDL, so it can still be edited with Blend and/or the form designer to tweak and enhance.