sppkg file not creating properly

[jpheeter]

Category

• [X] Question
• [x] Bug
• [ ] Enhancement

Expected or Desired Behavior

When copying the sharepoint-starter-kit.sppkg either manually or using the deploy.ps1 script I would expect the package to show information from package-solution.json I would expect to see a different version number. I would expect to see the App Depolyed=Yes

Observed Behavior

In the SharePoint App Catalog the App version is 1.0.0.0 and there is no Product ID. The sppkg Deployed=No

I think because of the sppkg not packaging properly and not being deployed the rest of the Deploy.ps1 script is failing.

---

Apply-PnPProvisioningTemplate : {"error":{"code":"-1, Microsoft.SharePoint.Client.ResourceNotFoundException","message":{"lang":"en-US","value":"Exception of type 'Microsoft.SharePoint.Client.ResourceNotFoundException' was thrown."}}} At C:\VSC\Code\sp-starter-kit-master\sp-starter-kit-28\provisioning\deploy.ps1:98 char:5

• Apply-PnPProvisioningTemplate -Path "$PSScriptRoot\solution.xml" ...

• 
  + CategoryInfo          : WriteError: (:) [Apply-PnPProvisioningTemplate], Exception
  + FullyQualifiedErrorId : EXCEPTION,SharePointPnP.PowerShell.Commands.Provisioning.ApplyProvisioningTemplate
  -------

What bothers me most is last month I was able to deploy the starter kit without errors but when I wanted to customize the installation it started failing.

I have tried this using two laptops with VSC installed and had the same error I have updated all of the npm and gulp and had the same error I have spun up a new O365 dev instance and still received the same error I have slow stepped myself through the pre-reqs so all of that should be fine.

I think my issue is focused on the creation of the sppkg but I'm not sure how to fix that.

Steps to Reproduce

I just followed the instructions for setup and deploy. Same issue when dragging the master copy of the sppkg directly into the app catalog after unzipping.

Thanks for your contribution! Sharing is caring.

[mrik23]

I just tried to upload the package file provided in the solution to the tenant app catalogue but nothing happens. Tried in Chrome and Internet Explorer.

https://github.com/SharePoint/sp-starter-kit/blob/master/package/sharepoint-starter-kit.sppkg

[mrik23]

Tried to repackage without any modification, but still getting nothing when uploading the package.

If I package the basic helloworld webpart, it works fine.

[PrinsMild]

I have the same experience. The app doesn't have an ID. It happends on all tenants I have tried uploading to, and all are set to pre release. Any other package deploys and have an ID.

[adamtoad]

I have the exact same problem. Nothing shows up when I manually deploy on tenant app catalog, and when I try deploying using deploy.ps1 I get the same error message as jpheeter did.

[jpheeter]

Thanks everyone for the verification... This is exciting, I was afraid I was just doing it wrong!

[mrik23]

OK, so we are not alone. Let's wait for a fix.

For the time being, I'm trying to found out how I can package single webparts, instead of everything.

[PrinsMild]

I would like to add that I also tried to pack and Gulp the solution myself, but with the same result. Adding with PnP also fails. Get-PnPApp results nothing.

[PooLP]

Same issue for me on a new English tenant.

[LeonardoSilva01]

Same behavior here either. I´ve just create a trial tenant to make sure that it wasn´t a problem with our global tenant.

So, let´s wait. Tks all.

[JulianKuenzel]

Hello- the following did the trick for me:

https://github.com/SharePoint/sp-starter-kit/issues/158#issuecomment-424321563

to get the "new" sppkg just follow the following steps: https://github.com/SharePoint/sp-starter-kit/issues/158#issuecomment-424319762

Otherwise just wait till the repo get updated with the correct package-solution.json

[eoverfield]

Hi all, I want to provide an update on the current status of the master branch per early Oct 2018. The master branch is based on SPFx 1.4.1, which utilizes '@microsoft/sp-client-preview' for MSGraphClient. With the recent upgrade to SPFx 1.6 in the backend of SPO, MSGraphClient was moved to its production module, and although I cannot confirm this all right now, it appears as though MSGraphClient was removed from sp-client-preview (as expected). Thus when the sppkg is attempting to be installed, since a module is effectively missing, the package install fails.

