Another SharePoint Conference has come and gone and it’s time for the obligatory wrap-up post (at least what I can remember). This was a very busy conference for me, almost to the point of being overwhelming. I caught some sessions live and got to spend time with my colleagues from Portal and Pluralsight, but I didn’t get nearly enough time to spend with the seemingly endless number of other people I knew at the conference.
Being an MVP, I had early access to the beta/preview bits and to training so I came into the conference with a solid understanding of the App model. What I wanted to see was if the messaging from Microsoft had changed since I wrote SharePoint 2013 Development–Microsoft has their Heads in the Clouds. It was very clear from the start that it had not – the developer sessions were all Apps and all Office 365. Aside from a brief comment here and there and one demo in one session, you wouldn’t have known that the Solutions model (farm and sandbox solutions) even existed. Also, all of the demos I saw were done on Office 365 and the presenters made claims and comments only applicable to Office 365 without qualifying that was the case. They seemed to assume that everyone had or will be moving to Office 365.
While the conference was going on I saw several Tweets and participated in or overheard conversations from attendees confused by what they had seen. Hopefully the following will help address some of the misconceptions and misunderstandings:
- Farm and sandboxed solutions are still viable options in SharePoint 2013. Apps are an alternative to solutions, not their replacement.
- Visual Studio 2012 has almost the exact same tooling for building solutions for SharePoint 2013 as Visual Studio 2010 did for SharePoint 2010.
- You can still build and use web parts in SharePoint 2013. App parts are an alternative, not their replacement.
- Unless you only plan on building Apps for Office 365, you will need to install SharePoint on your development machine.
- Apps cannot do everything farm solutions can do. While there have been significant extensions to CSOM and REST APIs, the Server Object Model is still more powerful and extensive.
- Napa is a tool for learning and prototyping. It is not meant to be used to build production Apps.
I want to make it clear that I am not anti-App. I think the App model makes a lot of sense in several situations, I just don’t think it make sense in all situations.