Tag Archives: CSOM

Client Side Object Model

Installing SharePoint 2013 Apps programmatically: what’s possible, what not?

Last week I was looking for a solution to install SharePoint Apps using Server Side Object Model (SSOM) or Client Side Object Model (CSOM). Microsoft does not really support this scenario as it is not the preferred ways to use Apps. Normally end users should install Apps themselves on sites they want. In this post I will cover the possibilities of provisioning Apps using code. But I investigated the API to see if there is a way to support the sample scenario somehow.

Scenario: I want a Web Service which enables me to provision Apps from the App Catalog Site Collection on request to a Web on a specific Site Collection. The Web Service should be a Full Trust Code solution which grabs the App in the App Catalog and provisions it. The App Catalog should be used to make it easy to deploy new Apps from a central place and to support versioning in an easy way:
Deploying Apps

Now we know what we want we can look into the API which is present in SharePoint and see what possibilities we have. Microsoft offers not much API’s for provisioning Apps. When browsing on the internet you will probably find a method called LoadAndInstallApp on the SPWeb object. This method however only accepts stream object to a binary representation of the .app file. The .app file is actually a zip file containing the application. The disadvantage of this solution is that you have to upload the App to every single Web where you want to deploy this App and not using the advantage of a central location like the App Catalog to distribute the Apps and taking care of versioning. A sample of how to install apps using SSOM can be found on MSDN Blogs.

When digging further in the SharePoint DLL’s using ILSpy you will notice that there is no publicly available API to install Apps directly from the App Catalog. Internally there are some methods available, as it is possible from UI to add an app from a Corporate Catalog on a Web. A possible workaround is to retrieve the App file from the App Catalog (it is internally just a list) and then forward the stream object to the LoadAndInstallApp method. This works however SharePoint doesn’t notice then that the App is coming from the Corporate Catalog. In case a new version of the App is installed on the App Catalog, SharePoint doesn’t know that the App which is installed on that specific Web is updated and can’t notify the site owner by a notification that an update is available (SharePoint won’t push new versions automatically!). Another thing which you’ll notice is that when opening the Site Contents page and open the context menu on the installed App that the About option is missing. This page is very important, as this page normally allows an end-user to update the App and see if an update is available. So this means that the end-user can’t update the App properly from UI. Conclusion:The API is not that mature to use it in a professional environment to support scenario’s like this. We need to hope that Microsoft will come with an API to support scenario’s like this in future. Currently it seems not to be possible to programmatically install an App from the App Catalog into a Web.

I also want to mention the CSOM variant of the LoadAndInstallApp method. It is present in both the .NET Managed CSOM and Javascript library. However when you call it, you will get an error that it is only supported when sideloading is enabled. Sideloading should only be used in development environments. Therefore CSOM doesn’t provide a way to deploy Apps programmatically in SharePoint on production environments. There reason is probably to reduce the risk to install corrupt Apps or Apps which can delete or malform existing data in the Web.

SharePoint 2013 Lazy loading Javascript

In SharePoint 2013 the Javascript loading mechanism seems to be changed a bit. When porting a SharePoint 2010 solution to 2013 I found out that sometimes some weird script errors where occuring when calling SharePoint Javascript libraries. On some pages in SharePoint 2013 it happens that not all SharePoint Javascript libraries are loaded because of the built-in lazy loading mechanism. This reduces bandwidth when loading pages, because no unneeded libraries are downloaded to the client. But this causes issues when you want to use not loaded libraries. The following sample Javascript codes shows how you can load some Javascript Libraries and then automatically call your function where you want to use those libraries:

//Register SOD's
SP.SOD.registerSod('core.js', '\u002f_layouts\u002fcore.js');
SP.SOD.executeFunc('core.js', false, function(){});;
SP.SOD.registerSod('sp.js', '\u002f_layouts\u002fsp.js');
SP.SOD.executeFunc('sp.js', false, function(){});
SP.SOD.registerSod('sp.core.js', '\u002f_layouts\u002fsp.core.js');
SP.SOD.executeFunc('sp.core.js', false, function(){});

function doSomething() {
   //Your Logic here which calls sp core libraries

// Load asynchronous all needed libraries
ExecuteOrDelayUntilScriptLoaded(function() { ExecuteOrDelayUntilScriptLoaded(doSomething, 'sp.core.js') }, 'sp.js');

In the example above we’re using the SP.SOD library provided with SharePoint. Those existed already in SharePoint 2010 and are still present in 2013. With the SOD library it is possible to lazy load Javascript files and load them on the moment you need them. The sample script exists of three parts. In the first step we register Sod’s (Script on Demand) where we define a key and as value the relative path to the Javascript file. We also call executeFunc to load the file using a dummy function. In the second step we create a custom function. This is the function where you want to call specific methods in the Javascript libraries loaded. Then we call ExecuteOrDelayUntilScriptLoaded. Because in this sample we want both sp.core.js and sp.js loaded, we nest it with another call to ExecuteOrDelayUntilScriptLoaded and finally let the callback call the function which needs the libraries loaded before executing. This method of loading scripts seems to work well in SharePoint 2013 and can also be used for other OOTB Libraries, like the Taxonomy Javascript Library. When your site is still running in SharePoint 2010 mode however, this doesn’t work properly. The registering of Sod’s seems to break with the 2010 way of loading the OOTB Javascript files so there you need only the ExecuteOrDelayUntilScriptLoaded calls. If you need to detect the mode in Javascript you can use the SP.Site.get_compatibilityLevel() function to retrieve that info using JSOM and then dynamically decide which method of loading to use.