ApplicationCustomizer extension not loading in one tenant

[tarjeieo]

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

I have one tenant where Application extensions does not work. I am able to upload the packages to the app catalog, the apps are visible in sites, the apps can be added to sites, but nothing is loaded on any page in the sites I add the app to.

NOTE; It looks like this happens in a single tenant only. It's a customer tenant that has been around for a few years (not that it matters I guess?). I know the previous SharePoint admin was quite conservative, and may have restricted a lot of features, fwiw. The same pacakge works in another tenant.

I have also logged this as a service request in the affected tenant, ticket 7473725. If you need tenant name or additional info, feel free to shoot me an e-mail at tarjeieo (at) puzzlepart.com.

Observed Behavior

After the app is added, nothing happens. Nothing is loaded, and there are no errors in the console log.

Steps to Reproduce

I use the latest version of yeoman, npm and sp-generator. I created a new @microsoft/sharepoint project, changed nothing, but still I am not able to get the alert to be invoked in the sites I'm adding the app to.

I've also shared the package; https://www.dropbox.com/s/999c4n67k5nq0g1/blank-extension.sppkg?dl=0.

package.json

{
  "name": "blank-extension",
  "version": "0.0.1",
  "private": true,
  "engines": {
    "node": ">=0.10.0"
  },
  "scripts": {
    "build": "gulp bundle",
    "clean": "gulp clean",
    "test": "gulp test"
  },
  "dependencies": {
    "@microsoft/sp-core-library": "~1.4.1",
    "@microsoft/decorators": "~1.4.1",
    "@types/webpack-env": ">=1.12.1 <1.14.0",
    "@microsoft/sp-dialog": "~1.4.1",
    "@microsoft/sp-application-base": "~1.4.1"
  },
  "devDependencies": {
    "@microsoft/sp-build-web": "~1.4.1",
    "@microsoft/sp-module-interfaces": "~1.4.1",
    "@microsoft/sp-webpart-workbench": "~1.4.1",
    "gulp": "~3.9.1",
    "@types/chai": ">=3.4.34 <3.6.0",
    "@types/mocha": ">=2.2.33 <2.6.0",
    "ajv": "~5.2.2"
  }
}

package-solution.json

{
  "$schema": "https://dev.office.com/json-schemas/spfx-build/package-solution.schema.json",
  "solution": {
    "name": "blank-extension-client-side-solution",
    "id": "ad070b4d-30f5-470a-bf13-946b84710e43",
    "version": "1.0.0.0",
    "includeClientSideAssets": true,
    "features": [
      {
        "title": "Application Extension - Deployment of custom action.",
        "description": "Deploys a custom action with ClientSideComponentId association",
        "id": "1b1c0dea-d7b6-4e75-a2b5-6b6d46ed1449",
        "version": "1.0.0.0",
        "assets": {
          "elementManifests": [
            "elements.xml"
          ]
        }
      }
    ]
  },
  "paths": {
    "zippedPackage": "solution/blank-extension.sppkg"
  }
}

[wictorwilen]

I have the exact same issue in a tenant, both for existing solutions and also using the solution uploaded in the original issue!

This is a breaking issue for clients!

[maliksahil]

Are you using chrome 64 by any chance? Can you check the console for any errors? Also does it load if you run chrome in private mode?

[wictorwilen]

No errors in the console. And you can see in the HTML source that the extension is registered, but it never loads or tries to load the accompanying JavaScript file.
And yes, 64 bit Chrome

[VesaJuvonen]

Would appreciate direct emails with tenant names where this happens vs. where it does not happen, so that we can isolate the issue. You can send a message using whatever channel towards me. Email also works and address is pretty logical based on my name. Thx - this helps on narrowing the issue down.

[wictorwilen]

@VesaJuvonen - you got mail

[wictorwilen]

It's working for me now. The culprit was related to #503. In 1.4.1 we do no longer get an error when building/packaging with relative JSOM URLs and it deploys fine to SPO. But the extension fails to load without any warnings or errors. Changing back to absolute URLs for the JSOM URLs it works again.

[VesaJuvonen]

hi @tarjeieo - any changes on the status from your side? - We can't get this repro'd in our side so will ping you offline for seeing suitable time for a online sync.

[tarjeieo]

I decided to do some more testing tonight, and I have an additional discovery. SPFX web parts are not working in the tenant either. I created a new “Hello World” spfx web part with yeoman, changed nothing, bundled and packaged solution, and uploaded the app.

I'm able to upload it to the app catalog, add the app to sites, but don't see my web part in the web part picker for pages. I've verified the same package works in another tenant.

Any global settings or anything like that I can look for?

[tarjeieo]

Got a tip from @wobba to check CDN settings, as commented about in #775. I added /CLIENTSIDEASSETS (Add-SPOTenantCdnOrigin -CdnType Public -OriginUrl "/CLIENTSIDEASSETS"), gave it 30 minutes, and now it’s working. Both web part and extensions are working in the tenant again.

My understanding was using CDN was not mandatory when working with SPFX - is that wrong? From e.g. https://docs.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/get-started/hosting-webpart-from-office-365-cdn.

Note

Starting from the SharePoint Framework v1.4, static assets are by default packaged inside of the sppkg package. When a package is deployed in the app catalog, they are automatically hosted either from Office 365 CDN (if enabled) or from an app catalog URL. You can control this behavior with the includeClientSideAssets setting in the package-solution.json file.

Appreciating clarifications around this (and I'm really sorry if this is an obvious error on my part!)

[wobba]

So seems if CDN is enabled, but not for the cliensideassets folder, then this issue happens. Ideally it should then be served from the App catalog site I guess, same as if CDN is disabled.

[maliksahil]

If you use automatic asset deployments it comes from /clientsideassets in the app catalog .. both site and tenant. Just hit f12 and see where the files are coming from, you’ll see what I mean :)

TLDR, after you enable the public cdn, don’t remove the */CLIENTSIDEASSETS origin (present by default)

[wobba]

Indeed :) But would be great if SPFX checked that the origin was there. At least we know how to troubleshoot and fix, and FAQ will be updated for this.

[maliksahil]

Yeah I agree. Ideally during deploy, it should do this sanity check. Or perhaps it shouldn’t be possible to disable those origins. Dear @VesaJuvonen ..

[tarjeieo]

Yeah, so I'm interested to know whether

1. CLIENTSIDEASSETS was removed by someone, or
2. Never present in this tenant, since we enabled CDN before it was one of the default items (might even have been when CDN was in preview)

I did see that even if the CDN was enabled, all the origins were removed when I took a look there.

[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