15

SharePoint Online

If you have not heard about public or private clouds, you must not be reading the news or blogs, or looking at what the different vendors are doing. Software as a service (SAAS) is all the rage in the computing world. Although it has many merits, including ease of deployment, anywhere access, and quick upgrades, at the same time it has a number of obstacles, such as limited offline support, less mature development tools, and less control of customization. Regardless of these limitations, many people are looking to the cloud as the next major shift in the computing world. If you have not tried to build applications against a cloud service such as Microsoft Azure or SharePoint Online, get started today.

BPOS: SHAREPOINT ONLINE OVERVIEW

Business Productivity Online Services is the Microsoft cloud hosted productivity suite that includes SharePoint 2007. BPOS is being deprecated as Office 365 comes to market so this section of text is left in the book for reference only. All future development should be done on Office 365, which includes SharePoint 2010. There are two versions of SharePoint Online: Standard and Dedicated. Table 15-1 provides an easy way to compare the different ways you can deploy SharePoint. This table compares SharePoint On-Premises, SharePoint Online Standard, and SharePoint Online Dedicated.

TABLE 15-1: Different Deployment Options for SharePoint

One of the major differences, as you can see in the table, is that SharePoint Online Standard does not support the full range of customizations like the other two deployments of SharePoint. Going even deeper, if you look at what constitutes a farm solution as opposed to a non-farm solution, the clarity of what will and won't work gets better. Table 15-2 shows examples of no-code solutions versus farm solutions.

TABLE 15-2: No-Code versus Farm Solutions

One other major difference between online and on-premises is that not all of the feature set of SharePoint is supported in the cloud. In particular, SharePoint Online does not support PerformancePoint or FAST in the cloud. Additionally, when dealing with search technologies, architecture and deployment become more critical when deploying in the cloud. For example, if you had a hybrid environment where you wanted to have one search index across both on-premises content and cloud content, where do you place your indexer — on-premises or online? The answer is that it depends, but either place that you decide to place it, you will be dealing with crawling across WANs. A solution may be to create two separate search deployments and use federated search. However, doing so results in the loss of the ability to have a single result set with integrated relevancy.

DEVELOPING IN THE CLOUD

As you can see by the previous summary, some of the ways you are used to developing on-premises will not translate to the multi-tenant cloud. Using server-side code is a no-no when it comes to building applications on which you are running SharePoint with other tenants on the server. When developing for online use, there are a number of choices you have for development. You can use Sandbox Solutions, SPD, InfoPath, Access, or the SharePoint client object model in ASP.NET or Silverlight applications. Because many of these technologies have been covered already in this book, they will not be covered here again.

Instead, this chapter focuses on some of the best practices to use when developing in the cloud. These best practices can be used on-premises as well as on the cloud, but given the limitations of the cloud, you have more options on-premises.

Debugging Your Solutions

Depending on the technology you decide to use, there will be different techniques to debug your solutions. Unfortunately, many of the techniques you are used to will not work in an online development environment. For example, you cannot enable the Developer Dashboard in the online environment. Also, your Sandbox Solutions cannot write to the file system or over the network. For SharePoint debugging purposes, get comfortable writing debugging information as screen alerts or storing it within SharePoint lists. Furthermore, you will want to keep a SharePoint site just for development and then deploy your solutions to your online production site.

When it comes to Silverlight or client-side code, your choices for debugging are better, since you can use the tools built into Internet Explorer or Firefox to debug your solution.

The following Sandbox web part shows how to log on to a SharePoint list for debugging purposes:

using System;
using System.ComponentModel;
using System.Runtime.InteropServices;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;

namespace SharePointOnlineLogging.WebPart1
{
    [ToolboxItemAttribute(false)]
    public class WebPart1 : WebPart
    {

        private Button logResultsButton = new Button() { Text = “Log Results” };
    private Label lbl = new Label();

    public WebPart1()
    {
    }

