サーバー移行が終わったのか、終わってないのかよくわからない(IPアドレスは変わった気がするけど、PHPのバージョンが上がっていない?)ので、ブログに凝った記事などを残すと痛い目を見そうなので、軽い備忘録を残しておく。

 

 .NET Framework、.NET Core、.NET 5と実行環境が色々混在する過渡期の今「プロジェクトのC#のバージョンは何だっけ?」となることも多いと思うので確認する方法。

 

#error version

 

 と記述するとプログラムはエラーになるけど、エラーメッセージでコンパイラのバージョンと言語バージョンが確認できる。

 たまに確認したくなるんですよね。

 

 追伸:Unityで試してみたらlatestと表示されて確認できないケースがあることを知った・・・latest指定でもその最新バージョンを表示すると思い込んでいました。

 

 ちなみに普段使うことはあまりないと思うけど、バージョンを指定したい場合は.csprojに以下のようなタグを記述。どの辺に挿入するかなど仔細は省略。

 

    <LangVersion>5.0</LangVersion>

 

 


 このブログはhetemlというレンタルサーバー上で動いている。

 もともとFlash Media Serverが遊べるレンタルサーバーとして選択したのだが、現在はFlash Media Serverの機能は無くなり、お値段据え置きという微妙なコスパになっている。

 

 このhetemlが2020年から2021年にかけて、古いサーバーを強制的に新しいサーバーに移行させることになった。

 PHPのバージョンは上がるし、古いサーバーだとセキュリティ上の問題もあるだろう、サーバーのスペックもたぶん上がるからメリットも大きいが、強制的に移行というのは中々にリスキーな気もする。

 

 移行用のドキュメントを見た感じ、

 

・DBはそのまま

・ファイルはコピー

・DNSはムームーなら自動で変わるよ

・動作確認はhostsを変えてみてね

 

 という感じだ。現状、アクティブなのはWordPressで動いているブログぐらいなので、放置していても問題なく移行が終わる気もする。

 むしろトラブった際の訓練用に半分放置しておこうと思う。

 

 というわけで、対応は以下のようにする予定。

 

・WordPressのuploadsフォルダーだけバックアップ

・DBは触らないみたいなので信じてノータッチ

・DNSはムームーなので自動で変わるのだろう

・hosts書き換えて一応見てみる

・あとはトラブったらその時対応。復旧不能でも、まぁ、いいや。

 

 というわけで、FTP(厳密にはSFTP)でuploadsフォルダーだけバックアップしておいた。

 あとは移行時にトラブルがあったらその備忘録を残そう。

 

追記:

 2020年11月5日現在の状態を確認してみたら、新サーバーで10月12日以降にアップロードした画像が404になっていました。

 旧サーバーから新サーバーへのファイルのバックアップは10月12日に取られて終わりってことかもしれません。DBは変わらないので記事がなくなることはないでしょうが、この辺をあまり考えずに旧サーバーにメディアファイルをアップロードしていると移行時に苦労するかもしれません。移行完了してもしばらくは旧サーバーからファイルを落とせるなら良いのですが、もし旧サーバーにアクセスできなくなってしまうと、復旧が面倒そう。

 

 hostsを新サーバーに設定しても「PHPのバージョンが古い」という警告がWordPress側で消えないので、何か理解できてないポイントがある気もするけど、前にも書いたとおり、トラブルになったら対応方針で様子見。

 


 「へぇ、Power Shellで操作できるんだ」と公式のドキュメントを見て、試しにやってみたら躓いてしまいました。

 公式に以下のようなクイックスタートがあるので、これをそのまま実行すればOKだろう。と軽い気持ちでしたが、

 

Quickstart: Create an Azure Cognitive Search index in PowerShell using REST APIs

 

 インデックスを作成する段で、

 

No HTTP resource was found that matches the request URI・・・

 

 というエラーが出てしまった。

 この際に実行したURIが以下、

 

https://<サーチサービス名>.search.windows.net/indexes/customer-index?api-version=2020-06-30

 

 公式のクイックスタートを多少変えてあるが、ほぼ同じ。

 前にもこんなことあったような・・・という朧気な記憶から動作したURIは以下。

 

https://<サーチサービス名>.search.windows.net/indexes?api-version=2020-06-30&$select=name

 

 URIからインデックス名がなくなっているが、事前に定義しているインデックスの情報にインデックス名も指定しているので問題なく作成されました。

 先のURLでどうしてダメだったのかの細かい検証はしません。あくまで備忘録ということで。

 


 2020年9月度の.NETラボ勉強会で「Microsoft Teamsカスタマイズ入門」というタイトルでお話させていただきました。

 1番苦労した点は、Teamsで配信しつつ、Teamsの画面を説明した点です。誤ってTeamsクライアントを閉じてしまうと、配信が終わってしまうので気が抜けない戦いでした。

 

 スライドの最後にも書きましたが、LinkedInラーニングでTeamsアプリケーション開発のコースを公開予定(未定)なので、もう少し知りたいと思っていただけたなら、LinkedInラーニングのコースも視聴してみてください。 

 

