Wait, There’s No Code-Behind File for a SharePoint Master Page?

I recently had a situation where our SharePoint 2010 site’s master page was emitting an empty DIV element that ruined the layout of several pages in the site. Although largely extraneous on most pages, the DIV and it’s child ContentPlaceholder control was required by a handful of pages on the site, so we couldn’t just delete it.

As an ASP.NET developer still relatively new to SharePoint, I thought that a simple fix would be to add code to the master page to suppress the errant DIV on pages where the placeholder wasn’t used. How hard can it be?

Server-side

I created a standard ASP.NET test site with a master page where I could prototype a solution. Had I bothered to Google, I’d have had working code in seconds as I was hardly the first person to encounter this situation, but it was still only a matter of minutes to put write it myself.

The other solution would be to add a script block to the master page. On the face of it, I’d prefer not to do this simply because I’ve gotten used to keeping my presentation markup and event-handling code in separate files. Even if I wanted to do that, SharePoint won’t let you; you’d get an error letting you know that “code blocks are not allowed in this file.” There is a workaround to edit the web.config file to disable that security feature (See SharePoint Page Types), but between loosening security restrictions and mixing code in with markup, the script block approach seemed the wrong way to go.

Client-side

At this point, the path of least resistance was to handle this on the client side, particularly since the jQuery library was already available on the site in question. With jQuery and a regex, this became almost a one-liner:

I’d have preferred to avoid a solution that involves downloading unnecessary markup to the browser as well as additional code to hide it. I know it’s only a few bytes—a drop in the bucket compared to the typical bloated SharePoint page—but it still bothers me, especially since the code is visible to the end user and I’m “airing my dirty laundry,” as it were. However, it’s working, so I’m not going to sweat it.

Server-side, take two

The brevity of the jQuery version got me wondering how terse and cryptic I could make a server-side version if I used Linq. Just for fun, here’s what I’ve come up with. It’s not as short as the jQuery code, but much more impenetrable than the earlier ASP.NET version.

I wasn’t sure that this would work the same way as my original code and terminate the loop as soon as it hit a non-whitespace character, but the documentation assures me that the All() method will stop “as soon as the result can be determined.”