Missing documentation regarding On-Premise SP2016

[psylion]

Category

• Question
• Typo
• Bug
• Additional article idea

There is a demand to build solution based on SPFx onPrem.
We are focussing on 2016 but in the near future will go to 2019.

Expected or Desired Behavior

I was not able to find a proper documentation/artcile to create a proper sp2016 on-prem solution.
Apparently there is so many limitation in the versions of Node / SPFx / etc... That I suggest to have a dedicated article point to proper steps.

Observed Behavior

After 3 days of testing many differents solution packaging i still cannot load a proper sppkg on my App Catalog... with the simple hello world in SPFx v1.7.0 using node v8.15.1.
It will be also usefull to provide tips and tricks regarding the simple gulp serve issue on NODE_NO_HTTP2...

[msft-github-bot]

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

[nanddeepn]

Hi @psylion ,
Here is a good documentation https://docs.microsoft.com/en-us/sharepoint/dev/spfx/sharepoint-2016-support

[Dennis-LZ]

@psylion , you can check the article here: SharePoint-2016-support.md

and SharePoint Framework - SPFx Development With SharePoint 2016

[psylion]

@nanddeepn , @Dennis-LZ , thanks for the links, I already look at those content.
Looking also across issues in git, I saw comment regarding now we should use SPFx 1.7.0 for on premise. Definitely, we should have a link pointing to LATEST compliant versions for OnPrem.
The first link video content dated Sept 2017 (2years ago) and use SPFx 1.0.2
The second link provide steps from December 2018 (10months old) and does not specify any versions.
As soon as I moved on, I have make big steps forwards this morning:

• after checking App catalog / auth. provider. / etc...
• I finally be able to upload valid sppkg onPrem
  Now i'm confused:
  for onPrem spppkg creation, can we have a requirement list of versions for:
• Node
• @microsoft/generator-sharepoint
  Cuurently using Node v8.15.1 and the following details from my .yo-rc.json...
  "@microsoft/generator-sharepoint": {
  "isCreatingSolution": true,
  "environment": "onprem",
  "version": "1.7.0",
  "libraryName": "default-mg-s",
  "libraryId": "db31f07a-1026-4e69-b837-984ad66a8bf0",
  "packageManager": "npm",
  "componentType": "webpart"

When doing simply :
gulp bundle -- ship and gulp package-solution --ship
I got the following error when WebPart are adde into a page:
***ERROR MESSAGE:
***Failed to load component "a14df85e-8dbf-45fc-9c92-8c911283398a" (HelloWorldWebPart).
Original error: ***Failed to load path dependency "a14df85e-8dbf-45fc-9c92-8c911283398a" from component "HelloWorldWebPart" (Error loading https://component-id.invalid/a14df85e-8dbf-45fc-9c92-8c911283398a_0.0.1/HelloWorldWebPartStrings
Unable to load script /defaultmgs-helloworldwebpartstrings_en-us_536e65149b0acf4d52c0043073b9fc59.js).
Original error: {3}

Certainly I need to change somethings like the manifest or other config file...

[andrewconnell]

Please see the docs on setting up your dev environment: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/set-up-your-development-environment

If you're on SP2016, you must have SP 2016 Feature Pack 2 installed as that includes SPFx.

You should install the latest Yeoman generator for SharePoint (currently, v1.9.1). When you create a project, it will prompt you for the environment you are targetting. You'll pick SP 2016. The project created will use the version of SPFx that your env. supports (SPFx v1.0.1).

There is a note on the above-mentioned about troubleshooting... it addresses your question on HTTP2 & HTTPS.

First, verify your project works in the local workbench (run gulp serve). If that works, then code/project part works.

If after deploying you're having trouble, it's likely an issue with the SP 2016 installation & configuration to support hosting apps.

[psylion]

@andrewconnell thanks for your input, this was helping me understanding the situation of latest version.
I have now the Node v1.16.3 and I used the @microsoft/generator-sharepoint version 1.9.1
My .yo-rc.json confirm I got the onprem env.
I set the HTTP2=1 and
The gulp serve is running perfectely but I had to modify the serve.json like this:
"https": false,
"initialPage": "http://localhost:5432/workbench",
Now I can run local workbench no issues

But still when gulp bundle --ship and gulp package-solution --ship created the package
and loaded into my app catalog (Valid app package = Yes)
I can add the app on the site after having add into the central admin.
The app is available on the site
I can add the webpart to a page
And then the issue
How to configure the solution package to not use CDN and just the local sharepoint where the package is deployed?

[andrewconnell]

@psylion said:

I have now the Node v1.16.3

Assume you mean Node.js v10.16.3? If you are running Node

@psylion said:

The gulp serve is running perfectly but I had to modify the serve.json like this:
"https": false,
"initialPage": "http://localhost:5432/workbench",
Now I can run local workbench no issues

You should not have to do this... it doesn't sound like you have trusted the dev cert which was a step in the link I shared above.

@psylion said:

But still when gulp bundle --ship and gulp package-solution --ship created the package and loaded into my app catalog (Valid app package = Yes)
I can add the app on the site after having add into the central admin.
The app is available on the site
I can add the webpart to a page
And then the issue

What "issue"... the one about loading the component? If so, did you deploy the JavaScript bundle & manifest to a public location & configure the project to pull from that location? This page in the docs explains deploying to an Azure CDN, but you don't have to use Azure. It just has to be a public location that people can pull the files from when they load the web part in the page. You will need to configure your project so SharePoint knows where to pull the files from as outlined in this section of the same doc.

@psylion said:

How to configure the solution package to not use CDN and just the local sharepoint where the package is deployed?

Not possible... you said you were on SharePoint 2016. You don't have the option to deploy the assets (JS bundle & manifest) with the SharePoint package. that was added to SPFx v1.4.1 and only available in SharePoint Online.

Your only deployment option is the two-step option:

1. upload & deploy the *.sppkg to an app catalog, then install in a site
2. deploy the assets needed for the component to run (minimum, the JS bundle & manifest JSON files.

For the deployment of the assets, they can go anywhere as long as the users of the web part have permissions to pull from that location. They can be in an Azure CDN, AWS CDN, GCP CDN, public file share, SharePoint doc library... it doesn't matter. Just has to be HTTPS accessible by everyone using the page.

[psylion]

Diging into other forums I found a description on how to physically modify the write-manifest.json to enter cdnBasePath a path pointing to the local SiteAssets where I copied the content of temp\deply folder 1 json and 2 js.
I allowed the JSON extension onto the web applications and then after recreating my package I've been able to make it working.

Are these steps mandatory?
The gulp bundle and pakage-solution does not integrate the json and js files?
Can you point me where this is documented?

[psylion]

@andrewconnell I think you just reply to my questions in the same time i wrote my last comment.
Now its start to be clear and under control.

the only remaining issue is the change of the serve.json... I'm running on Win10 and https was not working
even I followed another thread saying I need to delete the "homeuser"/.gcb-serve-data and recreate the gulp trust-dev-cert
Which I did and I had the Popup to approve ther usage of the certificat, but still not able to run in default mode with https true on port 4321

[andrewconnell]

@psylion there are numerous issues, both open & closed, related to HTTPS & the local workbench in this issue list. Please review those and comment back on all the things you've tried. This is not an uncommon issue & entirely dependent on your machine. Usually on Windows it's resolved by untrusting the cert, then re-running the trust-dev-cert task from an administrative command prompt.

Regardless, these are two different issues and you should open a different issue related to that.

[psylion]

Ok thank you
The initial issue is solved, I'll keep an eye on the #2343

[andrewconnell]

I wouldn't watch a closed issue like the one you reference... once an issue is closed, it's considered "done"... closed issues don't get much if any attention.

In fact, me responding to this issue, now closed, is quite out of the norm :)

[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