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.
Now don't get me wrong: I'm excited for new challenges and new technologies and that's why I'm a developer. I love new toys; I love watching tools mature and increase their (and my) efficiency and performance. But lately, it seems like many "next" versions of technologies within the last year or so have ushered in a paradigm shift verses simply providing an expanded API or a reduced load time.
For example, let's look at database programming. When I was coming up, it was ADO.NET. And it kinda sucked: typed datasets, hard coded column names, etc. Then Linq-to-SQL (L2S) came out as an improvement to our database development experience: generated business logic, this crazy new Linq syntax, and a designer to manipulate entities. (In fact, entity designers are the only ones I use).
But ADO.NET wasn't deprecated! It was still there, driving all the pretty Linq sitting on top of it. And if something sucked to do in L2S (or was too slow) you could always crack open your own SQLConnection object and do it old skool. Then the Entity Framework (EF) came out as sort of a big brother to L2S with new features and tooling.
In all this time, I was still thinking about databases and business objects and relational data in pretty much the same way; it was the same paradigm, just with better tools and slight nudges in specific directions to new paths Microsoft was guiding us down. It was annoying at first, but gradually I embraced the new technology, since I wasn't forced to do so; now I'm a huge advocate of it.
That's how it should be done: gradually and on your terms. (Of course, we also do need to have a good attitude about the nature of things changing.) However, I also do dig the "time to upgrade" mentality we've been seeing from Microsoft, such as forcing 64 bit servers and, oh yeah, Windows 8. They need to thin out the herd of cattle that is old technology to make way for the new, shiny, speedy bits. Put simply, paradigm shifts are necessary in our industry, but they need to indeed be shifts and not tsunamis.
But telling us that we're suddenly "not supposed" to deploy any custom code that interacts with the server object model to our SharePoint 2013 farms? Tsunami! We're being guided to start converting as many web parts as we can to MVC (which is actually an exciting thing) and keeping our GACs pristine. That's cool right there; that's a paradigm shift, and actually a welcome new dimension of SharePoint development.
But no server side SharePoint code...at all? What about timer jobs? Or custom service applications? Or the 95 code samples you'll see in this book? Tsunamis! Now of course, server code won't void the warranty or anything, but it is, as far as I can tell, only there for "oh shit" moments when we're late and on fire and need to write some quick SharePoint code to save the day.
This was very tough for me to swallow. First, like I said, I had just finished this book to pimp the hell out of the server object model. Second, Microsoft.SharePoint.dll is like my fourth-best friend in the world; it's the only API that I feel like I've truly, honestly mastered. Seriously: the moment I'm comfortable referring to myself as an expert in an area, that area has to shuffle everything around and rip out its core and, consequently, a piece of my heart.
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. I'm sure I could (and will) convert all this deployment code to PowerShell and get over myself and be blogging about how much I love the new SharePoint 2013 paradigm in no time.
But I do need to make this final point: if you're installing software, whether it's on a production server or a tablet, would you rather be given an MSI file or a batch file to execute? PowerShell plays a ginormous role in this book, and I feel bad comparing it to DOS-y things. And it's stupid powerful. However, and maybe it's just me, but I always feel more confident when my work is given a thumbs up from the C# compiler.
So anyway, ranting now complete, it's weird to say that what you're (hopefully still) about to read is sort of obsolete. The new paradigm is going to be apps, and that's all I've been working on since I "published" this work. That said, I think there's still going to be a lot of time for traditional (dare I say "classic") farm solutions to rule the intranet day.
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!