Microsoft Teams Custom from Makoto Nishimura

 ASP.NET MVCのサンプルプロジェクトをDLしてきて実行してみたら、タイトルのようなエラーで起動しない。

 

・・・bin\roslyn\csc.exe’ パスの一部が見つかりませんでした

 

 roslyn? 言っていることはわかるような気がするが、なんでそんなもののパスがプロジェクト内にあると思った?

 こういうときはネット便りで・・・検索するとパッケージをアップデートすれば解決するらしい。

 

update-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

 

 上記で良いみたいだが、とりあえずパッケージを全部更新してみたら解決。


 Microsoft Teamsのタブ機能はiframeでWebサイトを表示することで実装します。

 Teamsクライアントから情報を取得する場合 Teams JavaScript client SDKなどを利用してJavaScriptで書くわけで、ブラウザみたいな開発者ツール(F12で起動するアレ)があると便利。

 

 TeamsにもDevTools for Microsoft Teams tabsというのが存在し、これを利用するとJavaScriptのデバッグが楽になります。

 まんまF12で起動するアレですね。

 

開発者向けプレビューを有効にする

 

 現時点(2020年8月25日)では、Teamsの開発者向けプレビューを有効にしないとDevToolsは利用できません。

 開発者向けプレビューはクライアントアプリ毎に有効無効を変更します。

(事前にMicrosoft 365管理センターから、アプリケーションのサイドローディングを許可している必要があるかもしれません)

 

 Teamsクライアントの右上のアイコンから・・・

 「情報」→「開発者プレビュー」をクリックします。

 「開発者プレビュー版への切り替え」をクリックすることで開発者プレビューに変更することができます。

 この際にTeamsクライアントが再起動し、再ログインが必要になります。

 

DevToolsの起動

 

 DevToolsの起動はタスクトレイから行います。

 デバッグしたいタブを開いた状態で、タスクトレイのTeamsアイコンを右クリック→「DevToolsを開く」で起動することができます。

 うん、便利。

 

 


 Microsoft Teamsのカスタマイズアプリケーションを作成する方法の1つにタブがある。

 Microsoft Teamsに個人用またはチーム、チャネルにタブとしてWebページを表示する仕組みです。

 個人用とそれ以外の違いはまたの機会に紹介するとして、まずはサンプルを元に個人タブの動作を確認してみる。

 

Toolkitの導入

 

 Visual Studio∔C#で開発する場合は「Microsoft Teams Toolkit for Visual Studio」を入れておくと、ある程度ひな形ができた状態から開発を開始できる。

 とはいえ、ASP.NET MVCにマニフェスト用のJsonファイルと、Teams内で動かすためのJavaScript SDKの記述を加えただけなので、無くてもそんなに苦労はしない。

 

 最小限∔αのアプリケーションを作成して、変更点を確認するにはもってこいなので、今回はToolkitのテンプレートを利用す。

 

プロジェクトの作成

 

 Toolkitで追加されたプロジェクトテンプレートを利用する。

 「Microsoft Teams App」というテンプレートがあるので選択。

 

 この辺は毎度のプロジェクトの設定項目なので、説明は割愛。最初に入力された値のままでもOK。 

 

 Tab機能を使いたいので「Tab」にチェックを入れる。

 ひな形としてコードが追加されるだけなので、作成後にBotなどを追加できないわけではない。

 

 「Personal tab」にチェックを入れて個人用のタブだけ確認してみる。 

 これで最低限の機能を持った個人用タブのプロジェクトが作成できる。

 

