How hard is it to write Reporting Services extensions?

Obviously the answer to this question is fraught with conditions and dependencies. In general terms, this would be my answer (from easiest to most difficult):

 

Data Processing Extensions: Built on the same framework as ADO.NET, a Reporting Services data processing extension models .NET data providers in many ways. They are fairly straight forward to build and because they are based on .NET data providers, there is ample documentation and resources to support them. Obviously, you can make it as complex and powerful as you want, but as a rule, they are not hard to build. The documentation for Reporting Services includes a sample, however, that sample does not cover the use of data extensions that handle parameters. This is the only area where it gets confusing. Hopefully we will include a more comprehensive sample in the future. Developers with some experience with ADO.NET and .NET data providers should be well on their way to implementing a data processing extension.

 

Delivery Extensions: Unique to Reporting Services, delivery extensions can appear a bit overwhelming at first, but they really are simple once you get down to it. A delivery extension supports extension settings, which are used to drive subscriptions to reports. In addition, developers must implement the Deliver method which actually handles delivering the notification. Once again, there is a sample available with the Reporting Services documentation which should give you an idea of what they are all about. If you follow the sample and its logic, you should be able to write a delivery extension of your choosing with little or no problem. Once again, it can be as complex and feature-rich as you need it to be.

 

Security Extensions: Unique to Reporting Services, but based on technologies that ASP.NET developers should be familiar with, security extensions present a unique challenge. The difficulty does not lie in developing or understanding them, but in deciding when and how to use them. In addition, they are hard to deploy. Deploying a security extension touches just about every configuration file imaginable. The Reporting Services team is close to releasing a technical article and comprehensive sample that should shed some light on these types of extensions. Currently, the only type of security extension that has been written or conceived of is a Forms Authentication extension, which provides Forms-based ASP.NET authentication and then models Windows authorization. Security extensions are for intermediate to advanced developers with knowledge in ASP.NET Security, Forms Authentication and role-based security concepts.

 

Rendering Extensions: Also unique to Reporting Services, rendering extensions are the most difficult of the extensions to develop. Even the most talented developer will find rendering extensions a bit overwhelming. The difficulty lies in the understanding of the report object model and the sheer number of APIs. If you want to develop one, it might help to travel to Microsoft's main campus and stay for a month or two while you work alongside Reporting Services developers. There is no documentation and there are no samples available yet. An alternative to writing a rendering extension might be to first render to XML and then apply an XSLT or simply live with the rendering extensions that Microsoft provides (new ones are in the works). These aren't impossible to write by any stretch of the imagination and many third party developers are getting up to speed. It will definitely help when we release an official version of the rendering extension documentation. Just be prepared for a tough road ahead when developing these suckers.