Whenever you are looking at building a custom solution for any platform, one of the things you will have to determine is what environment you will use to build your custom solution. This is no different when you want to create a custom solution for SharePoint. Determining the best way to set up your development environment has always been difficult for SharePoint, and SharePoint 2013 adds even more complexity to it, with extended hardware requirements and two new types of servers.

Let’s start by looking at the different server roles that you can choose from.

Although it is possible to build a development environment by using a standalone server installation of SharePoint on a single server without a domain controller or separate computer that is running Microsoft SQL Server, for practical reasons you will at least need a domain controller, a database server, and a SharePoint server. For certain types of SharePoint apps you might not need a SharePoint development environment, because these apps can be hosted on a generic web server that doesn’t have SharePoint installed on it. However, you should test what your app looks like in a SharePoint environment before you add the app to the production environment, so you should always use some sort of test or development environment.

If your development environment is installed in an existing domain, you don’t have to build your own domain controller; you can simply use an existing one. If you are creating your own domain, you will have to create a domain controller as well. You can create a single server and use that as the domain controller, the database server, and the SharePoint server. Be aware, though, that some things don’t work on a domain controller and some things have to be configured differently. It is important to keep this in mind while developing and testing custom solutions on your development server.

In SharePoint 2010, Microsoft Office Web Apps came in a separate installation that had to be installed on at least one of the SharePoint servers in the farm. After installation, they could be configured as service applications. In SharePoint 2013, this is no longer the case. Office Web Apps is now its own product. Office Web Apps has to be installed in its own separate farm, and it cannot be installed on a server that also has SharePoint installed on it, because Office Web Apps will completely take over the Internet Information Services (IIS) on the server. You can install Office Web Apps on one or more servers and connect the Office Web Apps farm to the SharePoint farm. Having Office Web Apps installed in its own farm on one or more servers means that it is now more scalable. The Office Web Apps farm can be connected to one or more SharePoint farms. This means that one Office Web Apps farm can support the SharePoint servers of several developers.

With SharePoint 2010, you automatically got the SharePoint 2010 workflow host, which was based on Windows Workflow Foundation 3. Windows Workflow Foundation was a native part of SharePoint, but the way in which it was implemented meant that customers who were serious about using workflow in SharePoint almost always ran into issues with scalability. SharePoint 2013 uses a new workflow service, which is built on the Windows Workflow Foundation components of the Microsoft .NET Framework 4.5. The new workflow service is called Workflow Manager and, like Office Web Apps, is a separate installation that should be installed on separate servers. After you have created a Workflow Manager farm consisting of one or more servers, you can connect this farm to your SharePoint 2013 farm. As with Office Web Apps, creating a separate workflow farm means that your environment will be a lot easier to scale out and a lot more suitable for use in a serious workflow solution or a large enterprise. Your old SharePoint 2010 workflows will still work, because SharePoint 2013 automatically installs the SharePoint 2010 workflow engine.

To summarize, if you want to have all SharePoint 2013 functionality available to you in your development environment, you will need at least three servers:

You can, of course, have many more: you could split out your domain controller, database server, and SharePoint server; you could have separate SharePoint web and application servers; and you can have as many Office Web Apps and Workflow Manager servers as you want. How many servers you use will mostly depend on the size of the solution that you are building, the type of functionality that you need, and—let’s face it—your budget.

Windows PowerShell scripts can be used to automate SharePoint installation and management. When you are using Windows PowerShell scripts to install SharePoint, it is easy to repeat the installation in exactly the same way. This is very useful when you have to create multiple development environments or multiple servers in a production environment, or when a farm has to be rebuilt after a system failure. Be aware that not all steps of the installation can be scripted by using Windows PowerShell, so you will still have to make sure that all steps are documented as well.

Using Windows PowerShell to manage SharePoint is very useful for repeatable tasks. When you use a saved script every time, the chances of human errors causing serious problems during maintenance decrease. Windows PowerShell can also be used to fully automate maintenance steps. It would, for example, be possible to create a Windows PowerShell script that creates a new site collection. The next step would be to add a couple of parameters and then automatically start the script. You could, for instance, start the script whenever a new project or customer is added to a Customer Relationship Management (CRM) system.