    protected override void CreateChildControls()
    {
            logResultsButton.Click += (object sender, EventArgs e) =>
            {

            SPContext context = SPContext.Current;

        SPWeb web = context.Web;

        SPList list = web.GetList(“/Lists/SharePointOnlineLogging-ListInstancel”);
        string logResults = DateTime.Now.ToShortDateString() + “ ” + DateTime.Now.ToShortTimeString() + “: Logged from Sandbox Web Part!”;

                SPListItem newItem = list.AddItem();


        newItem[“Title”] = “New Log Result - ” + DateTime.Now.ToShortTimeString();
        newItem[“LoggingResult”] = logResults;

        newItem.Update();


        lbl.Text = “Logged Result: ” + logResults;
            };
            Controls.Add(logResultsButton);

        Controls.Add(lbl);

        //base.CreateChildControls();
         }

     protected override void RenderContents(HtmlTextWriter writer)
     {
             base.RenderContents(writer);
         }
     }
 }

EXAMPLE CLOUD SCENARIOS

To help understand areas where using SharePoint in the cloud makes sense, the following scenarios describe where you can use the cloud and where you can't. As you will find, for out-of-the-box functionality, SharePoint Online is a very viable solution. The areas to watch out for include custom code and unsupported features in the cloud, or features that require administrative access to the server.

The first scenario is your typical team collaboration, wherein you are creating a team site, sharing documents, and performing simple customization of the site. Because this case does not require high-end development or administrative access, this scenario would be supported easily in the cloud. The only gotchas are to make sure that users who use Office on their desktop understand how to authenticate against SharePoint Online and how to determine the address for their sites, since they will be fully qualified domain names rather than Intranet-style short names.

The next scenario is a company portal. This is where it gets more complex, because many portals require rich customization and publishing infrastructure. This is one scenario where you will have to evaluate your needs versus what SharePoint Online provides from a development standpoint. If you find that your existing portal makes use of a lot of custom code (such as custom field controls or complex workflows), you may not want to run your solution in SharePoint Online or rewrite these solutions to use Sandbox Solutions, which are supported in the Online environment.

SharePoint Online, in Office 365, has an offering for building extranets since the security for extranets is different than Intranet sites. Plus, sharing and invitations with external parties makes it easy for end users to invite their business partners from other companies. Extranets may be the first scenario that you undertake with SharePoint Online as a complement to your on-premises deployment of SharePoint. You may get a quick win by making it easy to share information with your business partners without having to worry about access to your internal corporate networks. You will want to make sure that the SharePoint Online service-level agreements for availability and recovery meet your corporate standards and that the security in place for SharePoint Online meets your security guidelines for your company. One thing to think about with the extranet capabilities in Office 365 is that it really is an external sharing capability since extranets usually require more complex compliance and governance. As long as you realize the limitations of the Office 365 extranet capabilities, you will use Office 365 for the right scenarios.

OFFICE 365 OVERVIEW

Office 365 is the next generation of the BPOS suite and is the latest offering in Microsoft's cloud services infrastructure. With Office 365, you get Exchange, SharePoint, Lync, and Office Professional Plus as part of the bundle. Microsoft runs the infrastructure for you by providing you with hosting, billing, backup, anti-virus, and anti-spam services, as well as a host of other services that normally an IT department would run on-premises. This section covers what SharePoint Online offers in Office 365, but you should browse to the Office 365 web site at http://office365.microsoft.com to learn more about Exchange Online or Lync Online.

Differences Between SharePoint On-Premises and Online

So, what's the difference between SharePoint Online and SharePoint On-Premises? There are a number of differences, with the majority of the differences falling into the level of control and extensibility scenario. For example, because SharePoint Online runs in a multi-tenant environment, you do not have the same level of access that you do when you run on-premises on your own server. You do not have access to SharePoint Central Administration. You cannot run full-trust solutions and any pieces of SharePoint that require full server configuration changes, Central Administration access, or full-trust access will not work in SharePoint Online. So, if you find that you need full control of your environment or full ability to write code that accesses all the resources on the SharePoint Server, you will find that you should continue to deploy SharePoint On-Premises.

