Sp-dev-docs: Cannot deploy packages anymore

[RobinBreman]

Category

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

Cannot deploy a previously good package anymore, this now results in a strange app catalog behavior.

Observed Behavior

Grabbed a previously good package from an earlier build, deployed this package to the app catalog.
Also tried deploying this package to a fresh (first release enabled) tenant (same problem).

• The Title and ProductId are missing, and the version is incorrectly shown.
• There is no deployment error logged.

• App details screen is showing: 'Invalid SharePoint App Product ID:'

[RobinBreman]

Update

By dismantling our project and keep digging down I found the cause of this one.

My webApiPermissionRequests object has grown in time, this is causing the issue.

When the (formatted) _string_-length of the webApiPermissionRequests object exceeds 255 chars the solution will not deploy. There is no error shown in the appcatalog only an invalid app is listed. The 'trust solution' dialog is never shown.

The appcatalog library's WebApiPermissionScopes field is the root cause. I found that on uploading the webApiPermissionRequests are stored into the hidden WebApiPermissionScopes field. This field cannot exceed 255 chars!
Values are stored in the: resource, scope; resource,scope ... format.

You can check the length:

let package = {}; //paste package-solution.json here

package.solution.webApiPermissionRequests.map(function (elem) {
    return elem.resource + ', ' + elem.scope;
}).join("; ").length

If this check exceeds 255 chars you will not be able to correctly upload a new app-package.

Make sure to delete an earlier version of the app-package from the app catalog to experience this behavior.
(If you do _update_ the app you will notice the version and other properties do not change but the 'trust solution' dialog does popup).

[RobinBreman]

Dear @VesaJuvonen has the app catalog deployment changed since v 1.6 ?

[PzYon]

Please also see #2642, it's going in the same direction. However for us it stopped working, without any changes in the app/manifest. From my understanding SP must have changed something on their side, but not together with the release of 1.6, but only in the last couple of days. Either some permission ResourceIds are suddenly not supported anymore or the handling of invalid permission requests has been changed.

[martinvillysson]

I'm also seeing the same problem when trying to upload the starter kit https://github.com/SharePoint/sp-starter-kit

[justdevelopment]

Looking at the code for the starter-kit it's also because the combined scopes string is too long.

Our current workaround is using multiple solutions which set scopes (so each one will stay below the 255 limit, as checked by @RobinBreman 's script). You can then deploy and approve all of them, the main solution which actually uses the scopes will work correctly after.

@PzYon as far as we can tell there is no check on the scopes/resources requested. You can add what ever you want and as long as you stay below the 255 limit it'll be accepted.

[PzYon]

@justdevelopment yes, you are right. I just tested with the permission scopes I mentioned in the other issue and it works - if there aren't too many of them... ;) In other words, I'll close #2642.

Is there any news from Microsoft on why they introduced a character limit? And how to solve this? Creating multiple apps just to request new permissions doesn't feel right...

[PzYon]

@VesaJuvonen, @patmill Do have an answer for this? I.e.:

• Will this be fixed? If yes, is there a timeline?
• Or do we really need to create multiple apps, just to register permissions?
• Or is there another way to workaround this issue?

My standpoint is clear: We have an app retrieving data from Graph, SP as well as custom APIs, so we hit the 255 character limitation pretty fast. From a developer as well as from a customer perspective, it doesn't make sense to create and maintain "dummy" applications just to be able to register permissions.

[VesaJuvonen]

We are aware of this and are working on a resolution, which is actually slightly more complex than it seems. For now - workaround is to request permissions with multiple packages, which is not optimal, but does work for now until a more long-term solution is available.

[MatthiasWeibel]

@VesaJuvonen, @patmill Any updates on this?

[patmill]

Sorry - yes. This has been fixed.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues