Solvedsp dev docs Breaking change on creating content types using CSOM - Value cannot be null

Category

  • Question
  • Typo
  • Bug
  • Additional article idea

When applying PnPTemplate that contains a content type definition, provisioning fails with the error:
"Apply-PnPProvisioningTemplate : Value cannot be null.
Parameter name: s"

I have observed the problem on 14.05.2019 without changes to PnP engine version (used the latest one). I believe that the problem is not related to PnP but to O365 backend. Sample template definition that fails:

<?xml version="1.0"?> <pnp:Provisioning xmlns:pnp="http://schemas.dev.office.com/PnP/2018/05/ProvisioningSchema"> <pnp:Preferences Generator="OfficeDevPnP.Core, Version=2.20.1711.0, Culture=neutral, PublicKeyToken=3751622786b357c2" /> <pnp:Templates ID="TEST-TEMPLATES"> <pnp:ProvisioningTemplate ID="TEST" Version="1" Scope="RootSite"> <pnp:SiteFields> <Field Type="Text" DisplayName="TestField" Name="TestField" StaticName="TestField" Description="TestField" Required="FALSE" EnforceUniqueValues="FALSE" Indexed="FALSE" MaxLength="255" Group="TEST" ID="{b280c2fa-7aba-40a2-8d9a-e2e23984c305}" SourceID="{{siteid}}" ></Field> </pnp:SiteFields> <pnp:ContentTypes> <pnp:ContentType ID="0x0100240A55DF4AAE484BAFA63308338F5501" Name="TestCT" Description="" Group="TEST" NewFormUrl="" EditFormUrl="" DisplayFormUrl=""> <pnp:FieldRefs> <pnp:FieldRef ID="fa564e0f-0c70-4ab9-b863-0177e6ddd247" Name="Title" Required="true" /> <pnp:FieldRef ID="b280c2fa-7aba-40a2-8d9a-e2e23984c305" Name="TestField" /> </pnp:FieldRefs> </pnp:ContentType> </pnp:ContentTypes> </pnp:ProvisioningTemplate> </pnp:Templates> </pnp:Provisioning>

Observed Behavior

Exception is thrown:
Apply-PnPProvisioningTemplate : Value cannot be null.
Parameter name: s
At line:1 char:1

  • Apply-PnPProvisioningTemplate -Path $path
  •   + CategoryInfo          : WriteError: (:) [Apply-PnPProvisioningTemplate], ServerException
      + FullyQualifiedErrorId : EXCEPTION,SharePointPnP.PowerShell.Commands.Provisioning.Site.ApplyProvisioningTemplate
    

Steps to Reproduce

Deployment of PnP Template with CT definition. Attached sample can be used.

Thanks for your contribution! Sharing is caring.

47 Answers

✔️Accepted Answer

Thanks everyone for confirming that the workaround fix in the PnP PowerShell and NuGet package side is working as expected.

Status on the root issue on the server side APIs:

  • Issue has been identified and fixed in the server side source code
  • Fix is planned to get fully applied to production worldwide within next 36 hours
  • Any customer who have opened a Premier Support case will be prioritized for patching

This means that the root issue at the server side APIs should be fully fixed by end of the day Friday 17th of May. We will be doing an internal postmortem analyses on this issue to minimize possibility for similar mistakes in the future.

We will be rolling back the workaround fix in the PnP components latest by June 2019 release as it does have a small impact on the supported capabilities, but we need to ensure that the ContentType.FieldLinks.Reorder method is first fully fixed in the server side, before this can be performed.

We will be providing any updates on this issue still during this week, but will close it when we have confirmed that the patch is fully deployed worldwide. We do apologize the inconvenience caused by this accident.

Other Answers:

We just confirmed this to be a change on the server side APIs related on the field reorder, like also mentioned above by @cverhelst and @vladivanovrf. It's caused by a situation where you execute the fields reorder without any fields for a content type. Recent change in server side API did not take this into account and unfortunately PnP provisioning engine will call the reorder for fields in a content type regardless if there are any.

We are working now on two sides:

  • New PnP Sites Core CSOM assembly will be released today (ETA few hours) which will do the workaround for skipping the ReOrder call for content type when there's no fields. This will address the issue from PnP provisioning engine perspective in upcoming hours.
  • We have internal threads moving on addressing the server side API change to include a checkup for the fields, which will be addressed in server side code. Getting that changed deployed worldwide will take much longer after the requested change has been approved, but will update this thread on the progress as have any.

Thanks everyone for sharing your test results and insights on the repro. These helped us to move forward on providing initial fix as fast as in few hours after identifying the root cause.

Root cause of the issue - if you execute following code, you will get the same exception:
ContentType.FieldLinks.Reorder(new string[] { });

thx @SBajonczak for confirming the provisioning engine fix in the PnP CSOM Core NuGet package.

ETA for PnP PowerShell workaround fix is 2-3 hours.
No ETA at this point for the server side API root issue.

We will keep on updating this thread as we have any updates.

Just to follow up on the progress.

Thanks for opening the Premier Support cases for following up on the server side API issue. These are good for tracking the root cause and ensuring that it gets fixed as soon as possible.

Thx @siata13 for reporting this. This seems to be a breaking change in the server side, which we are now actively investigating. Here's a duplicate entry in the PnP Sites Core and in the PnP PowerShell repositories for this one for tracking purposes. I also changed the title to be more descriptive with the oob capabilities as this is not about the PnP wrapper.

In short - there seems to be a breaking change in the oob CSOM for handling content types in server side.