To give you an example, Figure 15-1 shows the tenant administration page in SharePoint Online. Notice that this administration page is very different and less functional than what you can do in SharePoint's Central Administration site.

FIGURE 15-1

What's in SharePoint Online in Office 365

Since SharePoint Online is not an exact replica of SharePoint On-Premises, you may be wondering what is supported in SharePoint Online. Table 15-3 shows the developer features that are available in SharePoint Online. Please note that there are also IT and end user features that are not available in SharePoint Online, so you will want to check the SharePoint web site for more information about which features are available in SharePoint Online.

TABLE 15-3: Developer Differences Between Online and On-Premises

What About Hybrid Solutions?

Given the limitations of SharePoint Online, there may be times when you need to build a hybrid solution between SharePoint Online and SharePoint On-Premises. Given that SharePoint Online does not support BCS, bridging this gap is not as easy when it comes to data connectivity. However, for applications that need to span across the two environments when writing client-side code, such as Silverlight and JavaScript applications, hybrid solutions can make sense as long as you can overcome the connectivity and identity issues. Another good solution for hybrid solutions is also hybrid cloud solutions between Office 365 and Windows Azure. By combining the two clouds, you can build richer solutions that span the two environments. The rest of this chapter covers integrating SharePoint, both on-premises and online, with the Microsoft Azure technologies.

AZURE OVERVIEW

The Microsoft Azure platform is Microsoft's Platform-as-a-Service (PaaS) offering that allows you to offload your platform services to Microsoft data centers. The main components of the Azure platform are Windows Azure, SQL Azure, and Windows Azure AppFabric.

Windows Azure

Windows Azure is made up of a number of components underneath the Windows Azure brand. For example, Windows Azure includes compute, virtual machines, storage, content delivery networks, and caching. Windows Azure and SharePoint can overlap in a few ways. In the simpler form, you can build applications on Azure that you can then surface into SharePoint using the Page Viewer web part. You can also build more complex scenarios such as writing a remote blob storage provider that uses the Windows Azure storage technologies to store your SharePoint blobs in the Azure cloud.

SQL Azure

Another piece of the overall Azure platform is SQL Azure. SQL Azure is a cloud database built on the SQL Server technologies. With SQL Azure, all the infrastructure management, high availability, and fault tolerance of SQL Server is provisioned and provided by the cloud service. Developers just need to create databases and write applications that use the SQL Azure databases. In fact, existing administration and development tools can be used against SQL Azure, as you can see in Figure 15-2, which shows using SQL Server Management Studio with a SQL Azure cloud database.

FIGURE 15-2

SQL Server Management Studio

In addition to providing database capabilities, SQL Azure also provides business intelligence capabilities by providing rich reports through SQL Azure reporting. SQL Azure reporting is the familiar SQL Server Reporting Services technologies hosted inside the Azure cloud.

Lastly, SQL Azure also provides SQL Azure Data Sync, which is a cloud-based data synchronization service built on the Microsoft Sync Framework technologies. With this technology, you can sync between SQL Azure databases or between SQL Azure and on-premises SQL Server databases.

Windows Azure AppFabric

Windows Azure AppFabric is a cloud-based middleware platform for building applications on the Windows Azure platform. The middleware services AppFabric provides are Service Bus, Access Control, Caching, and Integration. The Service Bus provides secure messaging and connectivity. Access Control provides identity and access control services that integrate with standards-based identity providers such as ADFS, Windows Live ID, Google, and Facebook. Caching provides a distributed, in-memory application cache that allows for high-speed access, scaling, and high availability. Finally, the Integration service provides integration capabilities such as pipeline management, transformation, and business and format adapters that allow you to quickly build middleware applications that connect together.