Webアプリケーションとして動かしてみる

 

 プロジェクトの構成が下の画像のようになっているので注意。

 「IIS Express + Teams」だとブラウザーが起動して実行結果が表示されない。アプリケーション自体は動いているのだが、ブラウザーは立ち上がらないので、まずはIIS Express + Browserでデバッグしてみる。 

 起動するとブラウザーには「Teams client host not found」と表示される。

 この部分はJavaScriptで以下のように判定している。

 (Index.cshtml)

    if (window.parent === window.self) {
        message.innerText = 'Teams client host not found.';

 

 Teamsというかiframeかどうか見ている感じ?

 

ローカルのTeamsにインストールする

 

 このアプリケーションをサクッと動作確認するだけなら、同じローカルで起動しているTeamsクライアントにアップロードすることができる。

 TeamsクライアントはOffice365の組織アカウントと紐づいたMicrosoftアカウントでサインイン済みで、かつサイドローディングが許可されている必要がある。

 

 Microsoft Teams Toolkit for Visual Studioのテンプレートには1つ便利な機能があって、

 プロジェクト作成時に導入される「Microsoft Teams Toolkit」というウィンドウで「Edit app package」でアプリケーションのパッケージ用のマニフェストを編集するとローカルで起動しているTeamsクライアントのApp Studioに必要な項目が設定されたマニフェストファイルが転送されるのだ。

Visual StudioのMicrosoft Teams Toolkitウィンドウで編集すると・・・

TeamsクライアントのApp Studioにマニフェストが転送される

 

 まぁ、勝手に追加さるのが迷惑といえなくもないが。以下のようなマニフェストファイルが作られる。

 もちろん、App Studioで自分で設定してもいいけど、マニフェストファイルのJSONのルールに慣れないうちはありがたい。

 

{
  "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.7/MicrosoftTeams.schema.json",
  "manifestVersion": "1.7",
  "version": "1.0.0",
  "id": "56a863ec-b3e3-476e-920f-9df7d8bb70bc",
  "packageName": "com.microsoft.teams.extension",
  "developer": {
    "name": "Developer Name",
    "websiteUrl": "https://localhost:44310",
    "privacyUrl": "https://localhost:44310/home/Privacy",
    "termsOfUseUrl": "https://localhost:44310/home/termsofuse"
  },
  "icons": {
    "color": "color.png",
    "outline": "outline.png"
  },
  "name": {
    "short": "TeamsTabSample002",
    "full": "TeamsTabSample002"
  },
  "description": {
    "short": "Short description for TeamsTabSample002",
    "full": "Full description of TeamsTabSample002"
  },
  "accentColor": "#FFFFFF",
  "configurableTabs": [
    {
      "configurationUrl": "https://localhost:44310/home/config",
      "canUpdateConfiguration": true,
      "scopes": [
        "team",
        "groupchat"
      ]
    }
  ],
  "staticTabs": [
    {
      "entityId": "index",
      "name": "Personal Tab",
      "contentUrl": "https://localhost:44310",
      "scopes": [
        "personal"
      ]
    }
  ],
  "permissions": [
    "identity",
    "messageTeamMembers"
  ],
  "validDomains": [
    "localhost:44310"
  ]
}

 

 あとはTeamsクライアントのApp Studioで今回のアプリケーションを選択し「Test and distribute」タブから「Install」すればOK。

 

インストールしたアプリケーションを動かす

 

 インストールしたアプリケーションはTeamsクライアントの左アイコンの下部にある三点リーダー「・・・」をクリックしてアプリケーションを選択すればOK。

 Webサイトのページがiframeで表示されます。

 今回は個人用タブだけだったので、アプリケーションを起動できるのはここからのみ。

 表示するとWebアプリケーション側でTeamsクライアントの情報であるユーザーアカウントが取得できていることがわかります。

 処理を行っているのはローカルで起動しているASP.NETアプリケーションの以下のJavaScript。

 

(index.chtml)

// Get the current Teams context for the tab
microsoftTeams.getContext((context) => {
    message.innerText = 'Congratulations ' + context.upn + '! This is the tab you made :-)';
});

 

 個人用タブ以外のタブも使いたい場合は、もう少し覚えることが出てくるけど、今回はここまで。

 

 


 ngrokを利用すると、ローカルで実行しているASP.NETアプリケーションにグローバルアドレスでアクセスすることができて便利です。

 Teamsアプリ開発でもサーバー側の動作確認をするのにいちいちサーバーに上げていては色々と面倒。

 ということで、ローカルのIIS Express上で動作しているサーバーでデバッグするわけですが、多少戸惑う点があります。

 

ポート番号の指定について

 

 ASP.NETアプリケーションをデバッグする際にアクセスするアドレスを見ると、ブラウザに表示されているURLは44340ポートを指定しているとします。

 

 ngrokでトンネルするポートはこの番号ではなくて、プロジェクトのプロパティから確認できる値です。

 プロジェクトのプロパティの「デバッグ」タブのアプリURLに記載されている値を指定します。この画像の場合は59189ですね。

 

host-headerも指定する

 

 IIS Expressはlocalhost以外の接続をはじく(デフォルトの設定では)のでngrokの設定は

 

♯ngrok http 59189 -host-header=localhost:59189

 

 というふうに、-host-headerを記載します。

 

 ふだん、ASP.NETをバリバリ開発している人には常識なのだろうか?