Sandboxed Solutions

Deploying Sandboxed Solutions

Lately I’ve been working on some Sandboxed solution for Office 365. We all know that they differ on lots of points from Farm Solutions. On the coding end by now we know all the limitations and best practices but how about deployment of these solutions. Some experiences from my end in this post.


Maybe a no-brainer but dependencies between sandboxed solutions can be killing and may result in errors on Solution Activation level. For instance Content Type references in a List Definition with an instance attached to it. The Content Type should be in the same solution as the definition. If there are more Feature in one Solution, make sure to use Activation Dependencies. Again make sure that two different features in two different solutions don’t have any direct dependencies with each other.

Upgrading Shared Resources

When Branding is needed in a Sandboxed solution like MasterPage, PageLayouts, CSS, Images etc. we can use the SharePoint Module SPI for provisioning. However when 1 of these resources is checked out by someone else then the user who deploys and activates the Feature which holds that module, SharePoint will give a Runtime error on Activating the feature. In this case it doesn’t matter if the person deploying the Solution is a sitecollection admin. The settings on the the library for Mandatory Check Out don’t help much either. Even when this is turned off and the file is still checked out, the error occurs.

So it’s important to make SURE that all the files that need to be upgraded are Checked In! And off course this doesn’t apply only to branding files but ALL files that are being provisioned by a Module SPI.

Create a sub site based on a custom (Sandboxed) Web Template using Powershell

One quick tip when using Powershell to create a SharePoint sitestructure combined with custom Web Templates (In my case Sandboxed). The correct syntax for creating Webs based on your custom (sandboxed) Web Template is: $site = Get-SPSite http://myserver/sites/mysite  $web = New-SPWeb http://myserver/sites/mysite/subsite   $web.ApplyWebTemplate(“{FeatureGUID}#MyTemplate”)

In this case you can not use the –template parameter on the New-SPWeb method. Hopefully this post will save u the wondering why your PS script is failing.

If you are trying to figure out what the correct name is for the WebTemplate, you can also use this PS command to check which Templates are available in your current Site.

$site = Get-SPSite http://myserver/sites/mysite  $site.GetWebTemplates(lcid)

lcid off course being the language ID.

Inconvenient Recurrence Data from a SharePoint Calendar using Client OM (JS)

The CAML to get SharePoint items from lists has a nice feature when it comes to Calendar data. Using the <DateRangesOverlap/> it is possible to check if a given date is within a range of dates and when passing the ExpandRecurrence property it even takes the Recurrence Data into account. Using Sandboxed Solutions to do so we can easily set this property SPQuery.ExpandRecurrence = true; However when it comes to the JavaScript Client OM we cannot use this property.


The only way to query SharePoint for Recurrence Data using Client OM is by using theGetListItems Method from the List WebService (/_vti_bin/lists.asmx). The XML passed into the WebService can handle QueryOptions and we can use this to specify if ExpandRecurrence should be true. The Soap XML looks like this:

<soapenv:Envelopexmlns: soapenv=’’>    <soapenv:Body>     <GetListItemsxmlns =’’>        <listName>[MyListName]</listName>        <query>          <Query>            <Where>              <DateRangesOverlap>                <FieldRefName=’EventDate’ />                <FieldRefName=’EndDate’ />                <FieldRefName=’RecurrenceID’ />                <ValueType=’DateTime’>                  <Today />                </Value>              </DateRangesOverlap>            </Where>          </Query>        </query>        <queryOptions>          <QueryOptions>            <ExpandRecurrence>TRUE</ExpandRecurrence>            <CalendarDate>              <Today />            </CalendarDate>            <ViewAttributesScope=’RecursiveAll’ />          </QueryOptions>        </queryOptions>        <viewFields>          <ViewFields>            <FieldRefName=’EventDate’ />            <FieldRefName=’EndDate’ />            <FieldRefName=’fAllDayEvent’ />            <FieldRefName=’fRecurrence’ />            <FieldRefName=’Title’ />          </ViewFields>        </viewFields>        <RowLimit>10</RowLimit>      </GetListItems>    </soapenv:Body>  </soapenv:Envelope>

This example checks if there are events overlapping with <Today />. I found that it’s best to check with tags like <Today/>. <Week/>, <Month/> and <Year/> instead of using UTC Dates. Notice the <queryOptions/> wrapper passing the Options. Building regular CAML XML using the inner <QueryOptions/> tag didn’t work unfortunately. Both <ExpandRecurrence/> as <CalendarDate/> are mandatory in order for this query to work.

Tip: When using Client OM to process SharePoint data requests it’s best practice to specify as much properties as possible. Specifying <ViewFields/> will only return these fields instead of all possible fields that come with an Item. If you know the maximum amount of results specifying <RowLimit/> also helps to improve the performance on your Query.

Handling DateTime in Office 365 Sandboxed Solutions

When developing custom solutions on the SharePoint platform we don’t really think about using DateTime objects anymore. We just build solutions using server-side DateTime.Now or DateTime.Today to check Date and Time and to check that with the values we get back from SharePoint. Because we have full control over our On-Premise environment we can be sure that the Server Date and Time is correct. However moving this principal to the Cloud we loose that bit of control. We have to make sure again we get the right Date and Time from the server to do accurate checks.

Timezone of a Office 365 Server

As soon as I was testing a solution using a DateTime.Now object to get Calendar Items I came across some strange behavior when testing before 09:00 (GMT +1). I came across this article to get all Applications in the right TimeZone. It seemed that the Office 365 servers were all set to the TimeZone GMT -8 (Which is the Redmond TimeZone). So there was a 9 hour difference (I’m in Amsterdam TimeZone GMT +1).

Regional settings

Because programming it like DateTime.Now.AddHours(9); didn’t seem the right thing to do, I found a good solution to get the right DateTime.Now based on our local TimeZone. First step is to set the Regional Settings for your Office 365 SharePoint Site Collection (https://MySharePointSite/_layouts/regionalsetng.aspx) to the correct TimeZone. With this Regional Settings we can use the SPRegionalSettings object to calculated the local time at the moment of need using the following code.

       SPRegionalSettings reg = SPContext.Current.Site.RootWeb.RegionalSettings;          SPTimeZone tz = reg.TimeZone;          DateTime utc = DateTime.Now.ToUniversalTime();          DateTime utcLocal = tz.UTCToLocalTime(utc);

The utc represents DateTime.Now at GMT. With the UTCToLocalTime() method we will get the current DateTime based on our TimeZone. Now we can use utcLocal instead of DateTime.Now to get the accurate Date and Time when doing Server Side (Sandboxed) calculation with DateTime. The picture illustrates the DateTime.Now, the TimeZone ID set for the Current Site, GMT time and our LocalTime.