WINDOWS AZURE VIRTUAL NETWORK

Windows Azure Virtual Network is made up of two components: Windows Azure Connect and Windows Azure Traffic Manager. Windows Azure Connect is a simple way to set up IP-based network connectivity between on-premises resources and Windows Azure. For example, you can connect to an on-premises SQL Server or SharePoint deployment and use that data in your Windows Azure applications without having to set up complex VPN settings.

Windows Azure Traffic Manager allows you to load-balance traffic to multiple hosted services. You can use three balancing methods to do this: Performance, Failover, or Round Robin. As these names suggest, Performance is based on performance thresholds you set, Failover is for failing over traffic during a disruption, and Round Robin routes between all resources all the time.

DEVELOPER TOOLS FOR WINDOWS AZURE

To get started developing for Azure, you need to download the tools and SDK. Azure tools integrate into the Visual Studio 2010 environment so you can quickly get started building Azure applications. Plus, you can locally deploy and debug your applications in Visual Studio before deploying them to the Azure cloud. Figure 15-3 shows developing an Azure application in Visual Studio 2010.

FIGURE 15-3

SHAREPOINT AND AZURE INTEGRATION SCENARIOS

There are many ways you can integrate SharePoint and Azure. For example, you can host an Azure application in a Page Viewer web part in SharePoint for simple integration. Beyond that, for on-premises SharePoint deployments, you can connect BCS to SQL Azure to surface information from the cloud SQL Server into your on-premises SharePoint deployment. Furthermore, you can use Azure Connect to connect your Windows Azure applications to on-premises SharePoint resources. The rest of this section explores some of these different integration scenarios.

Integrating SQL Azure with SharePoint On-Premises

One of the first ways you can integrate Azure and SharePoint is through BCS. Please note that BCS is only supported today with SharePoint On-Premises so the information contained here will work only with an on-premises deployment of SharePoint, not with SharePoint Online. Working with SQL Azure is as easy as working with SQL Server On-Premises when connecting and consuming SQL from BCS. Let's go through the steps to connect BCS and SQL Azure.

Create Your SQL Azure Database

The first step is to create your SQL Azure database. You can download the Northwind sample database, which you can find either at http://archive.msdn.microsoft.com/northwind/Release/ProjectReleases.aspx?ReleaseId=1401 or as part of the sample applications for this chapter. To install the Northwind database, you need to first connect to the SQL Azure management portal. This portal is part of the Windows Azure management portal, which you can find at www.microsoft.com/windowsazure/account/. Figure 15-4 shows the SQL Azure management portal.

FIGURE 15-4

Using this interface, you can create your SQL Azure database. Since the database will be small, you can use the web edition database with a size of 1GB. Remember what you name your database and also remember the fully-qualified DNS name of your SQL Azure server, which you can see on the right side of the screenshot. You will use this information later to connect from SQL Server Management Studio.

Set Up Firewall Rules

SQL Azure has a firewall to stop access to your databases from unauthorized sources. You will want to configure firewall rules so that your on-premises machines can access SQL Azure. Conveniently, the user interface for adding a firewall rule shows your current IP address and can accept a range of IP addresses to allow, as shown in Figure 15-5. Also note that if you are behind a proxy server, you will want to make sure you are putting in the IP address of the proxy.

FIGURE 15-5

Connect Using SQL Server Management Studio

Once you have your firewall rules set up, you can connect to SQL Azure from SQL Server Management Studio. Make sure to put in the fully qualified domain name for SQL Azure, as shown in Figure 15-6.

FIGURE 15-6

Once connected, you can create the Northwind database. Once the import is complete, you now have data in your SQL database to connect to SharePoint through BCS.

Create a New Secure Store Service (SSS) Entry

