Two things happened this week: I finished this book, and realized that it was already obsolete. Damnit. I’ve been laying this egg since my SharePoint 2007 days, when deployment issues started keeping me up at night. The code you’ll read about here has been worked and re-worked for years, and in the twilight months of SharePoint 2010 (just before the 2013 preview bits became available) I started writing it all down.
My egg hatched just as 2013 came out, so I decided to re-do everything from scratch in the latest version SharePoint, as well as Windows Server (2012) and Visual Studio (2012). Unfortunately, that took forever. But more unfortunately, while I was busy ensuing that the code, the scripts, and the SharePoint knowledge and paradigms I had been cultivating were upgradable to 2013, I wasn’t paying much attention to the new app model. Just as long as I didn’t fall behind the learning curve of the new stuff, I assured myself, it was prudent to be productive when my first SharePoint 2013 project came up. I might not be able to build apps, but I’ll be ready to rock out an intranet. Then once I had adjusted to the water’s temperature of SharePoint 2013 on a few “conventional” projects, I’d be ready to dive into the deep end of the pool with some apps. So that’s what I did. It turns out 99% of my 2010 stuff worked fine in 2013; a few remote corners of the SharePoint Search APIs needed some tweaking and that’s basically it. Like I said, it just took a long time to re-do everything (getting used to a new OS and IDE, taking new screen shots, etc.). While I was busy with that, I wasn’t reading the writing on the Microsoft wall: 2013 would be very, very different from SharePoints past. Although the old 2010 code worked, farm solutions as we know them have been “marked” for obsolescence. They are still supported, but Microsoft is ushering us into the cloud and seems very committed to having us convert all of our provisioning code, features, web parts, and WSPs to PowerShell commandlets, apps, app parts, and package manifests. They say that too much custom functionality is causing customers to fear upgrades. And I don’t doubt it; I’ve seen a lot of very poor implementations that have left farms un-restorable, let along un-upgradable. SharePoint is too easily sold and .NET developers (as opposed to SharePoint developers) are too easily staffed against it. It only takes a few memory leaks or jQuery hacks to bring a site to its knees; combine this with years of divergence from best practices and poorly-trained content authors and I can’t imagine an upgrade going smoothly. The real irony here is the fact that the whole point of this book is to help make SharePoint environments more sustainable by using the server object model to build everything out all neat and tidy. If you factor the SharePoint API out of this equation, there’s really no more equation. If you’re upgrading from 2010 (or simply staying there) and don’t plan on rewriting the site to use apps, this book is still relevant for you. If you want to master SharePoint’s backend technologies and streamline their deployments, this book is still relevant for you. If you are going to build a traditional intranet in which the app model doesn’t quite meet your needs, this book is still relevant for you. Basically, if you are going to be anywhere near the server object model, please keep reading: build a site that’s deployable, and by extension upgradable. Follow best practices and write code that won’t only be “future proof” but will, as I like to say, even work on Mars. And by all means, write some apps! I just don’t think that farm solutions, and all the customizing power they imbue developers with, are done seeing the light of day. And until they are completely eclipsed by apps or whatever else is coming, let’s build them in the smartest way we can!