Updating the package-solution.json schema as we have seen here (https://github.com/SharePoint/sp-starter-kit/issues/158#issuecomment-424321563) wouldn't be enough to fix the issue, the module loading for MSGraphClient must also be updated in webparts.

This is why the current dev branch is working for us. @waldekmastykarz made amazing progress a few weeks back updating the entire kit to spfx 1.6. Until the core team merges dev into master, we have a few options.

1. use the dev branch. This works yet be aware it is more dev-y than master, thus you may want to test more than normal before going to production. Also, I suggest for now you stick with the traditional kit deployment procedures. @erwinvanhunen and @PaoloPia are working on a new provisioning process that is not yet fully available.
2. take the master branch and update that to SPFx 1.6 yourself. Not sure why you would do this, but it should work.
3. remove all webparts (the "personal" ones) as well as any reference you find to MSGraphClient and the preview module. Rebuild the sppkg and redeploy. Along with option 2, not sure why you would do this.
4. wait until dev is merged into master. I am trying to get an update on timeline for this for us all. No word yet, hopefully very soon.

Related to issue: https://github.com/SharePoint/sp-starter-kit/issues/71 as well.

[mrik23]

@eoverfield thanks for the details and update.

[mrik23]

Tested with the dev branch, and it seems to work fine.

https://github.com/SharePoint/sp-starter-kit/tree/dev

[erwinvanhunen]

A small update from the core team working on the starter kit: early next week we will release an updated version of PnP-Sites-Core and PnP PowerShell which contains the code for the updated provisioning process we demoed and introduced during Ignite 2018. This means that provisioning the starter kit will be a matter of typing "Apply-PnPProvisioningHierarchy StarterKit.pnp". The PnP file we provide contains all templates, all support files needed (images, etc.) and a compiled/packaged version of the webparts. The PnP file is a zipped/office open xml file which contains all files. There is a single template xml file in the package that contains 5 provisioning templates that are being applied to sites which have been defined in the sequence that is part of the same file. We will also update the readme.md file to explain this process. Notice that is not required to use the pnp file, you can also point the cmdlet to an xml file containing a full provisioning hierarchy. The hierarchy is made up of a sequence containing one or more sites, templates, support files, etc.

It's a relatively simple process to create your own starterkit based upon a modified template xml file. You update the starterkit.xml file to your likings (notice, the file is pretty big and you should take your time to dive into what we are doing here as we are using the engine to the fullest). After updating the sequences /templates/packages you can generate a new PnPfile like:

$mystarterkit = Read-PnPProvisioningHierarchy -Path myfile.xml
# at this time you can move things around if needed, or change parts your hierarchy by modifying the $mystarterket object. We have a specific cmdlets for that.
Save-PnPProvisioningHierarchy -Hierarchy $mystarterkit -Out myfile.pnp
# the Save-PnPProvisioningHierarchy cmdlet will read all files referenced in the hierarchy and then save everything to the PnP file that has been specified with the -Out parameter

More to come at a later stage, but keep an eye on the starterkit repository for now for updates.

[eoverfield]

@erwinvanhunen thank you for the update, outstanding news!

[VesaJuvonen]

The root cause of the original issue is too many permission scope requests, which are then causing a challenge due to field size limitations. If you reduce the number of requested scopes from the package-solution.json, things are working again properly. The root cause is oob issue, but the version in dev branch is working already properly as we reduced the number of scope requests. We are also working on the SharePoint engineering side to address the oob issue.

This issue then got sideways with many many other messages, but the solution in the dev branch will be working properly and will be published as long as we can get the PnP PowerShell/CSOM October release out.

[eoverfield]

@VesaJuvonen Ah, very good to know about that limit, thanks!

[PrinsMild]

Yeah! Thanks! Now it finally warks again!

[VesaJuvonen]

thx @PrinsMild for confirming this, closing the issue as fixed.