Since SQL Azure requires SQL Server authentication and sits in a different domain than your SharePoint deployment, you will need to create a Secure Store Service entry to allow BCS to know the credentials to connect to SQL Azure with. To create a new SSS entry, under Central Administration, go under Application Management and then choose Manage Service Applications Under Secure Store Service, click the Secure Store Service link. Then click Manage and then New. Provide a target application ID and a display name and click Next, as shown in Figure 15-7.

On the Field page of the wizard, add a description for the User Name and Password fields. In the Field Type area, make sure User Name is selected for your username field. Choose Password and check the Masked check box for the password field, as shown in Figure 15-8.

FIGURE 15-7

FIGURE 15-8

Finally, select a Target Application Administrator, as shown in Figure 15-9.

FIGURE 15-9

Create an External Content Type with SharePoint Designer

The next step is to create your External Content Type with SharePoint Designer. This is no different than creating an External Content Type to an on-premises SQL Server except that you need include the address of your SQL Azure database and make sure to tell SharePoint Designer to use your SSS credentials to connect to SQL Azure.

Figure 15-10 shows how to add a connection in a SharePoint Designer External Content Type to Windows Azure.

FIGURE 15-10

Once connected, you can do your normal operations such as creating all operations against the SQL Azure datasource, as shown in Figure 15-11.

FIGURE 15-11

The next step is to have SharePoint Designer create the list and forms for you to display your external data. To do this, click the Create Lists and Form button.

Set Permissions for Your External Content Type

The last step before you can use your ECT in SQL Azure is to set permissions to your External Content Type for users who need to be able to use the type. To do this, go into Central Administration. Under Manage Service Applications, select Business Data Connectivity Services. Click Manage and find your new ECT, and then select it and click the Set Object Permissions in the Ribbon. From there, add the user who is getting permissions, as shown in Figure 15-12.

FIGURE 15-12

Browse and Enjoy!

That's it. You now have connected SharePoint and SQL Azure in five minutes. The results of the work are shown in Figure 15-13, where you can see an external list showing the customers from Northwind in your SharePoint user interface.

FIGURE 15-13

Integrating SQL Azure and SharePoint Online

Since SharePoint Online does not support BCS, you may be wondering whether you can leverage SQL Azure from SharePoint Online. Although it's not as robust as using BCS, you can still host SQL Azure using the Page Viewer web part to host a web page that connects to SQL Azure. You may be wondering why you can't use a Sandbox Solution. The issue there is that Sandbox Solutions cannot use network features, so they cannot connect to SQL Azure.

Your other option is to write a Silverlight application that connects to SQL Azure and host that Silverlight application using the Silverlight web part in SharePoint Online. This is a viable option to connect with and leverage SQL Azure data. Figure 15-14 shows a sample Silverlight application that surfaces SQL Azure data.

FIGURE 15-14

Connecting to On-Premises from SharePoint Online

Beyond connecting to the Azure cloud from your applications, you may want your Azure applications to be able to connect to your on-premises SharePoint deployments. There are two ways you can do this. First, you can write an on-premises WCF service that you can call through the Azure Service Bus. The Azure Service Bus allows you to connect to your on-premises SharePoint deployment using the SharePoint APIs such as REST and web services.

Another option is to use Azure Connect, which allows you to connect your Windows Azure roles to your on-premises resources. The way this is achieved is by installing an Azure Connect agent on your on-premises resource and then using a secure activation token. This enables connectivity between your Azure roles and your on-premises resource. In addition, you can even domain join Azure machines to your on-premises Active Directory.

WRITING SHAREPOINT ONLINE APPLICATIONS

This last section deals with writing SharePoint Online applications. Because SharePoint Online is the same software as SharePoint On-Premises, except with some functionality and platform differences, many of the techniques you've learned throughout this book work with SharePoint Online. The main hurdle that you will run into when writing SharePoint Online applications is in understanding the limitations of SharePoint Online and making sure you understand how to authenticate and authorize using SharePoint Online. Looking at some sample scenarios will help make this more clear, so let's dive in.

Identity and Authentication in Office 365

