Reverse Alchemy

Recently I’ve been working a lot with the SharePoint standard templates. A client wanted us to build a Web Part that had the look and feel of a standard SharePoint Web Part and the easiest way to achieve that was using templates. Using these, we didn’t have to worry about custom fields, save buttons, validation and all the other goodness that SharePoint has to offer.

The project was progressing nicely. We inherited from some of the standard SharePoint controls to extend their behavior, like the Save button. Everything worked absolutely fine until we send the first version of the Web Part to our customer. Within a few hours a response came back; the Web Part did not work. Attached to the bug report was a screenshot with the “error message”: a NullReference exception. If there’s any exception I hate with all that is in me it is this one. It just doesn’t provide any information at all about what went wrong. Is it truly that hard to tell me just which object was null?

Anyway, it took us a while to figure out that the customer was using a Dutch language pack, and this was what was tripping up our Web Part. If he installed it on an English instance of SharePoint everything worked fine. Weird. We weren’t using any localization that was not part of the standard SharePoint template we had used as the basis of our work (for those interested, we used the UserListForm).

I will spare you the gory details of what we went through trying to figure out what was wrong. Eventually I simply started commenting out every control in our custom template one by one. If the error went away, I would have found the culprit. Crude, but it worked. The fault turned out to be in a single line of the template:

<SharePoint:CompositeField FieldName="Name" ControlMode="Display" runat="server" />

The why was just as elusive. The template used by the CompositeField didn’t lead us anywhere, nor did .NET Reflector’s help in looking at the source code. Again, we were mystified.

Until inspiration struck. Looking at the line of code I started wondering why there was a hard reference to a field called “Name” in there. Usually, these keys are put into resource files so a different language can use a localized version of the key. So I figured I’d give it a try. I changed “Name” to “Naam” (which is the Dutch translation). And lo behold! The Web Part worked in the Dutch instance of SharePoint and crashed gloriously in the English instance, giving us the exact same error. For kicks, we installed the French language pack and changed the key to “Nom”. Same result.

The solution to the problem was surprisingly easy. We changed the above line to:

<SharePoint:CompositeField FieldName="<%$Resources:wss,viewlsts_title%>" ControlMode="Display" runat="server" />

The choice of the viewlsts_title was somewhat arbitrary (you’d be surprised how many resource keys have the value “Name”) but it seemed the most appropriate. After this, the Web Part worked great in any language we threw at it.

I still don’t know if this is a bug in the SharePoint code or in the language packs, or anywhere else. I do hope that our explorations will spare you the same.