Posts

Avoiding deployment validation errors with SPFx packages

Image
Just a quick note on a gotcha I came across when deploying an SPFx package to the App Catalog:

In the package-solution.json file, make sure your solution name doesn't use dot notation (or for my American friends, doesn't contain periods). This appears to prevent SharePoint from recognising your .sppkg file as a valid app package.



I started with a package-solution.json file that resembled the following - a nicely-qualified solution name, or so I thought:

{
    "solution": {
        "name": "Chorus.TiledNewsPart",
        "id": "83a75dd2-26d3-4235-b4ba-d0d4a8b19443",
        "version": "1.0.0.2"
    },
    "paths": {
        "zippedPackage": "solution/chorustilednewspart.sppkg"
    }
}

When I dropped the package into the App Catalog, I saw the following:










As you can see, things don't look good:

A bunch of fields (Title, Product ID, Metadata Language) haven't been populated.The Valid Ap…

Creating Services with SPFx

Update 21st April 2017: While the SPFx service model behaves as expected on the SharePoint workbench, I've had less success when the web parts that consume the service are packaged and deployed via the App Catalog. When the script files and the service package are served locally, the service class is instantiated only once. When the script files are served from a CDN, the service class is instantiated multiple times: once by each web part that consumes the service. The call to ServiceKey.create is also executed once for each web part that consumes the service - which effectively means that the page-level ServiceScope hosts multiple instances of the same service, each registered against a different ServiceKey object. I can only assume that this is due to a nuance of the bundling process that I'm missing. The result of this is that the SPFx service model isn't currently all that useful to me for sharing data between web parts. As a workaround, I've reverted to storing da…

SharePoint Framework POST requests: watch out for OData version incompatibility

This week I've been building a SharePoint Framework web part that queries a Pages list, amongst other things. For reasons that I won't go into, I need to do this by sending a CAML query to the server. The usual way to do this is to send a POST request to the getitems REST endpoint:

[Web URL]/_api/web/lists/getbyid('[List GUID]')/getitems

Where the body of the request contains your CAML query:

'query': {
   '__metadata': {'type': 'SP.CamlQuery' },
   'ViewXml': '<View><Query><Where>...'
}

To do this the SPFx way, we leave jQuery.ajax behind and use the SPHttpClient.post method. However, when I did this, the server returned an HTTP 400/Bad Request response with the error message:

The property '__metadata' does not exist on type 'SP.CamlQuery'. Make sure to only use property names that are defined by the type.

After a bit of trial and error in Fiddler, I found the problem:

The SPHttpClient class ap…

Getting or Setting Multi-Value Metadata Fields with the REST API

Image
A couple of years ago, I published a series of posts on getting and setting taxonomy field values in SharePoint workflows by using the REST API in custom workflow activities. These custom activities have served me well, but they've always been unable to work with multi-value taxonomy fields. It's time to fix that.

Background As you probably already know, when you add a taxonomy field to a SharePoint list, SharePoint adds a corresponding hidden note field. For example, if you add a taxonomy field named Colours, you actually get:

A taxonomy field named Colours. Depending on whether the column allows the user to select multiple terms, the field accepts values of type SP.Taxonomy.TaxonomyFieldValue or Collection(SP.Taxonomy.TaxonomyFieldValue).A hidden note field, probably named Colours_0.  The hidden note field stores the contents of the field in a term string format. In a single-value taxonomy field, the format looks like this:
Red|87999a76-e3cb-433c-96ad-c6fe354db476
And in a mult…

Controlling start options for SharePoint workflows in Visual Studio

Image
When you build a reusable SharePoint workflow, it's useful to be able to control which start options are available. For example, if you only want your workflow to run once when an item is created, it makes sense to disable the "Changing an item will start this workflow" option.

SharePoint Designer provides some handy checkboxes that you can use to control your start options:










However, it's not immediately obvious how you can set these options for a Visual Studio workflow as the options aren't documented anywhere.

To control the start options for a SharePoint workflow in Visual Studio, you need to edit the feature element file that deploys your workflow. Within the feature element file, you need to add properties to the File element that deploys your Workflow.xaml file:

<?xmlversion="1.0"encoding="utf-8" ?> <Elementsxmlns="http://schemas.microsoft.com/sharepoint/">   <ModuleName="[Workflow Name]"Url="wfsvc/1c…