SharePoint 101 C. The SharePoint Development Models (server side, client side, apps) & Tools

As a developer, SharePoint almost gives you too much choice.

Key concept: customization

• Ghosted vs unghosted, Uncustomized vs customized
• Using SharePoint Designer for prototyping, quick fixes and customizations

Server-side development overview

• Solution packages
  • Visual Studio project template (full-trust solutions)
  • Adding a solution package to the farm with PowerShell
  • Deploying a solution package:
    • through the Central Administration UI
    • with PowerShell
    • with Visual Studio
  • Deploying DLLs to the GAC
  • Technet: Deploy solution packages
  • Quick reverse-engineering win:
    • Save a SharePoint site as a .WSP site template file through the Site Settings and then import it as a Visual Studio SharePoint project.
    • MSDN - Walkthrough: Import Items from an Existing SharePoint Site
• Features and modules
  • Feature scopes
    • Blog: SharePoint 2010 Feature Scopes & Activation
  • Modules: file and component provisioning
  • The pitfalls of Default Activation Profile
  • Why you should avoid SharePoint's XML definitions
  • Feature event receivers
  • Writing intelligent, idempotent, self-healing feature activation code
• Why you should avoid Visual Studio-based deployments
  • Using a /sites/deploy site collection as deployment target + Using a separate site collection for your actual testing
  • Scripting your deployment & setup sequence
    • A sound strategy if you want to easy deployments when you leave your development environment
• How to debug server-side solutions
  • Hooking up to PowerShell.exe
  • Hooking up to w3wp.exe processes
  • Remembering to restart application pools, PowerShell.exe and OWSTimer.exe after deployments
• Exercises:
  • Package your first feature in a WSP and deploy it
  • Debug your first feature event receiver (through PowerShell.exe and w3wp.exe)

References:

• MSDN: The Farm Solution execution model
• Debugging SharePoint Solutions
• GSoft Dynamite's wiki: On the evils of Visual Studio-based deployments

Client-side development overview

• A bit of history: sandbox solutions in SharePoint 2010
  • MSDN Sandboxed Solutions Reference
  • MSDN Blog: In-depth Sandbox Solution development guide (SP2010)
  • Long story short: In SharePoint 2013 (where Sandbox Solutions were re-branded as NCSS - No Code SharePoint Solutions), for most cases, Sandbox Solutions should be avoided in favor of App development. They may still be useful in some corner cases - see additional Reference below.
• CSOM & JSOM
  • MSDN - How to: Complete basic operations using SharePoint 2013 client library code
  • MSDN - How to: Complete basic operations using JavaScript library code in SharePoint 2013
• SharePoint REST API
  • MSDN - How to: Complete basic operations using SharePoint 2013 REST endpoints
  • MSDN - REST API reference and samples
• The App model
  • MSDN - Overview of apps for SharePoint
  • Provider hosted vs. SharePoint hosted
  • The App Web vs. The App Host Web
    • Host webs, app webs, and SharePoint components in SharePoint 2013
  • App permissions vs User permissions
    • App permissions in SharePoint 2013

References:

• MSDN - SharePoint 2013 .NET Server, CSOM, JSOM, and REST API index
• MSDN - Apps for SharePoint compared with SharePoint solutions - Apps vs. NCSS (i.e. Sandbox) vs. Farm solution (i.e. server-side)