元技術者のぶーろぐ

asp.net core blazorでJavascriptからC#メソッドを呼び出す方法をMSのサイトや、他のサイトで検索した結果、staticメソッドや他クラスインスタンスメソッドを呼び出す方法については書いてあったが、ページクラスのメソッド呼出しについて書いてあるサイトが見つからなかった。

ページクラスのメソッドが呼べれば、クラス変数がそのまま使用できるので、変数とバインドされているHTMLエレメント値を直接いじれるので便利だと思い、色々試してみた。

サイトに書かれていた説明では、呼出されるC#メソッドには[JSInvokable]属性をつける必要がある。これはどのサイトでも同じことが書かれている。

staticメソッドの場合は、 下記のような感じでJavascriptから呼び出すことが可能。

Dotnet.invokeMethod(<アプリ名>,<メソッド名>[,パラメータ1[,パラメータ2...]])
または
Dotnet.invokeMethodAsync(上記と同様)

ただし、staticメソッドなので、バインドされたページインスタンス変数にはアクセスできない。

もう一つ例が載っているのが、ヘルパークラスを介した呼出し。

C#側
var helper = new MyJsHelper();
await JSRuntime.InvokeVoidAsync("JsFunc",
  DotNetObjectReference.Create(helper));

JS側
function JsFunc(helper) {
  helper.invokeMethodAsync(・・・); // invokeMethodも使用可
}

でも、同じようにバインドされたページインスタンス変数にはアクセスできないよね。(もちろん、ページインスタンスをヘルパーインスタンス内に保存すれば大丈夫かもしれないけれど・・・)

で、上記を見てもしかしてと思って以下のようなコードを書いてみた。

C#側
private string Mesg = "";
・・・
[JSInvokable]
public void CSMethod(int p1, double p2, string p3) {
  Mesg = $"p1={p1}, p2={p2}, p3={p3}";
  this.StateHasChanged(); // JSから呼び出された場合は自動更新されないので
}
・・・
  await JSRuntime.InvokeVoidAsync("JsFunc",
    DotNetObjectReference.Create(this), 
    "CSMethod",10,3.14,"Hello");

JS側
function JsFunc(helper,func,p1,p2,p3) {
  helper.invokeMethodAsync(func,p1,p2,p3);
}

見事に動いてくれました。

で、これ使って何をやりたかったかというと、BingMap等のイベントハンドラをC#で書きたかっただけなのです。実際には、ピン等を追加したりするためにJS関数を細切れに作って、C#から呼び出すことになるんだけどね・・・

以前にも書いたとおり、dotnet core 3からblazor server sideアプリが正式サポートされるようになった。残念ながら、wasm版は3.1からのサポートとなる。(βでは動作確認済み)

で、blazorというかaps.net coreのアプリを実環境に公開してみたくなったので、色々調べてみた。

まず、このブログが動いている、VPSはCentOS6なので、dotnet core 3は動作しない。仕方ないので、CentOS7のVPSを別途契約。

そのVPS上にdotnet core 3 sdkを導入後、簡単なblazor server sideアプリを作成。
dotnet runで開発モードにて動作確認後、下記コマンドでリリース版を作成。

dotnet publish --configuration Release

これで、bin/Release/<target framework>/publishフォルダにアプリケーションがビルドされる。ビルドされたフォルダ中に、<プロジェクト名>.dllが作成されるので、下記コマンドで動作する事を確認する。

dotnet <プロジェクト名>.dll

何も設定せずに動かしてみると、http://localhost:5000およびhttps://localhost:5001でListenしている。待受けアドレスやポートを変更するには、同一フォルダ中のappsetting.jsonに下記セクションを加えるのが簡単な方法だ。

  "Kestrel" : {
    "EndPoints" : {
        "Http" : {
          "Url" : "http://・・・:<待受けポート番号>"
        }
    }
  },

これを外部に公開するのだが、今回はapache httpdのvirtual host機能と、proxyおよびURL書換機能を利用して公開することにした。(一番簡単だと思う)

Kestrelの待受けURLをhttp://localhost:5000とした場合、以下のように設定したconfファイルを/etc/httpd/conf.dに置いてhttpdをリスタートしよう。

# URLで宛先切替
# 一般ホームページ用
<VirtualHost *:80>
        DocumentRoot /var/www/html
        ServerName www.hoge.jp
</VirtualHost>
# asp.net coreアプリ用
# URLの書換はblazor server sideアプリがSignalRを使用するために必要
# 最初、これが無かったので、ページは表示されるけど、イベントが
# ハンドリングされなかった・・・
<VirtualHost *:80>
        ServerName aspcore.hoge.jp
        ProxyPass / http://localhost:5000/
        ProxyPassReverse / http://localhost:5000/
        RewriteEngine on
        RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
        RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
        RewriteRule /(.*) ws://127.0.0.1:5000/$1 [P]
