[X] Bug
[ ] Enhancement
[ ] Office 365 / SharePoint Online
[ ] SharePoint 2016
[x] SharePoint 2013
If SharePoint on-premises, what's exact CU version: June 2016
Please note im using PnP PowerShell to report this issue, but its not related to PnP PowerShell, but rather with the ObjectPageContentsHandler
https://github.com/SharePoint/PnP-Sites-Core/blob/master/Core/OfficeDevPnP.Core/Framework/Provisioning/ObjectHandlers/ObjectPageContents.cs#L231
Remote provisioning is successful
You get the following error
PS C:\code\temp\testcase> Apply-PnPProvisioningTemplate .\template.xml
powershell.exe Information: 0 : 2016-11-30 13.29.59.4415 [OfficeDevPnP.Core] [0] [Information] File template.xml retrieved from folder 0ms
powershell.exe Information: 0 : 2016-11-30 13.29.59.4434 [OfficeDevPnP.Core] [0] [Information] File template.xml retrieved from folder 0ms
powershell.exe Information: 0 : 2016-11-30 13.29.59.4745 [Provisioning] [10] [Debug] Code execution scope started 0ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.29.59.4753 [Provisioning] [10] [Information] ProgressDelegate registered 0ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.29.59.4763 [Provisioning] [10] [Information] MessagesDelegate registered 2ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.30.04.0407 [Extensibility Providers] [10] [Debug] Code execution scope started 0ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.30.04.0417 [Extensibility Providers] [10] [Debug] Code execution scope ended 1ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.30.04.3356 [Lookup Fields] [10] [Debug] Code execution scope started 0ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.30.07.1325 [Lookup Fields] [10] [Debug] Code execution scope ended 2796ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.30.07.1505 [Files] [10] [Debug] Code execution scope started 0ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.30.07.8943 [Files] [10] [Debug] Uploading and overwriting existing file Hjemmeside.aspx 744ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.30.08.2418 [OfficeDevPnP.Core] [0] [Information] File Hjemmeside.aspx retrieved from folder 0ms
powershell.exe Information: 0 : 2016-11-30 13.30.08.2428 [OfficeDevPnP.Core] [0] [Debug] Creating file info with Url 'Hjemmeside.aspx' 0ms
powershell.exe Information: 0 : 2016-11-30 13.30.08.6958 [Files] [10] [Debug] Code execution scope ended 1546ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
powershell.exe Information: 0 : 2016-11-30 13.30.08.6977 [Provisioning] [10] [Debug] Code execution scope ended 9222ms 64b7781a-06ac-4561-99a4-cf3125aa36e1
Apply-PnPProvisioningTemplate : Method not found: 'System.String Microsoft.SharePoint.Client.WebParts.WebPartDefinition.get_ZoneId()'.
At line:1 char:1
+ Apply-PnPProvisioningTemplate .\template.xml
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (:) [Apply-PnPProvisioningTemplate], MissingMethodException
+ FullyQualifiedErrorId : EXCEPTION,SharePointPnP.PowerShell.Commands.Provisioning.ApplyProvisioningTemplate
Use the attached testcase.zip to reproduce
1) On SharePoint 2013 (or possibly 2016) create a new site collection based on a teamsite (STS#0)
2) Connect to the site using PnP PowerShell
Connect-SPOnline -Url <url to site collection>
3) Enable tracelogging
PS> Set-SPOTraceLog -On -Level Debug
4) Apply the provisioning template
PS> Apply-PnPProvisioningTemplate .\template.xml
Please note i've used the following release during my test
SharePointPnPPowerShell2013 2.9.1611.0
I reproduce this issue too with the latest release version (PowerShell.2013 2.10.1612.0)
Reproducible in CU August 2016 (15.0.4849.1000)
Seems to work as expected in CU October 2016 (15.0.4867.1000)
Edit: Also seems to work on a really old CU (15.0.4569.1000), so I'd wager that it's a bug in SP, which was introduced pretty recently, but then fixed in the one of the most recent CUs.
Does this mean that the PNP engine wil not work for Team Site 2013 on premise?
Can Anyone from MS or GITHUB Confirm what robbie has mentioned this so that we can plan whether to use PNP code for site provisioning?
Same here, I'm unable to provision WebParts for SharePoint 2013 using the PnP provisioning engine. I tried with the January 2017 CU, October 2016 CU, and SP1 for SharePoint 2013 and it doesn't work. I used the PnP PowerShell January 2017 cmdlets (v 2.11.1701.1).
This relates on issue with OOB CSOM Assemblies for providing us reliable mechanism in on-premises to check the used version. Core component used to use clientContext.ServerLibraryVersion property for detecting the used version. This oob API does not however work reliably in the on-premises and is providing wrong value as the version. We have now applied a fix to teh code where we use http header based detection on the used servers. This fix is currently in the dev branch and will be released as official NuGet package on 10th of February (next release date).
Thank you @VesaJuvonen! Looking forward to the next release cc: @olemp @wobba
Hello, I have a console application and exporting a Team Site from SP 2013 on-premise (CU June 2016) get the same error while exporting the site. I'm using the SP Core Library version 2.11.1701.1
Hi eariel, this is due the version detection issue with oob CSOM assemblies. We have fixed this now to our code and it will be shipped as NuGet package on 10th of February. If you need this fix right away, you could potentially compile a version from the dev branch.
Also hitting this issue worked then started hitting this everytime. I'll try pulling and building given I need it sooner.
Closing this one since its fixed as mentioned by Vesa.
This issue is still here today when provisioning files to sharepoint 2013 onpremises.
I believe this is due to due to web.Context.HasMinimalServerLibraryVersion(Constants.MINIMUMZONEIDREQUIREDSERVERVERSION) not working reliably, or at least not guaranteeing that we have the ZoneID varialble availiable. All other places are using complier flags to exclude the calls to ZoneId for 2013, so i believe we should do the same here.
cc: @VesaJuvonen @jansenbe
This issue is still here as of august 2017 with the SharePointPnPPowerShell2013 2.17.1708.1 version
We closed this issue as it had not activity within last 180 days. This is a generic process we have decided to perform for issues, which have not been explicitly marked still to be "work in progress" based on tags. We are performing this cleaning to make sure that old issues that have already been solved (but not closed) or are no longer relevant are cleaned out and make the issues more manageable. If this issue still valid, we would ask you to open a new issue and follow the guidance in the issue template related on the recommended location. We do apologize any inconveniences this might cause. Please do remember that issues in the issue lists are also messages for others in the community, so you can also check if you can assist on any of them. “Sharing is caring!”
Most helpful comment
This relates on issue with OOB CSOM Assemblies for providing us reliable mechanism in on-premises to check the used version. Core component used to use clientContext.ServerLibraryVersion property for detecting the used version. This oob API does not however work reliably in the on-premises and is providing wrong value as the version. We have now applied a fix to teh code where we use http header based detection on the used servers. This fix is currently in the dev branch and will be released as official NuGet package on 10th of February (next release date).