Though it is often convenient to use Windows PowerShell to install or configure SharePoint, in some cases you don’t have a choice because some functionality doesn’t show up in the user interface and can only be configured by using Windows PowerShell. Examples of this are the multitenancy features. The multitenancy features are a set of features that allow SharePoint to work as a hosting platform. They allow for operational service management of SharePoint for one or more divisions, organizations, or companies. Using the multitenancy features allows SharePoint to separate data, features, administration, customizations, and operations. In order to set up multitenancy in an environment, you have to set up site subscriptions, partitioned service applications, tenant administration sites, and (optionally) host header site collections and feature packs. All these features can only be configured by using Windows PowerShell.

If you need to install development environments on a regular basis—for instance, because you are working on different projects, or because you are working on a long-running project and developers are coming and going—it is worthwhile to create a Windows PowerShell script to install a development environment. Even if you would just use Windows PowerShell to configure SharePoint, this will save you a lot of time. It will also make sure that your development environments are always configured in exactly the same way. In addition to the fact that doing a scripted installation is often faster, this approach also allows you to do work on something else while the script is running.

There are two different tools in which you can write and run Windows PowerShell scripts: the Windows PowerShell console window or the Windows PowerShell Integrated Scripting Environment (ISE). To make the Windows PowerShell ISE available on your server, you need to install the Windows PowerShell Integrated Scripting Environment (ISE) Windows feature. You can do this by opening up the Server Manager, clicking Add Features, and selecting the ISE feature.

If you are using the console environment, you can either use the general console environment or the SharePoint 2013 Management Shell. You can access the general console environment by selecting it from the Windows Start menu. If it’s not on the first page, you can get to it from the Windows Start menu by simply starting to type PowerShell. This will give you the option to select one of the available Windows PowerShell tools and consoles.

Don’t pick the 32-bit version (x86); SharePoint is a 64-bit product. You can also go to the Windows Start menu to select the SharePoint 2013 Management Shell. You can find this in the same way as the general console; go to the Start menu, start typing PowerShell, and select the SharePoint 2013 Management Console.

These are effectively the same environment, except for the fact that in the SharePoint Management Shell the Microsoft.SharePoint.PowerShell snap-in has already been loaded. If you are using the standard console, you will have to load the snap-in yourself, by using the following command:

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"

You add the -ErrorAction “SilentlyContinue” mainly because the console will throw an error if the snap-in has already been loaded. You can ignore this, so it will look nicer if you hide the error. You can also play it safe and check to see whether the snap-in is already loaded before attempting to load it, by using the following:

$snap = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.PowerShell'}
if ($snap -eq $null) {
  Add-PSSnapin Microsoft.SharePoint.PowerShell
}

If you are creating a larger script, it is probably easier to open up the Windows PowerShell ISE, because this provides a better editing environment. You will have to load the Microsoft.SharePoint.PowerShell snap-in into the ISE as well. You can do this by using exactly the same script used for the console. If you find yourself using the ISE a lot, you can also add the snap-in automatically when the ISE starts, by adding it to the Windows PowerShell profile. The profile is a Windows PowerShell script file that runs every time you start Windows PowerShell. It has a .ps1 extension like any normal Windows PowerShell file, and you can put any valid Windows PowerShell cmdlet in it. The only way in which the profile file differs from a normal script file is in its name and location.

If you want to use the profile, you will first have to figure out whether a profile already exists on the server. You can do this by using the Test-Path cmdlet:

Test-Path $profile

If the profile already exists, the Test-Path cmdlet will return True; if it doesn’t exist, it will return False. You can also just run the $profile cmdlet and use Windows Explorer to browse to the path that it returns. If the file isn’t there, the profile doesn’t exist:

$profile

You can use the New-Item cmdlet to create a profile if one doesn’t already exist. -path $profile passes in the full path, and -type file tells the cmdlet that you are trying to create a file:

New-Item -path $profile -type file

When you open the profile, you will notice that it is completely empty. You can add to it any script that you want to always be executed before you start working on your scripts. This could, for instance, be a command telling Windows PowerShell to always go to a default location:

Set-Location C:scripts

Or you can add the Microsoft.SharePoint.PowerShell snap-in:

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"
$SolutionPackageName = "WingtipDevProject1.wsp"
Uninstall-SPSolution -Identity $SolutionPackageName -Local -Confirm:$false
Remove-SPSolution -Identity $SolutionPackageName -Confirm:$false

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"
$SolutionPackageName = "WingtipDevProject1.wsp"
$solution = Get-SPSolution | where-object {$_.Name -eq $SolutionPackageName}
# check to see if solution package has been installed
if ($solution -ne $null) {
  # check to see if solution package is currently deployed
  if($solution.Deployed -eq $true){
    Uninstall-SPSolution -Identity $SolutionPackageName -Local -Confirm:$false
    Remove-SPSolution -Identity $SolutionPackageName -Confirm:$false
  }
}

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"
$solution = Get-SPSolution | where-object {$_.Name -eq $SolutionPackageName}
if ($solution -ne $null) {
  if($solution.Deployed -eq $true){
    Uninstall-SPSolution -Identity $SolutionPackageName -Local -Confirm:$false
  }
  Remove-SPSolution -Identity $SolutionPackageName -Confirm:$false
}
Add-SPSolution -LiteralPath $SolutionPackagePath
Install-SPSolution -Identity $SolutionPackageName -Local -GACDeployment

In SharePoint Server 2010 the concept of service applications was introduced. SharePoint contains several different service applications, and all of them provide a specific piece of functionality to your SharePoint farm if they are enabled. All service applications can be shared across web applications, and some service applications can even be shared across farms. Let’s establish the terminology first.

A service application itself is the logical container of the service. We use the term service application to describe the services architecture in SharePoint. It is also what is exposed in the Central Administration site through the Manage Service Applications page. For most service applications, there can be more than one instance of the service application in a single farm.

The service instance is the actual implementation of the service, the binaries. A service instance could include Windows Services, configuration, registry settings, timer jobs, and more. The bits that make up the service instance are deployed to every SharePoint server in the farm.

The service machine instance of a particular service application is the server or servers in the farm on which the service for that service application runs. You can check where a service is running and start or stop a service on a particular server by going to the Services On Server page in the Central Administration site. On this page, you can select a server and then start the services you want to run on that particular server. When a service runs on more than one server in the farm, software round-robin load balancing is provided by SharePoint. Not all service applications have an associated service machine instance. Most service applications can have more than one associated service machine instance, but some can only have one. Not all services you see on the Services On Server page are service machine instances of a service application.

The service application endpoint is created when you start a service. Starting the service and thus creating a service machine instance creates an Internet Information Services (IIS) virtual application in the SharePoint Web Services IIS website. The virtual application includes a Windows Communication Foundation (WCF) or .asmx web service. This web service is the service application endpoint. Each service application must have its own service application endpoint.

A service application proxy (also called service connection or service association) is a virtual link between a web application and a service application. The service application proxy also enables cross-farm services.

A proxy group is a group of service application proxies that are selected for one or more web applications. By default, all service application proxies are included in the default proxy group. When you create a web application, you can do one of the following:

The custom proxy group for one web application cannot be reused with a different web application.

There are three ways in which you can configure service applications:

It is not recommended that you use the SharePoint Product Configuration Wizard to configure service applications. Using the wizard will create the service applications with a set of default settings that might not be suitable for your environment. If you use the wizard it is also very easy (as easy as selecting a check box) to create too many service applications. You should always just create the service applications that you need in your farm. Every service application consumes a certain amount of resources, so creating a service application that you don’t need means that you are burning valuable resources on your server.

To create a service application from the Manage Service Applications page in Central Administration, you start by clicking the New button on the Manage Service Applications page, as shown in Figure 2-1. Click Managed Metadata Service to create a managed metadata service application.

Figure 2-1. The Manage Service Applications page in Central Administration

On the next page, you enter a name for the service application and for the database that will store the contents and configuration of the managed metadata service application that you are creating, as shown in Figure 2-2. In this example, the name of the service application is Managed Metadata Service Application. The name of the database is ManagedMetadata. If this is the first service application that you are creating, you will also have to create an application pool that it can use. The name of the application pool in this example is SharePoint Web Services Default. This is the same name that the wizard would have used for the application pool that it creates if you use it to create service applications. In most cases, this application pool can be used for most if not all of your service applications. The account that is used in this example is the WINGTIPTOYSspservices account. Be aware that the account that you use as the application pool account must be a managed account. Go to the Configure Managed Accounts page in Central Administration to create a new managed account. All managed accounts should be dedicated service accounts. Selecting Add This Service Application To The Farm’s Default List means that SharePoint will add the service application to the default proxy group after you click OK.

Figure 2-3 shows the Manage Service Applications page after the managed metadata service application has been created. Creating the managed metadata service application through the Manage Service Applications page also automatically creates the managed metadata service application proxy. Most service applications automatically create their proxy when they are created through the Central Administration user interface. When Windows PowerShell is used to create the service application, you will almost always have to create the service application proxy yourself.

Figure 2-2. Creating a Managed Metadata Service Application

Figure 2-3. The Manage Service Applications page with the Managed Metadata Service Application and proxy

Some service applications start their service or services automatically, but for most service applications you will have to go into the Manage Services On Server page in Central Administration (shown in Figure 2-4). For the managed metadata service application, you will have to start the Managed Metadata Web Service on at least one server in the farm. In most development environments you will only have one SharePoint server, so you can start the service only on that server. Starting the service will also create a new IIS virtual application in the SharePoint Web Services IIS website. The name of the virtual application is a GUID, and the application will include the MetadataWebService.svc web service.

Figure 2-4. The Manage Services On Server page

Example 2-2 shows the Windows PowerShell script that will create the service application, the application pool, and the service application proxy and that will start the managed metadata web service.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"

$saAppPoolName = "SharePoint Web Services Default"
$appPoolUserName = "WINGTIPTOYSspservices"

# Gets Application Pool, or creates one
$saAppPool = Get-SPServiceApplicationPool -Identity $saAppPoolName -EA 0
if($saAppPool -eq $null)
{

  Write-Host "Creating Application Pool"
  # Create Application Pool
  $saAppPoolAccount = Get-SPManagedAccount -Identity $appPoolUserName
  $saAppPool = New-SPServiceApplicationPool -Name $saAppPoolName '
    -Account $saAppPoolAccount
}

$mmsInstanceName = "MetadataWebServiceInstance"
$mmsName = "Managed Metadata Service Application"
$mmsDBName = "ManagedMetadata"

Write-Host "Creating Managed Metadata Service Application & proxy"
$mms = New-SPMetadataServiceApplication -Name $mmsName '
    -ApplicationPool $saAppPoolName -DatabaseName $mmsDBName
$proxy = New-SPMetadataServiceApplicationProxy -Name "$mmsName Proxy "'
    -ServiceApplication $mms -DefaultProxyGroup
Write-Host "Starting Managed Metadata Web Service"
Get-SPServiceInstance | where {$_.GetType().Name '
    -eq $mmsInstanceName} | Start-SPServiceInstance
Write-Host "Managed Metadata Service Application successful configured!"

While creating a custom solution, you can and probably will use Microsoft Visual Studio to debug your code in your development environment if you experience any issues or unexpected behavior. You might even use Visual Studio to do some debugging to simply get a better understanding of what’s happening behind the scenes in SharePoint. The Visual Studio Debugger is not the only way to understand and troubleshoot SharePoint and your custom components, though. Other tools that you can use include:

Using the Developer Dashboard

The Developer Dashboard was introduced in SharePoint 2010 to show performance and tracing information for a SharePoint page in a control on the page itself. In SharePoint 2013, the Developer Dashboard has been dramatically improved. The dashboard is no longer a control on a page; it opens in a separate dedicated window. The dashboard also no longer just contains information about the latest request but contains information about several requests, so that you can compare them if you want to and more easily get an overview. The information on the Developer Dashboard is a lot more detailed than it was in SharePoint 2010. For instance, you can now easily see the SQL requests and the time it took to process them, the different scopes and execution times, service calls, and also all ULS log entries that are related to the selected request. All this can really help you to identify any potential problems related to a request, because you have all the information SharePoint collected about the requests in a single place.

By default, the Developer Dashboard is disabled. You can enable it by using Windows PowerShell. The Windows PowerShell cmdlet only supports On or Off; the OnDemand parameter has been deprecated, although On now pretty much acts the way OnDemand did in SharePoint 2010; it displays an icon in the upper-right corner that allows you to open up the Developer Dashboard. The Windows PowerShell cmdlet to turn on the Developer Dashboard is displayed in Example 2-3.

Example 2-3. Changing the mode of the Developer Dashboard

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"
$DevDashboardSettings = [Microsoft.SharePoint.Administration.SPWebService]:: '
ContentService.DeveloperDashboardSettings
$DevDashboardSettings.DisplayLevel = 'On'
$DevDashboardsettings.Update()

Figure 2-5 shows the Developer Dashboard after the welcome page of an out-of-the-box team site has been loaded. On the dashboard, you can see different tabs for server information, scopes, SQL info, ULS information, and a lot more. The Server Info tab contains the total execution time for the page, the current user, whether the page is published, and the correlation ID. The SQL tab also shows the execution time for all database queries and for all methods. By using the dashboard you can not only see how long a page took to load just the out-of-the-box functionality on it, but you can also see how long it takes your custom component to load. You can identify whether your code executes any expensive methods or database queries.

Figure 2-5. The Developer Dashboard

To write information from your own custom solution to the Developer Dashboard you can either execute your code in an OnInit or Render override, or you can wrap your code in an SPMonitoredScope block. Only code from farm solutions can send information to the Developer Dashboard; the contents of sandboxed solutions or apps cannot send information to the dashboard.

The release of SharePoint 2007 was a significant milestone for SharePoint as a development platform because in this version, Microsoft introduced support for features and solution packages. Soon after SharePoint 2007 was released, however, it became clear within Microsoft and throughout the industry that more and better developer productivity tools were needed. With SharePoint 2010, Microsoft extended the developer platform by introducing the SharePoint Developer Tools in Visual Studio 2010. These new tools made developing for SharePoint 2010 much faster and easier because they automated grungy tasks and hid many of the low-level details that developers had to worry about when developing for SharePoint 2007. For example, every SharePoint project in Visual Studio 2010 is created with built-in support to generate its output as a solution package. The SharePoint Developer Tools also integrate commands into the Visual Studio 2010 environment that make it easy to deploy and retract the solution package for a SharePoint project during testing and debugging.

With the introduction of SharePoint 2013 and Visual Studio 2012, Microsoft has further improved the SharePoint Developer Tools. For the project types that were available for SharePoint 2010 there are now also SharePoint 2013 versions. There are also Office add-in project types that can be used to create add-ins for the Microsoft Office 2013 and Office 2010 applications. The biggest change, however, is that the SharePoint Developer Tools in Visual Studio 2012 contain two project types that allow you to create two different types of apps:

You can find the app for SharePoint 2013 C# in the New Project dialog box within Visual Studio 2012 by navigating to Visual C#Office/SharePointApps, as shown in Figure 2-6.

Figure 2-6. Selecting the App for SharePoint 2013 project type to create an app

When you click OK you are asked to confirm the name of the app and specify the site to which you want Visual Studio to deploy the app and how you want to host your app, as shown in Figure 2-7.

Figure 2-7. Specifying a name, test site URL, and trust level for an app

SharePoint apps will be discussed in detail in Chapter 4. For now, you will create a SharePoint-hosted app, which means that all of the app will be deployed to a SharePoint site. When you click the Finish button in the SharePoint Customization Wizard, Visual Studio takes a few seconds to create and configure the new project. Figure 2-8 shows what the new SharePoint project looks like in Solution Explorer.

Figure 2-8. An app’s Features node, Package node, and some standard content

A SharePoint app is created with some default content. There is a style sheet, an app icon image, a default page, and several JavaScript files. The AppManifest.xml file contains metadata such as the name and the title of the app, the app icon, and the scopes at which the app needs to have permissions. You use the Features node of the App for SharePoint 2013 project to add new features to the app. Notice that the Features node of a SharePoint app contains one feature, called Feature1, when the app is created. Feature1 contains the default content and is web scoped. A feature in a SharePoint app can only be web scoped, it is not supported to use a SharePoint app to deploy a site, web application, or farm-scoped feature. You use the Package node to track project-wide settings related to building the project into a solution package .wsp file and an app package .app file.

