Sp-dev-docs: Asset Packaging error when the solution name has - in the name

[joaoferreira]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

Being able to deploy a valid package to the app catalog

Observed Behavior

When the solution name has a - in the name the sppkg will throw an error once the web part is added to the app catalog. This behaviour was observed on global app catalog and also in the site collection app catalog. The error messages is Invalid SharePoint App package. Error: Part URI is not valid per rules defined in the Open Packaging Conventions specification.
This error is caused by the assetpackagingwebpartstrings file located in the ClientSideAssets folder inside the package. Instead of using the - the file is created with a space in the name and it breaks the OPC specification.

Steps to Reproduce

1. Using yeoman generator create a new web part with a - in the name
2. Run the command gulp bundle --ship
3. Run the command gulp package-solution --ship
4. Add the package file to the app catalog

[jaredbuttars]

I have this same problem, unfortunately - the error persists even after removing the dashes.

[jaredbuttars]

After some experimenting, It's actually related to the CDN basepath not the package name.
when set to the folllowing in order to package assets into the sppkg:

"cdnBasePath": "<!-- PATH TO CDN -->"

The package is invalid with the error:

Invalid SharePoint App package. Error: Part URI is not valid per rules defined in the Open Packaging Conventions specification.

[kulkarnichief]

Same problem for me too even after completely updating manifest and package solution files

[kduenke]

I ran into this too. It showed up when I added "includeClientSideAssets": true to my package-solution.json file and built to ship. The fix for me ended up being to rename the directory that held my git project to remove any spaces from it. After that, it deployed fine.

[aslanovsergey]

I get the same problem today with SPFx 1.4.1

Invalid SharePoint App package. Error: Part URI is not valid per rules defined in the Open Packaging Conventions specification.

if I set "includeClientSideAssets": false the problem goes away but webpart doesn't work accordingly

[colonelclaypoo]

I can confirm that I have the same issue. I followed the tutorial series but did not opt to enable an O365 or Azure CDN.

[aslanovsergey]

Very nasty bug, have no idea how deploy my web part. Removing spaces in folder, shortening solution name didn't help... PnP Team please look at it, I would give maximum importance to this ticket

Name of folder(before it was with spaces and I replaced spaces with dashes): shared-mailbox-access-approval-request-form
package-solution.json
{ "$schema": "https://dev.office.com/json-schemas/spfx-build/package-solution.schema.json", "solution": { "name": "shared-mailbox-access-approval-request-form-client-side-solution", "id": "eaa1a1a1-d2fa-44db-a28c-0ae53021d73e", "version": "1.0.0.0", "includeClientSideAssets": true }, "paths": { "zippedPackage": "solution/shared-mailbox-access-approval-request-form.sppkg" } }

[jesusvelasco93]

I could correct that error change the name folder that have the project without dashes ("-") and spaces (" ").

[mcraiha]

Removing whitespace from path helped in here.

[aslanovsergey]

What helped me was cleaning temp/deploy folder

[JLRishe]

This seems to have to do with the way that the string resource files are bundled. The generated .js files seem to be prefixed with the name of the folder containing the solution. If the folder name contains a space, then the file names will contain a space, and SharePoint seems to not like this.

It seems pretty unnecessary to have the file names contain the solution's folder name, and I'm wondering if this is a bug in the gulp bundle procedure. It may be possible to remedy this by modifying said procedure, but being fairly unfamiliar with gulp, I wouldn't know how to go about that.

[Dangerous-Mind]

Solved removing the space on the name of the folder were the solution was stored and on one of the files.

[rajamaniperumal]

What helped me was cleaning temp/deploy folder

Thanks, you have saved my time....

[kylepdx]

Wicked error message...not helpful. In my case I had an asset (image file) that had a space in the filename. Once I renamed the file and did a clean, I was able to package and deploy again.

[ravinleague]

Had to -
Rename project folder (it had spaces)
Check for dashes in the solution names_(removed, just in case)_
Delete temp/deploy folder
Gulp bundle --ship
Gulp Package-solution --ship

Working fine!!

[andrewconnell]

Seems like things are resolved by cleaning & rebuilding the project?

[jonathaneckman]

The solutions above helped me.

1. Remove spaces from the path.
2. Clean
3. Rebuild and package.

In my case, I found a space in a parent directory my source code was under.

[msft-github-bot]

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within next 7 days of this comment. Thank you for your contributions to SharePoint Developer activities.

[joaoferreira]

This still happens, I did a test today and got the same error.
The workaround provided in this thread helped me to get it working

• Rename project folder (it had spaces)
• Check for dashes in the solution names_(removed, just in case)_
• Delete temp/deploy folder
• Gulp bundle --ship
• Gulp Package-solution --ship

[andrewconnell]

@joaoferreira I just created 2 new projects and tested the deployment on each:

• project folder with no spaces/hyphens, project name with hyphen = pass
• project folder with no spaces/hyphens, project name with space = fail

So the original reason for the issue, hyphens in the project name, is no longer a problem. However, spaces are a problem. With that being said... it's not really a bug as things are working as expected, but a feature enhancement for the generator could be to not allow spaces for the project name. In that case, it should be submitted as a feature request via UserVoice @ https://aka.ms/sp-dev-uservoice.

Therefore, I'm going to close this issue since the root reason for the issue is no longer applicable.

[JLRishe]

@andrewconnell _it's not really a bug as things are working as expected_ ... Having certain circumstances where the build process produces packages that are unusable and provide no indication of what's wrong is "working as expected"? Is this documented somewhere outside of this Github issue?

This seems to be the kind of thing that should be caught in the build process (or the build process should be improved to not cause this issue, since it seems like there's not really any good reason why it's happening), not in the generator.

[andrewconnell]

Honestly, I'm not sure @JLRishe (if it is/isn't documented somewhere).

Maybe you could call it a bug & I'm wrong... I'll flag it for engineering to decide if it is / isn't a bug and see if they won't comment here.

I do agree... it would be nice if the generator flagged it as an issue at project creation, I'm just not sure if that would be considered a "nice" feature to have, or if that's a "bug". I can't be the judge in that...

[DonKirkham]

I also ran into this and it was a space in an image file that caused the issue.

I also think the package-solution should have a warning, or better yet, nip it in the bud at build if we know it will be a problem downstream.

@andrewconnell , this would certainly be a great tip for your courses. "NO SPACES IN SPFX!"

[smit1529]

Hey Guys,

What helped me to resolve the issue is....
Eliminating/Removing the "clientsideinstance.xml" attribute from "package-solution.json" file.
Please check the below screenshot for the same.

Mark as answer if you find it useful.
Thanks.