One of the major pieces of Office 365 is the authentication system. Office 365 supports direct authentication via a username and password. The Office 365 security system is known as OrgID, which is based off the LiveID technologies. Although it's similar, an OrgID is not the same as a LiveID. For example, you cannot log on to Office 365 with your LiveID using the LiveID STS. When logging into the system, you request a token from the Office 365 STS, which is located at https://login.microsoftonline.com/extSTS.srf. You pass your username and password using the SAML 1.1 protocol and, if successful, the STS returns a security token. That security token is sent to the service you are trying to use, in this case SharePoint Online, and if validated, SharePoint Online returns two cookies that act as tokens. One is called FedAuth and the other is rtFa. From that point, you must pass these two tokens with every call to SharePoint Online.

Similar to the way you passed the CookieContainer in the Windows Phone 7 applications we saw earlier in the book, when writing SharePoint Online applications, you need to grab the two cookies that represent your tokens and add them to your calls.

Rather than writing your own code to do all this work, you have two choices. You can use a Microsoft sample, which uses a web browser control to have the user log in and then retrieves the cookies if there is a successful login. Or you can use a sample that Wictor Wilen wrote, at www.wictorwilen.se/Post/How-to-do-active-authentication-to-Office-365-and-SharePoint-Online.aspx. Both samples are included in the sample applications of this chapter. The main difference is that the Microsoft sample does display a web browser control, as shown in Figure 15-15, and the other sample does not.

FIGURE 15-15

Calling the Client Object Model

To make this clearer, let's write a sample application that calls the client object model using both sets of samples for performing authentication. The sample will retrieve the title of the website and all the lists in the site and display them on the screen.

Microsoft Authentication Sample

The Microsoft authentication sample can be compiled and referenced in your projects. The only issue with the Microsoft sample is that it does display its own form so you will run into issues trying to use the sample in Windows Forms applications. The following sample references the Microsoft sample and will display the name of the site and all the lists using the client object model.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.Client;
using MSDN.Samples.ClaimsAuth;

namespace SharePoint_Online_MSFT_Authentication
{
    class Program
    {
        [STAThread]
        static void Main(string[] args)
    {

            if (args.Length < 1) { Console.WriteLine (“Please enter a URL for SharePoint Online”); return; }
    
            string targetSite = args[0];
            using (ClientContext ctx = ClaimClientContext.GetAuthenticatedContext(targetSite))
            {
                if (ctx != null)
        {
                    ctx.Load(ctx.Web);
            ctx.ExecuteQuery();

            Console.WriteLine (“Your site name is: ” + ctx.Web.Title.ToString());

            Console.WriteLine(“Your lists are: ”);
            ListCollection listCollection = ctx.Web.Lists;
            ctx.Load(
                        listCollection,
            lists => lists
                .Include(
                                list => list.Title,
                list => list.Hidden)
                            .Where(list => !list.Hidden)
                         );
                    ctx.ExecuteQuery();
            foreach (var list in listCollection)
                Console.WriteLine(list.Title);



                }
            }
            Console.ReadLine();
         }
     }
 }

Wictor Authentication Sample

Wictor's sample, rather than using a web browser control to capture the username and password, takes the username and password as inputs and then uses the cookies to authenticate against the service. The following sample uses the same client object model code but with different authentication code.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.Client;

namespace Wictor.Office365.ClaimsDemo {
    class Program {
static void Main(string[] args) {
    if (args.Count() != 3) {
        Console.WriteLine(“Syntax: Wictor.Office3 65.ClaimsDemo.exe url username password”);
    }
    MsOnlineClaimsHelper claimsHelper = new MsOnlineClaimsHelper
               (args[0], args[1], args[2]);
    using (ClientContext context = new ClientContext(args[0])) {
        context.ExecutingWebRequest +=
           claimsHelper.clientContext_ExecutingWebRequest;

    context.Load(context.Web);

    context.ExecuteQuery();

    Console.WriteLine(“Name of the web is: ” + context.Web.Title);

    Console.WriteLine(“Your lists are: ”);
    ListCollection listCollection = context.Web.Lists;
    context.Load(
            listCollection,
        lists => lists
            .Include(
                    list => list.Title,
            list => list.Hidden)
        .Where(list => !list.Hidden)
            );
        context.ExecuteQuery();
    foreach (var list in listCollection)
           Console.WriteLine(list.Title);

         }
      }
   }
}

