Sp-dev-docs: Command Set Customizer: Debugging doesn't work for Targeted Release tenants

[AJIXuMuK]

Category

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

Expected or Desired Behavior

Command Set Customizer can be debugged with gulp serve --nobrowser and debug query string parameters

Observed Behavior

Debugging works for Standard Release, but not for Targeted (First) release

Steps to Reproduce

1. Create Command Set Customizer extension using Yeoman generator
2. gulp serve
3. Copy the query string parameters
4. Open any list view page on Targeted Release tenant and paste query string params
5. Allow loading on debug scripts
6. Command bar buttons don't appear

Tested on 2 Targeted Release tenants

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[PopWarner]

@AJIXuMuK, I know there has been a few issues logged recently around this. Curious, if you do a bundle and package-solution, NOT using --ship, so it still uses your gulp serve...throw that up in a site collection or tenant app catalog, does it work? :)

[AJIXuMuK]

@PopWarner, yes it works.
But sometimes we don't have access to App Catalog to install the .sppkg.
So it still an issue to be fixed :)

[PopWarner]

@AJIXuMuK I gotcha and with ya! :) I was mainly just curious if you had the same experience I was once you deployed a non "--ship" version of it. 👍

[EranHertz]

Same happens to me (targeted release) with a fresh Yeoman install. There are no errors and it loads the local files, yet the buttons are missing.

[patmill]

This has been fixed and should be rolling out shortly I believe. Adding @ahackettms for confirmation.

[andrewconnell]

This workaround may help: https://github.com/SharePoint/sp-dev-docs/issues/4374#issuecomment-516815819.

Appears a regression was introduced at some point that caused the wrong URL to be generated by gulp serve which isn't telling SPO to load SPFx onto the page if it isn't already there.

Hey OP @AJIXuMuK, please try this and report back if it resolves your issue.

[AJIXuMuK]

Hey @andrewconnell ,
Yep, the workaround works!

I believe it still should be fixed but not a blocker for sure.

[andrewconnell]

@AJIXuMuK strictly a workaround, not a solution. They'll get it fixed... hopefully in 1.9.1

[patmill]

In this instance, it won't need a fix to any generator / npm package. Rather it will be an update to the list app that is shipped directly to the service. The ideal solution will be a case-insensitive comparison of the query string, so the workaround will continue to work, but the actual string generated by the tools will also work.

[andrewconnell]

Can you take a look and see if this is resolved? A fix for this has been rolling out and is likely to be deployed WW by now...

[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.

[AJIXuMuK]

Sorry, my bad!
Yep, it’s working!

Thanks @andrewconnel for the update!

[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