Just like normal SharePoint projects, SharePoint apps also have three special menu commands to support deployment and packaging of the app: Deploy, Package, and Retract. These menu commands are available when you right-click the top-level project node in Solution Explorer. You can run the Package command to build a SharePoint project into a solution package. You can use the Deploy command to run a sequence of deployment steps that deploy the solution package in the local farm so that you can test and debug your work. The Retract command reverses the act of deployment by retracting the solution package from the local farm. When you click the Deploy button, Visual Studio deploys the app to the site you listed in the Customization Wizard. You can find the app on the Site Contents page and in the navigation pane on the left side of the page, under the Recent heading, as shown in Figure 2-9. Clicking the app name or icon will open the app’s default.aspx page.

Figure 2-9. The WingTip app on the Site Contents page and in the navigation pane on the left side of the page

At least as important as knowing how to create a solution is knowing when to create a solution and what type of solution to create. Even though this is a book about custom development, the best approach when using SharePoint is to use out-of-the-box functionality. Customizations are the number-one cause of problems with SharePoint environments. Knowing this, you have to make sure that when you create a custom solution, the same functionality couldn’t be achieved by using out-of-the-box functionality. If you do have to create a custom solution, you have to make sure that you create the right type of solution and that you build the solution in a way that uses the least amount of resources from the SharePoint server.

When you open up Visual Studio, the first thing you have to decide is what type of project you want to create. With the new SharePoint 2013 app model added into the mix, you can now choose between a SharePoint 2013 farm solution, a SharePoint 2013 sandboxed solution, and a SharePoint 2013 app. There isn’t one right project type; the best type depends on what kind of customizations you want to build and to what type of environment you want to deploy the customizations.

The best option is always the project type that puts the least amount of load on the SharePoint server. However, the solution also has to be maintainable and upgradable. The solution should not be overly complex, so that it can be maintained by others. The solution design should follow best practices to ensure that it can be upgraded to a next version of SharePoint. Of course, you also have to make sure that the solution can be deployed to the environment that you are creating the customizations for. To summarize, when you create SharePoint customizations, the following things have to be taken into account:

Because a SharePoint app can’t deploy server-side code to the SharePoint server, that will always be the project type that puts the least amount of load on the SharePoint server. Sandboxed solutions can deploy server-side code to the SharePoint server; however, a sandboxed solution can only use a limited amount of server resources before it is shut down. A farm solution can technically use all the resources that are available on the server, and because of that, a farm solution can bring down an entire SharePoint farm. This is not just a theoretical scenario; it actually happens on a regular basis to both small and really large SharePoint environments.

It is likely that the version of the customizations that you are building is not the last version. Either the customizations will be a huge hit and users will ask for more functionality, or they aren’t what users were expecting and they need modifications to fit the user’s needs. To make the solution easy to maintain, make it as simple as possible. This means that even though your first choice should be to build a SharePoint app, because that would consume the least amount of SharePoint server resources, you shouldn’t do it at all costs. If creating an app would create a solution that is significantly more complex, the best solution is probably to build a sandboxed or farm solution.

If the SharePoint environment is successful, it’s very likely that at some point the environment will have to be upgraded to the next version of SharePoint. Some SharePoint customizations can block the upgrade of a SharePoint environment. For instance, if a solution makes unsupported changes to the database or to SharePoint files on the file system, it won’t be possible to upgrade the environment. Also, when certain customizations such as site definitions are involved, it will be significantly more difficult to move the contents of the SharePoint farm to a cloud-hosted environment. Because Microsoft has positioned the SharePoint app model as the SharePoint customization type of the future, and because almost all parts of the SharePoint app live outside of SharePoint, creating apps is your safest bet when you want to guarantee that your environment can upgrade without being hindered by the customizations.

Using farm solutions means that the solution will have to be upgraded when the SharePoint farm gets upgraded. Sandboxed solutions live in the content database and can only affect the site collection that they are deployed in. This means that the impact they can have on an upgrade to a new version of SharePoint is a lot smaller than for farm solutions. However, sandboxed solutions are deprecated in SharePoint 2013. This means that although both sandboxed solutions that were created for SharePoint 2010 and new sandboxed solutions created for SharePoint 2013 are still fully supported, Microsoft is planning to remove support for sandboxed solutions at some point in the future. This doesn’t necessarily have to be in the next release; it could be in the release after that, or an even later release. Investing in large-scale sandboxed solutions is probably not a good idea, though.

