I’ve recently been involved in creating a SharePoint Hosted add-in for a customer, and part of that process includes creating site columns, content types, and libraries in the host-web where the add-in is deployed. The Office Dev Patterns and Practices team has a great starting point example for this technique using the JavaScript (JSOM) api.
All was going well – we built and tested our code against a Developer site collection in our Office 365 tenant, and then packaged it up to deploy in the customer’s tenant.
But no sooner did we attempt to run the provisioning script did we get the following error when checking for site columns
This was a Tuesday morning. We reviewed and reran the add-in on our Dev tenant, and it continued to work.
At first I thought maybe it was something having to do with the asynchronous callbacks from the JSOM api – and that we were dealing with a timing or sequence issue. But as I debugged it revealed that the error was thrown on the initial query – never allowing subsequent calls to be made.
Here’s the basic code I was running to query the list of site columns from the host web.
As I continued to troubleshoot on my Dev tenant, suddenly, I started getting the same error in that environment. Strange, right? This delay made me wonder if there may have been a rollout of a CSOM update that hit my client’s tenant that morning, then my tenant by the afternoon.
I worked with my customer and we opened a MS Support ticket.
The support engineer ran a similar API call against a tenant in the same datacenter as ours, and it came back clean.
We did a screen-share, and I demonstrated the error and provided him the CorrelationID returned in the response. From there he was able to see a stack trace indicating that the failure occurred on a Enum.TryParse() method call. Interesting. He confirmed our code looked okay, and escalated the case to a Development engineer.
On our second call, we again demonstrated the error when calling the api against our tenant and our client’s. At first the MS engineer thought it may be related to lookup type columns, so we manually removed a couple that were User and Group type columns. No change.
We then decided to try to manually remove all the custom columns and reprovision from scratch. Upon clicking on the first one (called ‘Current Item Title’) we got an error in the UI. That was unexpected.
One thing I noticed, however, was that the Current Item Title column, which should have been a ‘Single line of text’ was actually showing as a ‘Hyperlink or Picture’ type.
I returned to my code and checked my manifest of field definitions. Quickly I realized the issue, as shown in the before and after images below.
The Field Type=’URL’ indicated that it was a Hyperlink field – but the Format=’Text’ was causing the exception, since the value ‘Text’ was not a valid option in the SPUrlFieldFormatType enumeration. Suddenly it all came clear. I’d copied and pasted the field definition, and changed the wrong parameter.
We had to manually remove the column using PowerShell (since it caused the error through the UI). I then corrected the field schema definition and republished my add-in. This time through, the provisioning script ran clean, and correctly created the Current Item Title column as a text field rather than URL.
UPDATE: Here’s the PowerShell to remove the field. Basically we just retrieve it by name, then delete it – all using the SharePoint Client Object Model (CSOM).
(I did complain to the MS engineer about why the API would allow me to pass in a bad value when creating the field, yet throw an error when trying to retrieve the field. He offered me the url to the UserVoice for SharePoint where I could submit my complaint.)
This cut-and-paste error cost our project a full week on the timeline (due to the back and forth delays with the MS escalation, etc.) and required 2 Microsoft engineers to assist in resolving.
Leave a Reply