Why Reflector is a Developer's Friend

If you have been wondering why some .net developers rave about Reflector as the one tool that rules them all, and have thought that maybe you should give it a try, here's a little tale about how it made my day better... (hope it encourages you)

Whilst attempting to bind an SPGridView to a LinqDataSource, one of the requirements was to use the filtering features of the SharePoint gridview (that's one of it's strengths above the standard GridView control).

I came across a post by Robert Fridén that described how to enable filtering when binding to an ObjectDataSource. An SPGridView property named FilteredDataSourcePropertyName needs to be set, and that must contain the name of the property on the bound datasource which will be called when filtering the data. In other words, it requires a string containing the name of a control property.

For an ObjectDataSource, that property is named "FilterExpression". I decided it was highly unlikely that the LinqDataSource would use the same property name, so I turned to Reflector.

In Reflector, I found and opened the System.Web.Extensions dll, browsed to the LinqDataSource class and then looked through the properties. Didn't need to right-click and disassemble the dll in this case, as one of the properties was named "Where". Sounded a good option for filtering. So I used that as the FilteredDataSourcePropertyName value, played around a little with the FilteredDataSourcePropertyFormat property of SPGridView, and hey presto the filtering worked. Sure, I could have looked through the MSDN documentation, but with Reflector I can browse inside the methods of the data source class if needed.

If you've not yet delved inside the .Net dlls with Reflector, give it a go. You'll be rewarded!

...and by the way, as tempting as it was I just couldn't bring myself to put the word"best" in the title ;-)