If your environment is a cloud-hosted environment such as Office 365, you might not have much of a choice, because you won’t be allowed to deploy full trust solutions, and not all customizations can be created by using apps. In those cases, you will probably still want to create new sandboxed solutions. The advice would then be to try and create the solutions in such a way that you can remove the sandboxed solution without the entire site breaking down. When Microsoft then at some point removes the support for sandboxed solutions, at least your existing content is still accessible.

When you are upgrading from SharePoint 2010 to SharePoint 2013, you can choose how you want to upgrade you custom solutions:

In SharePoint 2013, you can now choose from three different APIs: the server-side object model (SSOM), the client-side object model (CSOM), and the REST API. All three APIs give you the option to build customizations for your SharePoint environment. This section will provide an overview of the three different APIs. Each API will then be used extensively in examples throughout the book. For specific detailed coverage of CSOM and REST, see Chapter 5.

//Server Object Model
SPSite siteCollection = SPContext.Current.Site;
string url = siteCollection.Url;

//Managed Client Object Model
using (ClientContext ctx = new ClientContext("http://intranet.wingtiptoys.com"))
{
    Site siteCollection = ctx.Site;
    ctx.Load(siteCollection);
    ctx.ExecuteQuery();
    string url = siteCollection.Url;
}

//Silverlight Client Object Model
using (ClientContext ctx =
    new ClientContext("http://intranet.wingtiptoys.com"))
{
    Site siteCollection = ctx.Site;
    ctx.Load(siteCollection);
    ctx.ExecuteQuery();
    string url = siteCollection.Url;
}

//Mobile Client Object Model
using (ClientContext ctx =
    new ClientContext("http://intranet.wingtiptoys.com"))
{
    Site siteCollection = ctx.Site;
    ctx.Load(siteCollection);
    ctx.ExecuteQuery();
    string url = siteCollection.Url;
}

//JavaScript Client Object Model
var siteCollection;
function getSiteCollection
{
    var ctx = new SP.ClientContext("/");
    siteCollection = ctx.get_site;
    ctx.load(site);
    ctx.executeQueryAsync(success, failure);
}

function success {
    string url = siteCollection.get_url;
}

function failure {
    alert("Failure!");
}

http://<server>/<site>/_api

//Access a site collection
http://<server>/<site>/_api/site

//Access a specific site
http://<server>/<site>/_api/web

//Access a list in a specific site
http://<server>/<site>/_api/web/lists('GUID')

//Apply a "blank" site site definition to a SharePoint site
http://<server>/<site>/_api/web/applyWebTemplate?template="STS#1"

http://<server>/<site>/_api/web/lists('GUID')/items?$select=FirstName,LastName,
PhoneNumber$filter=startWith(FirstName, a)

In this chapter, all the basics of developing a custom SharePoint solution have been touched on. The first step is to determine what type of development environment you need to create the solution that you want to create, or to complete the project that you are working on. When you have your hardware and the design of the development environment in place, you can install and configure it manually, but you can also use Windows PowerShell to configure your server. Especially if you need to create multiple development environments, scripting the installation and configuration can save you time and will help to ensure that all development environments are identical.

The next step is to determine a development approach. The best approach for your solution depends on the functionality that you want to build and on the environment that the solution should be deployed to. If the solution has to be deployed to a cloud-hosted environment, creating a farm solution is not an option, because you won’t be able to deploy it. The most future-proof approach is to create a SharePoint app. However, some of the functionality that you might want to build might not be able to be created by using a SharePoint app (yet). This forces you to make a decision between creating an app that implements as much of the functionality as possible and creating a farm solution that implements the exact functionality that you are looking for. If you deploying a farm solution, you will have to upgrade it if you want to upgrade your environment, and at some point in the future Microsoft might remove support for farm solutions completely. Although it will be a while before this happens, it should already be a consideration when you are determining the development approach you are going to use for your solution.

After your solution is deployed, you might have to debug it. There are several debugging tools that can be used to debug custom SharePoint solutions. The best tool to use depends on the type of problem you are trying to debug and on what type of environment your solution is in. The ULS and Windows Event Logs, and the Developer Dashboard, can give you valuable information from all types of environments and are all useful tools to help you identify the cause of a problem on your farm.