I’m sure somebody, somewhere, leverages SharePoint Chrome for displaying the most beautiful and elegant titles on well-designed pages. I, however, am not that person, and have never met that person. The workflow I was accustomed to was:
- Add Web Part to page
- Edit Web Part
- Change Chome to None
- Save & Close Page
- Check In
Something I ran into awhile ago and spent way too long digging out is enabling developer dashboard. “But Lefty, there are thousands of blog posts on this subject, are you dim?” you might ask. Nay, just picky. Most of the time, nobody cares how the admin side of their application performs. Normally if it’s slow, it only affects a few users. And normally those users are either the person or a direct report of the person that contracted the creation of that application. The slow, behemoth that is the admin side helps them further appreciate the nimbleness of the public side. In my experience, the best way to transform that slow behemoth into a nimble speed demon is the developer dashboard, and a liberal application of SPMonitoredScopes.
One common problem many people run into is debugging SharePoint 2010. Not just dealing with the many nuances, but actually just the simple task of attaching a debugger. Sometimes, you’ll go through the hassle of finding the right worker process, attach to it, and even though you are 100% certain the binaries you have recently complies are currently what’s running on the site, you don’t get the satisfaction of your red breakpoint completely filling in. You stare at the screen blankly in confusion. Confusion turns to rage. Rage turns into sadness. Sadness turns into acceptance. You reset IIS, reload the page, and try again. And suddenly, it works. If the definition of insanity is doing the same thing over and over and expecting a different result, SharePoint really does make you crazy, because it rewards such nonsensical persistence with different results. Continue reading