
There can be times when a SharePoint Add-in instance just won’t install (or uninstall). You get the familiar “We’re adding your app” message on the new tile that has been added to the Site Contents page but nothing changes – it just stays like that.
Content relating to the development of custom solutions for SharePoint.
There can be times when a SharePoint Add-in instance just won’t install (or uninstall). You get the familiar “We’re adding your app” message on the new tile that has been added to the Site Contents page but nothing changes – it just stays like that.
Here’s a summary of some of the hints and tricks I’ve picked up while working with SharePoint Designer 2013 (SPD). Some are to fix issues that SPD introduces itself, and others are just things to make using the tool a little less painful.
Recent versions of SharePoint have exposed a rich tapestry of options for interacting with it without needing to resort to server-side code-based solutions. The main ones that I’m going to talk about here are the JavaScript Object Model (JSOM), SharePoint Web Services, and the RESTful API.
When developing SharePoint Add-ins there may be times when you want to access and store some data on the host web an app instance has been deployed to instead of holding it on the app web (as the app instance website is the default).
There are many times when you want to display filtered views of SharePoint lists by default. Sure, you can create a custom view – and that is often the best approach – but what if you want a configurable query? Then this simple ‘hack’ can be perfect for the job.
Everyone knows how to create lists via the web browser, but for developers it can often be easier and more controlled to use automation to create lists on target SharePoint sites, for custom solutions they are developing, and the easiest way to do that is often using PowerShell.
When developing new sites in SharePoint, using the web interface or SharePoint Designer is all well and good but it can become cumbersome when naming columns, getting their internal names, etc. A much better way is to use SharePoint’s rich PowerShell functionality.
When using MS Excel to provide reports from SharePoint (SP) data, a common problem is managing the size of the dataset being retrieved. SP sites are notoriously long-lived and data can grow and sprawl over time, with lists having 100,000s or even millions of items in them, and Excel reports linked to those lists can take so long to load they are all but unusable. Using an OData query can help get around these issues.
SharePoint doesn’t officially support timer based workflows out of the box. Various hacks can be instigated to attempt to achieve this, and the most common one is to set up looping workflows that call other workflows. The drawback of this approach is that normally, at some point, the workflow looping breaks down and a user will therefore need to monitor, detect failure, clean things up, and then kick everything off again. True timer-based workflows can be approximated to some extent by SharePoint’s Information Management Policy options.
This article introduces development of custom code activities that can be deployed to a SharePoint server farm. This greatly increases the scope of use of workflows in SharePoint by making it possible to publish activities that extend the built-in capabilities of the solution.