Writing a Sandbox Solution in Office 365

Your other option for SharePoint Online is writing server-side code. Because SharePoint Online does not support full trust solutions, you can use Sandbox Solutions as part of your application. With the new Visual Studio power tools, you can also use sandboxed visual web parts in SharePoint Online. Since sandbox is already covered in this book, I will not go through all the content again. The main difference between SharePoint Online and your own deployment is that SharePoint Online allocates 300 quota resources for your sandbox, and you cannot increase that quota. Please note that you will need a local copy of SharePoint in order to develop against and then deploy your solution using your WSP files to SharePoint Online. You will not be able to connect VS directly to SharePoint Online. Figure 15-16 shows a visual sandbox web part running in SharePoint Online.

FIGURE 15-16

Connecting Outside of Office 365 with Silverlight

Since Office 365 does not support BCS at the time of this writing, you have to depend on other technologies to connect to datasources outside of your Office 365 deployment. This is where Silverlight and its remote data connectivity come in handy. Remember with Silverlight you will need a clientaccesspolicy.xml file on your remote site so that the Silverlight application running in your Office 365 domain context will be able to connect to the datasource or other application. Figure 15-17 shows using Silverlight in SharePoint Online to connect to a hosted Northwind database.

FIGURE 15-17

Deploying and Debugging

You will find deployment and debugging painful when developing for SharePoint Online. SharePoint Online provides a limited set of capabilities for these two functions as opposed to SharePoint On-Premises. For example, since you cannot run Visual Studio on your SharePoint Online server and because SharePoint Online, today, does not support PowerShell, you will have to manually copy your WSP files to SharePoint Online and activate them.

In addition, you cannot attach the debugger directly to your processes since VS is not running on your server and you cannot set up remote debugging on SharePoint Online. Your only options for debugging are to use a local SharePoint Server, write to a list as a log file, or use the Developer Dashboard.

WSP Files and the Solution Gallery

To deploy solutions to SharePoint Online, you will need to manually copy your WSP files, which you can have Visual Studio package up for you. Then, you will need to activate the solution contained in the WSP file using the SharePoint user interface, as shown in Figure 15-18. From there, you can use your web part, workflow action, or other solution you have created for SharePoint Online.

FIGURE 15-18

Developer Dashboard

One nice feature that is enabled in SharePoint Online is that the Developer Dashboard is enabled by default. By clicking the Developer Dashboard icon in the upper-right corner of the SharePoint user interface, you can quickly see what's happening. However, Sandbox Solutions do not support SPMonitoredScope, which allows you to add richer tracking of your solution in the sandbox. Figure 15-19 shows the Developer Dashboard running in SharePoint Online with the custom sandbox web part you built earlier.

Fiddler

Because you are dealing with an online service, you need to become adept at looking at network packets when debugging. For debugging, you will want to install Fiddler on your machines since Fiddler will help you understand the traffic between your client machine and SharePoint Online. Looking at the traffic, you can discover what is happening between the instances and also determine whether your problems are authentication- or identity-related or are caused by other issues.

FIGURE 15-19

SUMMARY

In this chapter, you learned about the different versions of SharePoint Online. Also, you saw what is supported in an on-premises deployment, as opposed to an online deployment. With the 2010 release of SharePoint Online, there is better symmetry between the on-premises and online versions of SharePoint, but to a developer there are a significant number of differences. You will have to keep that in mind as you develop your code to make it portable from an on-premises solution to a SharePoint Online solution.