Archive for Deployment

Inconvenient (Sandboxed) Custom ListDefinitions

Building custom SharePoint Online solution a List Definition is likely to be a SPI you would like to use. Sandboxed Solution look like a good way of deploying these definitions to your SharePoint Online environment, but are they?

Language
When we deployed custom List Definitions we came across strange behavior accessing these lists. Suddenly the language changed from Dutch (nl-NL) to the default language (en-EN). Together with the help of MS we found some interesting information in the Logs. SharePoint was trying to access a resource file we didn’t deploy.

Localized Strings
A SharePoint Feature comes with the property DefaultResourceFile. This property can be set with the Feature Properties. When empty SharePoint will try to get the resource from “%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATES\FEATURES\FeatureName\Resources\Resources. Culture.resx” when a resource is requested by a Localized string. When you create a ListDefinition in Visual Studio the Schema.xml is being generated for you. The <List /> element contains an Attribute called Direction which is a localized string. Direction=”$Resources:Direction;”

The Localized string doesn’t refer to a default Resource file but instead it tries to get the Resource from the DefaultResourceFile. This results in an error when you are not deploying a Resource File to this location containing “Direction”.

Solutions
This blogpost states that with SP1 the problem is resolved. http://www.mysticslayer.com/?p=211 However together with MS we found out that the error in the Log files still occurs in SharePoint Online. The easiest way to fix this is to replace the localized string in your schema.xml for a hardcoded value. MSDN explains what values can be used (http://msdn.microsoft.com/en-us/library/ms415091.aspx).

If you don’t want to choose this option for some reason, according to MS you can also choose to reference the Core Resource file Direction=”$Resources:core,Direction;”. This didn’t give me the error on premise, but obviously I couldn’t test it in Office 365 because I’m not able to check the Log files. I didn’t experience the language change as before so I assume this is a good option. Still the value in the core resource file for Direction is 0 which is not given as an option according to MSDN. My guess is that SharePoint sees this as “none”.

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.

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.

Dependencies

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.