</VirtualHost>

とりあえず、この状態で、dotnet <プロジェクト名>.dllでアプリを実行、外部からアクセスしてみると、ちゃんと動作。
設定ファイルのコメントにも書いてあるけど、最初ProxyPassとProsyReversePassだけ設定して動かしたら、ページ自体は表示されたけど、イベント処理がNG。書換ルール追加を忘れないように(汗)

とりあえず、疎通はうまくいったので、アプリをサービス化しよう。
方法は https://docs.microsoft.com/ja-jp/aspnet/core/host-and-deploy/linux-apache?view=aspnetcore-3.0 などに書かれているように、 /etc/systemd/system にサービス定義ファイルを作成して、サービスを開始してあげればOK。

[Unit]
Description=サービスの説明

[Service]
WorkingDirectory=<作業ディレクトリ>
ExecStart=/usr/bin/dotnet <dllのフルパス>
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=<Syslogに書き出すときのprefix>
User=apache
Environment=ASPNETCORE_ENVIRONMENT=Production 

[Install]
WantedBy=multi-user.target

ちなみに、上記リンクのdotnetパスは/usr/local/binとなっているが、普通にdotnet core sdkをインストールすると、/usr/binにdotnetコマンドが置かれるようだ。
サービス定義後、下記コマンドでサービスを有効化して、起動、状態確認を行う。

# systemctl enable <サービスファイル名>
# systemctl start <サービスファイル名>
# systemctl status <サービスファイル名>
● <サービスファイル名> - <サービス説明>
   Loaded: loaded (/etc/systemd/system/<サービスファイル名>; enabled; vendor preset: disabled)
   Active: active (running) since ・・・ ago
 Main PID: 9999 (dotnet)
   CGroup: /system.slice/<サービスファイル名>
           mq7906 /usr/bin/dotnet <DLLフルパス>

これで、一応公開完了。
実際には結構色々なところで躓いているので、備忘録的に投稿してみた。

ちなみに、公開したページは以下のリンクから参照可能。
http://dnetapp.ohwaki.jp/gradation

dotnet core 3.1 previewでWeb Assemblyのみで動作する、Blazor WebAssembly Appが開発できるようになった。

dotnet core 3.0まではBlazor Server Appつまり、サーバーサイドで、.netの処理を行い、クライアント(ブラウザ)と通信を行って、結果を表示する方式のものしか開発できなかったのだが、Blazor WebAssembly Appでは、サーバーにアクセスするのは、ページロード時のみで、ページが読み込まれた後は全てクライアント側のWebAssembly中で処理が行われる。

Server AppとWebAssembly Appのソースは基本的に互換性があるようだ。(ただし、.netライブラリによってはサポートされないものもある)

試しに、Server Appのrazorページをコピーしてみたら、キチンと動作した。

Server Appと比べてbuildに時間がかかるのと、生成されるWebAssemblyのサイズが大きいためか、最初のページローディングには少々時間がかかる点が気になるが、一度ローディングしてしまえば、クライアント側で全て処理するので、処理している間にWebサーバーが落ちてしまっても問題無い。(実際にロード後にサーバーを落としてみたが、問題無く動作した。)

結構面白い技術だね。

以前、Blazorの記事を書いたが、dotnet core 3.0が正式にリリースされたので、Blazorに関しても色々といじくり回している。

Blazor等ASP.NET Coreのアプリをテンプレートから作成すると、Navigationメニュー付きの画面になってしまうが、これを変更するには、デフォルトのテンプレートを編集するか、別のテンプレートを作成して、ページ内でレイアウトテンプレートを指定する。

テンプレートはASP.NET Coreの場合とBlazorの場合ではレイアウトファイル名やフォルダが異なる。

ASP.NET Coreアプリの場合
・場所
<プロジェクトルート>\Pages\Shared
・ファイル名
_Layout.cshtml

Blazorの場合
・場所
<プロジェクトルート>\Shared
・ファイル名
MainLayout.razor

これらのファイルを直接変更すると、ページソースを変更しなくてもレイアウトを変更できる。

ちなみに、ページ毎に別のレイアウトを作成したい場合は、上記のフォルダにレイアウトファイルを作成して、ページ記述(.cshtmlや.razor)中に@layoutで指定する事が可能。
例えば、ASP.NET Coreアプリで\Pages\Shared\MyLayout.cshtmlを作成して、それをページに適用したい場合は、ページ中に@Layout=”MyLayout”とすれば良い。