Custom Report Items not supported in SQL Express & Workgroup Editions

Saw an interesting conversation today around custom report items in SSRS. The information isn’t a huge surprise, but at the same time is not documented in books online, either: Custom report items will only work inside Standard | Developer | Enterprise editions of SQL Server 2005.

Comments (1)

  1. Lisa Slater Nicholls says:

    Hi Russell —

    I’ve run into a snag in my work creating/using a custom report item that I thought maybe you could comment on or point me in the right direction… I’ve posted a question to John G as well and described the situation pretty fully in a forum post (, but something I read in your blog (re formatted HTML) makes me want to post it to you too.

    The general issue is this: I want to create a custom property for a standard (not a custom) report layout control.  It turns out that the best way to allow this within the standard report designer interface is to create a design-time-focussed report custom item and create some UI that is accessible from there.  I am running into difficulties doing this if the standard item does not have at least one other CustomProperty already defined. The standard controls don’t seem to expose their CustomProperties members properly… or I can’t see how to get at them.

    Why would I want to do add a custom property to a standard item in the layout?  Look at the formatted HTML discussion in response to one of your other blog posts.  Although it is not my use-case, it’s a good example of something that should be solvable with a little help from a custom property.  If one could tag a standard textbox as containing formatted HTML, or rich content of some other type (say, RTF), any renderer that recognized the tag might choose to treat it differently from all other textboxes.

    So here’s the problem: a report custom item can easily have its custom properties adjusted, that’s all nicely exposed.  But to get at another, standard control in the same layout within designer code I haven’t found a better way than to do something like this (I’ll post C# code here, since I posted a VB example to the forum):

    host = (IDesignerHost)this.Site.GetService(typeof(IDesignerHost));

    comp = (System.ComponentModel.Component)host.Container.Components[itemName];

    RSDesigner.CustomProperties p = (RSDesigner.CustomProperties) comp.GetType().InvokeMember("CustomProperties", BindingFlags.GetProperty, null, comp, null);

    This code works fine, and as long as the item already has at least one custom property already, there is no problem, I can add some more.

    But if the item doesn’t already have any custom properties, I would have thought I could set up the member at that point (this may not be exactly right, I’ve tried a huge number of other approaches, BindingFlag combinations, etc — but nothing works):

    if (p == null)


     p = new RSDesigner.CustomProperties();

     comp.GetType().InvokeMember("CustomProperties", BindingFlags.SetProperty, null, comp, p.ToArray());


    … I always get a MissingMethod exception.  That doesn’t make sense for a property — unless there’s some security issue I’m missing causing this type of error to come up for some obscure reason. That also doesn’t make sense considering that the control otherwise does exactly what it’s supposed to do, writes successfully to the RDL, etc.

    Maybe I just don’t know what to cast the component to, to do this successfully.  But what exposes the standard items’ CustomProperties (or CustomPropertyCollection, or whatever) ?  Remember this is a ReportDesigner scenario — I don’t think I should be using classes from ReportBuilder off in SQL Server territory, although some looked promising.

    I have a really dirty workaround, in that as long as the RDL report element has at least one CustomProperty manually created, I can write all other ones to that CustomProperties location, with Name elements that indicate their "real" control owners… so I can error trap for the null and ask for the user to go into the RDL XML manually to put in the dummy. But I’m sure that wasn’t what is intended.

    What am I missing? If nothing, I guess my real question is this: what is the point of custom properties for standard items if we can’t easily create them at design-time?  

    Thanks in advance for taking the time to read this.