この記事では、開発環境にて SharePoint Framework で作成した Web パーツを本番環境にデプロイするための手順を説明します。 まだ SharePoint Framework で Web パーツを作成していない場合やビルドしていない場合は、以下の記事を参考に Web パーツを作ってください。
本番環境にデプロイするためには、SharePoint Framework で作成した Web パーツをデプロイするためのパッケージにまとめる必要があります。 パッケージファイルは、.sppkg というファイル拡張子の zip ファイルで、これを本番環境にデプロイすることになります。 ということで、まずはパッケージを作成する手順からです。
SharePoint Framework で開発したアプリをテナント内で利用するためには、「アプリカタログ」と呼ばれる場所にアプリのパッケージファイルをアップロードする必要があります。 この記事では、この「アプリカタログ」を作成するための手順を紹介します。
テナント全体で使用するアプリを登録するためのアプリカタログです。 テナントアプリカタログに登録されたアプリは、テナント内のすべてのサイトコレクションに展開可能となり、特定のサイトコレクションに限定して展開することはできません。
サイトコレクションごとの個別のアプリカタログです。 サイトコレクション管理者は自身が管理するサイトコレクションにのみアプリを展開することができます。
テナントアプリカタログは Microsoft 365 管理センターから作成します。
① Microsoft 365 管理センターにアクセスし、SharePoint 管理センターを開く。
② メニューから [その他の機能] をクリック、右ペインの [アプリ] の下の [開く] をクリックする。
③ [アプリ カタログ] をクリックする。
④ [新しいアプリ カタログ サイトを作成する] をクリックする。
⑤ アプリカタログを作成する。
必要事項を入力し、[OK] ボタンをクリックすると、アプリカタログのサイトコレクションが作成されます。
⑥ アプリカタログを開く。
アプリカタログはサイトコレクションなので、⑤で決めた URL にアクセスすると通常のサイトと同様に開くことができます。
最終更新日：2020/07/26
SharePoint Framework 開発中、gulp serve でエラーが発生することがありますが、実際に発生したエラーと対処法をこの記事にまとめていきたいと思います。
**■エラーメッセージ（下線箇所は状況により異なります）**Error - Unknown EPERM: operation not permitted, chmod ‘/usr/app/spfx/dist/link-list-web-part-web-part.js’ ■対処法/usr/app/spfx/dist フォルダにあるファイルへのアクセスができないために発生しているものと思われます。 プロジェクト作業フォルダ内の dist フォルダを削除して再度 gulp serve を実施してください。
2020年7月17日に SharePoint Framework v1.11 がリリースされました。 この記事では v1.11 の変更点について気になるところだけ抜粋して記載します。 詳細は以下のリリースノートを確認してください。 SharePoint Framework v1.11 release notes なお、SharePoint Framework v1.11 に対応した Docker イメージは Docker Hub からダウンロード可能です。
2020年5月28日～29日に、世界規模で開催された Microsoft 365 Virtual Marathon というオンラインイベントにスピーカーとして参加させていただきました。 私はこれが初めてのオンラインイベントでの登壇で、リハーサルの時から機材大丈夫かなとか、おでこテカってないかなとか、背面大丈夫かなとか、色々考えて無駄に緊張してしまいましたｗ これから YouTube で動画が公開される予定ですが現時点では自分の喋りっぷりは確認できておらず、これまた大丈夫かなと不安な点はあるのですが、ひとまずいつも通りの感じでできたかなと思っています。 ちなみに今回私のセッションをご視聴いただいた方の人数は180名弱くらいだったようです。 ご視聴いただいた多くの方々、本イベントの主催者やスタッフの方々、この度はとても良い機会をご提供いただき誠にありがとうございました。 またオンラインイベントやっていきたいですね。
通常コミュニティイベントというと、休日にどこかの場所に集まってみんなで和気あいあいと楽しく勉強をするという感じで、それはそれでとても楽しいのですが、休日に家を空けるというのはなかなか大変なことで、これまであまりコミュニティイベントに参加できていませんでした。 でも、今回オンラインイベントを経験してみて、これはこれでオフラインのコミュニティイベントと同様にやりがいがあるし、何より参加いただける方が桁違いに多い！ だから、今までアプローチできなかった方々にも視聴いただくことができるようになったし、それによって生まれた新たなコミュニケーションもありました。 オンラインならではのこの経験はなかなか興味深いもので、これからのイベントの在り方を見直す良い機会なのかなと思いました。 さて、今回のイベントの詳細につきましては、日本チームのリーダーである平野愛さんが既にまとめ記事を投稿されているので、詳細はそちらをご覧ください。 Microsoft 365 Virtual Marathon 無事に終了しました
SharePoint の REST API をテストする時、みなさんはどんなツールを使っていますか？ 私はこれまで Internet Explorer のフィードを表示する機能を使っていたのですが、IE の未来に光が見えないので他のツールに乗り換えようと色々探していました。 IE と同じように、ブラウザで SharePoint サイト認証をクリアしていればその認証情報を使いまわしてくれるものが使い勝手が良くていいなと。 そしてようやくニーズにあったツールに出会えたので紹介します。 その名も「SP REST Client」 Google の拡張機能として提供されています。 ひと目で SharePoint 用だと想像がつく分かりやすい名前ですね。
別記事で SharePoint アドインが SharePoint Online でも使えることを記載しましたが、そうやって開発したクライアント Web パーツをモダンページに配置するとどうなるのか確認してみました。 SharePoint アドインのクライアント Web パーツはモダンページが登場する前からあった技術なので、レスポンシブが前提のモダンページにうまくはまってくれるのか、そこが最も気になっていた部分です。 参考： SharePoint Online で SharePoint アドイン（プロバイダーホスト型）を使用する
クライアント Web パーツというのは、SharePoint アドインを開発する際に SharePoint アドイン本体の Web アプリケーション部分を SharePoint のページ上に表示するために使用する Web パーツで、SharePoint ページ上では HTML の iFrame としてレンダリングされます。 iFrame の中に、Web アプリケーション部分が表示されることになります。
SharePoint Server 2013 で導入された SharePoint に機能を追加する仕組みとして、プロバイダーホスト型の高信頼性 SharePoint アドイン（以降「SharePoint アドイン」と表記）というものがあります。 SharePoint アドインは、もともと SharePoint アプリと呼ばれていたので、SharePoint アプリとして覚えている方もいらっしゃるかもしれません。 この SharePoint アドインですが、少々レガシーな仕組みかもしれませんが、SharePoint Online でもきちんと動作することが確認できました。 ただし、オンプレ環境で動作させる場合と展開する方法が少々異なるので、展開の仕方をまとめました。
SharePoint Framework v1.10 で実装されたライブラリの変更通知を受信する機能を試してみました。
指定したライブラリでファイルが登録、更新、削除された際に、その変更通知を受け取ることができるようになる機能です。 SharePoint Framework で開発する Web パーツやアプリケーションカスタマイザーで変更通知を受け取ることができます。 なお、SharePoint Framework v1.10 では、ドキュメントライブラリ系（ドキュメント、サイトのページ、メディアなど）の変更通知のみ対応しており、リストの変更通知を受信することはできません。 また、変更通知として受け取れる情報は、ライブラリが変更されたという情報だけで、何が変更されたのかといった情報はセキュリティ観点から取得することができなくなっています。 なので、必要に応じて変更通知の受信をトリガーに REST や spHttpClient でアイテムを取りに行く処理を実装する必要があります。 変更通知受信機能の詳細は、Docs を参照してください。
SharePoint Framework v1.10 で実装されたプレースホルダーの事前領域確保の効果を確認してみました。
SharePoint Framework 拡張機能であるアプリケーションカスタマイザーのページプレースホルダーを使用することで、すべてのモダンページに共通のヘッダーとフッターを追加することができます。 ですが、ページプレースホルダーはモダンページのレンダリングの順序において比較的遅めにレンダリングされるため、SharePoint 標準のヘッダーとコンテンツの領域が表示された後に、SharePoint 標準ヘッダーの下にページプレースホルダーによるヘッダーが挿入される動きが目で見て分かってしまいます。 SharePoint Framework v1.10 では、このちょっとカッコ悪い動きを改善するため、ページプレースホルダーの事前領域確保の設定ができるようになりました。 ページプレースホルダーの詳細は、Docs を参照してください。
事前領域確保の有無の違いが分かるように両方で動画を撮ってコマ送りにして比べてみました。
SharePoint 標準のヘッダーの下に青色のブロックがありますが、こちらがページプレースホルダーのヘッダーの部分、下部の灰色のブロックがフッターの部分になります。
上の動画が事前領域確保無し、下の動画が事前領域確保有りです。
事前領域確保無し
事前領域確保有り
比べてみると効果は一目瞭然。
事前領域確保無しの方は、ページのタイトル部分がヘッダーの表示のタイミングで下にずれ込むのが分かります。
動画をコマ送りで見ると、ページプレースホルダーの事前領域確保をした場合、下図の通りブランクの領域（横線が入った部分）がページプレースホルダーの表示領域としてあらかじめ確保される動きになっていました。
