@jsakamoto

2020年 08月 06日

EntityFramework Core のエンティティを名前変更したら、テーブル削除/新しい名前でテーブル新規作成のマイグレーションコードが生成されてしまった

C# による、リレーショナルデータベースにアクセスするプログラムを実装していての話。

SQL Server などのリレーショナルデータベースにアクセスする C# プログラムを作成する際、採用しているデータベースアクセスライブラリは、もうここ数年は EntityFramework Core (以下 EFCore) ばかりである。

さてそんな、EFCore を使っての、データベース構造を変更していく作業を進めていた中で、それは起きた。

開発途中、エンティティ名変更の要件が発生

まずとあるプログラムの開発着手当初、下記のようなエンティティを作成していた。

まずエンティティ型として以下のような "Person" クラスを用意し、

public class Person {
  public int Id { get; set; }
  public string Name { get; set; }
}

そしてこの "Person" クラスをエンティティ型としたデータセットプロパティを、データベースコンテキストクラスに追加しておく。

public class MyDbContext : DbContext {
  public DbSet<Person> People { get; set; }
  ...

しばしこの構造で開発を進めていたが、その後、このエンティティ型 "Person" を "BusinessPerson" に名前変更するのが良かろう、ということになった。

そこでまずクラス名を "Person" から "BusinessPerson" 変更し、

public class BusinessPerson {
  ...

データセットプロパティ名も "People" から "BusinessPeople" に変更。

public class MyDbContext : DbContext {
  public DbSet<BusinessPerson> People { get; set; }
  ...

あとは、以上のコードの変更にデータベース構造を追随させるマイグレーションコードを生成すれば OK だ。

生成されたマイグレーションコードが期待と違う!

ということで、(Visual Studio 上で作業していたので、"dotent ef" コマンドの実行ではなく) Visual Studio のパッケージマネージャコンソールウィンドウ内にて、マイグレーションコード生成のコマンド "Add-Migration ..." を実行した。

PM> Add-Migration RenamePersonToBusinessPerson

よしこれで完了、と思ったのだが、生成されたマイグレーションコードを見ると、なんと、既存テーブル ("People") を削除 ("DROP TABLE") してしまい、それから変更後の名前のテーブル ("BusinessPeople") を新規作成 ("CREATE TABLE") するコードになっていたのだ (以下、生成されたマイグレーションコードの抜粋)。

...
migrationBuilder.DropTable(
    name: "People");

migrationBuilder.CreateTable(
    name: "BusinessPeople",
...

これでは、既に People テーブルに格納されていたレコードが全滅である。

期待していたのは、あくまでもテーブル名の変更を行なうマイグレーションコードの生成である。

これはどうしたことか。

EFCore は悪くない

冷静になって考えてみると、こんなマイグレーションコードが生成されるのも無理からぬ事がわかってきた。

EFCore がエンティティ周りのコードの変更を追跡するにあたり、名前の変更であると認識するには、変更の前後での、当該エンティティの "つながり" がわかっていることが必要だ。

実際に EFCore のソースコードを確認したわけではないが、今回の振る舞いから推測するに、EFCore がコード変更の前後での "つながり" を認識するヒント要素は、以下の2つがあるのではないかと思われた。

エンティティ型のクラス名
データセットプロパティ名

つまり、コード変更の前後で、上記いずれか片方でも一致するデータセットプロパティは "つながり" がある、と認識されるのではないか、ということだ。

それが今回は、上記2項目をいずれも変更してしまい、コード変更の前後でつながりがないように見えてしまうことになったので、それで EFCore は、"名前の変更" ではなく "削除""新規作成" と認識してしまっただと考えられた。

ということで、以上の推測に基づき、マイグレーションコードの生成を二段階に分けて実行することでやり直してみた。

まず、エンティティ型のクラス名 "Person" を "BusinessPerson" に変更
ここで一旦、"Add-Migration ..." 実行
次に、データセットプロパティ名 "People" を "BusinessPeople" に変更
最後にもう一度、"Add-Migration ..." 実行

こうすればマイグレーションコードの生成を実行するタイミングでは、"つながり" を認識するためのヒント要素のいずれか片方は一致し続けるので、今度は大丈夫なはずだ。

結果は予想どおり、テーブル名変更のデータベースマイグレーションコードが生成された。(以下抜粋)

...
migrationBuilder.RenameTable(
    name: "People",
    newName: "BusinessPeople");
...

なお、上記の手順は、先にエンティティのクラス名を変更して、次にデータセットプロパティ名の変更という順序としたが、この順序は逆にしても、各マイグレーションコード生成時に "つながり" を認識するためのヒント要素のいずれか片方は一致しているのは変わらない。

つまり、データセットプロパティ名を変更してから、エンティティのクラス名を変更しても、テーブル名変更として認識されるはずだ。

ということで、念のため、上記逆順でも試してみたが、これまた予想どおり、ちゃんとテーブル名変更のデータベースマイグレーションコードが生成された。

まとめ

ということでちょっと手間取ってはしまったが、EFCore の気持ちになって考えてみることで、どうにか解決に至ることができた。

最初は「えっ、なんでテーブル名の変更にならないの!?」とか思ってしまったが、

「プログラムは思ったとおりに動くわけではない。作られたとおりに動くだけだ。」

みたいなどこかで聞いたような格言 (?) のような顛末となった。

# by developer-adjust | 2020-08-06 22:18 | .NET | Comments(0)

2020年 07月 09日

ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 '_content/Foo/Bar.css' not found」が発生したら

C# で Single Page Application (SPA) を実装できるフレームワーク "Blazor (ブレイザー)" を使っての SPA 開発中の話。

はじめに ― "Razor Class Library" パッケージについて

Blazor アプリ開発においては、Blazor コンポーネントを含むクラスライブラリプロジェクトを作成し、他のプロジェクトから参照してそれらを再利用することができる。

これらのライブラリは「Razor クラスライブラリ」と呼ばれ、NuGet パッケージとして単一のファイル (.nupkg ファイル) にパッケージ化することもできる。

「Razor クラスライブラリ」 NuGet パッケージには、JavaScript、CSS、グラフィックス、フォントなどの静的 Web アセットを含めることもでる。

「Razorクラスライブラリ」を作成してパッケージ化する方法

Windows OS で Visual Studio IDE を使用している場合、プロジェクトテンプレートの「Razor クラスライブラリ」を選択して開始することができる。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21591971.png$

dotnet CLI を使用する場合は、「dotnet new razorclasslib」コマンドが同等のことを行なう。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21591930.png$

テンプレートから新しい「Razorクラスライブラリ」プロジェクトが生成されると、そのプロジェクトには、Razor コンポーネント (.razor)、JavaScript、CSS、および PNG 画像ファイルが含まれていることが確認できる。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21591982.png$

そして、このプロジェクト上で必要なものを実装したら、この Razor クラスライブラリを NuGet パッケージファイル（.nupkg）としてパッケージ化可能だ。

Visual Studio IDE を使っている場合は、ソリューションエクスプローラーでプロジェクトのノードを右クリックし、コンテキストメニューの [パッケージ] メニュー項目をクリックすればよい。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21591935.png$

dotnet CLI を使用する場合、「dotnet pack」コマンドによって同じことができる。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21591986.png$

パッケージ処理が完了すると、NuGet パッケージ（.nupkg）ファイルが生成される。

そして、プロジェクトに含まれている静的 Web アセットファイルも、NuGet パッケージファイル内に同梱される。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21591932.png$

パッケージを再配布して使用するには？

「Razorクラスライブラリ」を NuGet パッケージ化した以降、さまざまな方法でこの NuGet パッケージを再配布できる。

最も簡単な方法の 1 つは、NuGet パッケージファイルを、ただただ単純に、ファイルシステム上に保管することだ。

NuGet パッケージを置いてあるフォルダーの場所を、パッケージソース設定に追加しておけば（以下を参照）、

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21592065.png$

それ以降、そのフォルダに配置した NuGet パッケージへのパッケージ参照を、Blazor アプリプロジェクトに追加することができるようになる。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21592009.png$

また、パッケージ参照を追加した以降、index.html または _Host.cshtml などのルートドキュメントから、パッケージ参照している NuGet パッケージに含まれている、静的 Web アセットを参照することができるようになる。

具体的には、以下の命名則の URL で、これらの静的 Web アセットを参照できる。

"_content/"で始まり、
続けて、パッケージの名前、
最後に、アセットファイルのファイル名

以上の要領で、静的 Web アセットを含む再利用可能な Blazor コンポーネントライブラリパッケージを、実に簡単に、作成、再配布、使用することができる。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21592076.png$

ところで。静的 Web アセットファイルはどこ？

さてところで、アプリケーションプロジェクトの出力フォルダを見てみると、そこには、NuGet パッケージによって提供される静的 Web アセットファイルは一切収録されていない。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_21592036.png$

ではいったい、どうやって NuGet パッケージに含まれている静的 Web アセットがブラウザに読み込まれるのだろうか?

重要なのは ".StaticWebAssets.xml" ファイル

答えは、

「これらのファイルは NuGet パッケージキャッシュフォルダーから取得される」

である。

出力フォルダを探してみると、"{OutputName}.StaticWebAssets.xml" というファイル名の XML 形式のファイルを見つけることができるはずだ。

この .StaticWebAssets.xml ファイルは、ビルドプロセスで生成され、このファイルの中に、静的 Web アセットを示す URL パスから、物理的なファイルシステム上の所在への、マッピング情報が記述されている。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_22035480.png$

この .StaticWebAssets.xml ファイルは、

ASP.NET Core に備え付けの "StaticWebAssetsFileProvider" ファイルプロバイダ
（Blazorサーバー、または Blazor WebAssembly で ASP.NET Core ホストの場合）
または Blazor 開発サーバー
（Blazor WebAssembly の場合）

によって読み取られる。

そして "StaticWebAssetsFileProvider" ファイルプロバイダーは、NuGet パッケージキャッシュフォルダーにある静的 Web アセットコンテンツを、.StaticWebAssets.xml ファイルによって提供されるURL マッピング情報を使用して Web ブラウザーに返答する、という仕掛けである。

ASP.NET Core のこの「静的アセット」機能は、ビルド時間を短縮化し、ディスク容量のファイル使用量を削減するのに役立つ。

なお、この機能はアプリケーション開発時のために設計されている。

プロジェクトを発行した後は、発行されたフォルダーには、NuGet パッケージに含まれるすべての静的Web アセットファイルが静的に配置されているのがわかる。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_22035578.png$

やっと本題 ― ある日、コンポーネントのスタイルが失われた!

さて、とある Blazor アプリの開発作業中に、その問題が発生した。

なんと、NuGet パッケージ参照先のコンポーネントのスタイル設定が失われてしまったのだ。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_22035511.png$

Web ブラウザーの開発者ツールを開いて「ネットワーク」タブで再確認してみたところ、静的 Web アセット (この場合、NuGet パッケージにバンドルされた .css ファイル) への HTTP GET 要求が、HTTP 404「リソースが見つかりません」で失敗していた。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_22035535.png$

最初に思い浮かんだ原因は、.StaticWebAssets.xml ファイルが何らかの理由で生成されなかった、又は破損したのではないか、という考えだ。

しかしいざ調べてみたところ、.StaticWebAssets.xml ファイルはちゃんと実在しており、その中身についても何の問題も見当たらなかった。

ではいったい何がこの現象を引き起こしたのだろうか。

真の原因は ...

実はこの現象に遭遇する直前に行なっていたとある作業内容が関係していた。

リリース環境にデプロイしたときにより近い状況でのデバッグを行なう必要があったため、"ASPNETCORE_ENVIRONMENT" 環境変数を、"Development" ではなく、"Release" に設定変更していたのだ。

$ASP.NET Core Blazor アプリで Razor コンポーネントパッケージを使用時、「HTTP 404 \'_content/Foo/Bar.css\' not found」が発生したら_d0079457_22035568.png$

実は、静的 Web アセット機能を実現している StaticWebAssetsFileProvider ファイルプロバイダは、なんと、"Environment" 構成が "Development" の場合にのみアプリケーションに組み込まれるのであった...！（下記のASP.NET Core ソースコードを参照。）

実際、"ASPNETCORE_ENVIRONMENT" 環境変数の設定を、"Development" に戻したところ、先の HTTP 404 エラーは解消され、目的の .css ファイルが正しくブラウザに読み込まれるようになった。

別の回避策

どうしても "Development" 以外の "ASPNETCORE_ENVIRONMENT" 環境変数設定にて、静的 Web アセット機能を有効にする必要がある場合、手動で有効にすることはできる。

前述のとおり、"StaticWebAssetsFileProvider" ファイルプロバイダは、Environment 構成が "Development" の場合に限って、"Program.Main()" 内で呼び出される、"ConfigureWebHostDefaults()" 拡張メソッドの内部でアプリケーションに組み込まれることが、ASP.NET Core のソースコードから読み取れる。

そのソースコードを参考に、次のような実装をすることで、Environment 構成が "Development" 以外に設定されている場合でも、"StaticWebAssetsFileProvider" ファイルプロバイダをアプリケーションに組み込むことが可能だ。

// Program.cs
...
public class Program
{
  ...
  public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
      .ConfigureWebHostDefaults(webBuilder =>
      {
        webBuilder.UseStartup<Startup>();

        // 👇 この "ConfigureAppConfiguration(...)" メソッド呼び出しを追加
        webBuilder.ConfigureAppConfiguration((ctx, cb) =>
        {
          // 👇 このアプリが開発環境で動作していることを示す
          //    何らかの条件式を決めて実装する。
          //    Environment 構成が "Development" の場合は除外することに注意
          if (!ctx.HostingEnvironment.IsDevelopment() &&
               /* ここに条件式 */)
          {
            // 👇 この呼び出しによって "StaticWebAssetsFileProvider" が
            //    静的ファイルミドルウェアに使用されるようになる。
            StaticWebAssetsLoader.UseStaticWebAssets(
              ctx.HostingEnvironment, 
              ctx.Configuration);
          }
        });
        ...

まとめ

Blazor Server アプリ、および Blazor Wasm ASP.NET Core ホストでは、Environment 構成が "Development" の場合にのみ、静的 Web アセット機能を実現している "StaticWebAssetsFileProvider" ファイルプロバイダが組み込まれる。

Razor コンポーネントライブラリパッケージを使用している ASP.NET Core Blazor アプリを開発している最中に、"HTTP 404 '_content/Foo/Bar.css' not found" といったエラーが発生した場合は、"ASPNETCORE_ENVIRONMENT" 環境変数が "Development" になっているかどうかを確認するのがよいかもしれない。

"Development" 以外の値を "ASPNETCORE_ENVIRONMENT" 環境変数に設定しつつ、その状態で Visual Studio IDE または「dotnet run」で実行する必要がある場合は、Program.cs 中に "StaticWebAssetsLoader.UseStaticWebAssets(...)" メソッドの呼び出しを追加することで回避することも可能だ。

# by developer-adjust | 2020-07-09 21:57 | .NET | Comments(0)

2020年 06月 20日

認証が有効な Blazor Wasm アプリで、アクセストークンなしで匿名アクセス可能なエンドポイントに HTTP リクエストを送信する

C# で Single Page Application (SPA) を実装できるフレームワーク "Blazor (ブレイザー)"、その WebAssembly 版を使っての SPA 開発中の話。

プロジェクトテンプレートから認証有効な Blazor Wasm アプリを作るのは簡単

ある日、ASP.NET Coreサーバーでホストされている、認証対応の Blazor WebAssembly アプリを作ることになった。

過去にも、Twitter 認証する Blazor WebAssembly アプリを作ったことはある。

そのときは認証後のセッション情報はブラウザの Cookie を使う方式で実装していた。

そのため、ユーザー情報を内蔵した、また、アクセストークンを使用する方式の Blazor WebAssembly アプリを実装したことはこれまではなかった。

なお、自分は普段は Windows OS の Visual Studio を使って Blazor アプリを開発している。

そのため、下図のとおり、Visual Studio のプロジェクトテンプレートから認証機能付き Blazor WebAssembly アプリを作るのはとても簡単なことだ。

認証が有効な Blazor Wasm アプリで、アクセストークンなしで匿名アクセス可能なエンドポイントに HTTP リクエストを送信する_d0079457_15265582.png

こうして実装した Blazor WebAssembly は認証後のセッション情報はアクセストークンとしてクライアント側に保持される。

この Blazor WebAssembly アプリでは、想定どおり、[Authorizaition] 属性を付与した Web API エンドポイントは匿名アクセスから保護されるようになっていた。

次は公開 API エンドポイントを追加

続けてこのアプリに、"最近の更新" ニュースフィードを一覧表示する機能を実装することになった。

"最近の更新" ニュースフィードのリストは、サーバー側で生成、Web API エンドポイントを経由してクライアント側に提供するように実装。

なお、要件として、このニュースフィードは、ログインしていないユーザーでも公開される必要があった。

そのため，匿名アクセスを許可する目的で，"最近の更新" リストを提供する API エンドポイントには [Authorization] 属性を付与しないよう実装した。


[ApiController]
[Route("[controller]")]
public class RecentlyUpdatesController : ControllerBase
{
  [HttpGet]
  public IEnumerable<string> Get()
  {
    ...

この API 実装を、資格情報なしの cURL コマンドでテストしてみたところ、もちろん問題なく動作た (下図)。

認証が有効な Blazor Wasm アプリで、アクセストークンなしで匿名アクセス可能なエンドポイントに HTTP リクエストを送信する_d0079457_15265992.png

だがしかし... 捕捉されない例外が発生!

サーバ側の実装が完了、続けてクライアント側の実装に取り掛かった。

DI 経由で注入された「HttpClient」オブジェクトを使い、その匿名アクセス可能な API エンドポイントから "最近の更新" リストを取得するコードを記述。

そこまで実装してアプリを実行してみた。

しかし残念ながら、予期せぬことに、画面上に "最近の更新" リストが表示される代わりに何かのエラーが発生してしまった。


Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
  Unhandled exception rendering component: ''
  Microsoft.AspNetCore.Components.WebAssembly.Authentication.AccessTokenNotAvailableException: ''
  at Microsoft.AspNetCore.Components.WebAssembly.Authentication.AuthorizationMessageHandler.SendAsync(
    System.Net.Http.HttpRequestMessage request, 
    System.Threading.CancellationToken cancellationToken)

認証が有効な Blazor Wasm アプリで、アクセストークンなしで匿名アクセス可能なエンドポイントに HTTP リクエストを送信する_d0079457_15265063.png

この例外の原因は...

Visual Studio のプロジェクトテンプレートから「認証」オプションを有効にして作成された Blazor WebAssembly アプリのコードをよく読んでみた。

するとどうやら、HTTP リクエストの送信時は、ユーザがサインインしているかどうかに関わらず、また、リクエスト先の URL に関係なく、その HTTP リクエストに常にアクセストークンを添付するよう、起動時の初期化コードで構成されているようであった。

しかしユーザーがサインインしていないときは、アクセストークンを HTTP 要求に添付したくても、（まだサインインしていないので）アクセストークンを入手前なので添付できない。

以上が原因で AccessTokenNotAvailableException 例外が発生してしまったようだ。

解決方法

この問題を解決する方法は、自分が思いついた範囲だと3つほどある。

解決策その 1

解決策その 1 は、AuthorizationMessageHanlder を設定して、指定されたサブパス以下のエンドポイントにのみアクセストークンを添付できるようにすることである。

この方法を選択するには、まず、サーバ側のエンドポイント (保護したいエンドポイント) の URL を、同じサブパス (例: "/authorized/...") の下になるように配置し直す必要がある。


[Authorize]
[ApiController]
// [Route("[controller]")]
[Route("authorized/[controller]")]
// 👆 このAPIのURLを "authorized "サブパスの下になるように変更。
public class WeatherForecastController : ControllerBase
{
...

次に、クライアント側で AuthorizationMessageHandler をカスタムオプションで設定する必要がある。

これはクライアント側プロジェクトの Program クラスの Main メソッドで行う。


public static async Task Main(string[] args)
{
  var builder = WebAssemblyHostBuilder.CreateDefault(args);
  builder.RootComponents.Add<App>("app");

  // 👇 この、AuthorizationMessageHandler を構成する
  //    コードを追加。
  builder.Services.AddTransient<AuthorizationMessageHandler>(sp =>
  {
    // 👇 作業に必要なサービスを DI から入手。
    var provider = sp.GetRequiredService<IAccessTokenProvider>();
    var naviManager = sp.GetRequiredService<NavigationManager>();

    // 👇 新しい「AuthorizationMessageHandler」インスタンスを作成、
    //    設定後にそれを返す。
    var handler = new AuthorizationMessageHandler(provider, naviManager);
    handler.ConfigureHandler(authorizedUrls: new[] {
      // 👇 ここに、HTTP 要求送信時には
      //    アクセストークンを添付したい URL を列記。
      naviManager.ToAbsoluteUri("authorized/").AbsoluteUri
    });
    return handler;
  });
  ...

最後に、HttpClientFactory に対し、こうして自分で設定したAuthorizationMessageHandler を使用するように設定する。


  ...
  // 👇 BaseAddressAuthorizationMessageHandler ではなく、
  //   上記で設定した AuthorizationMessageHandler を使用。
  builder.Services.AddHttpClient("BlazorWasmApp.ServerAPI", client => ...)
    // .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();
    .AddHttpMessageHandler<AuthorizationMessageHandler>();

  // Supply HttpClient instances that include access tokens when making requests to the server project
  builder.Services.AddTransient(sp => sp.GetRequiredService<IHttpClientFactory>()
    .CreateClient("BlazorWasmApp.ServerAPI"));
  ...

以上で、"/authorized/..." サブパス以下の URL に HTTP 要求を送信する場合にのみ、アクセストークンが添付されるようになる。

解決策その 2

解決策その 2 は、認証が必要なエンドポイントに HTTP リクエストを送信する際に、「IHttpClientFactory」からアクセストークンを添付するように設定された,

名前付きの HTTP クライアントを明示的に取得する方法だ。

まず、クライアント側プロジェクトの Program クラスの Main メソッドで HttpClient を DI に登録する際、IHttpClientFactory サービスから HttpClient を取得するのではなく、ベースアドレスを設定しただけのプレーンな HttpClient を DI に登録するようにする。


  public static async Task Main(string[] args)
  {
    ...
    // 👇 DI には、プレーンな HttpClient サービスを登録。
    // builder.Services.AddTransient(sp => ...CreateClient("BlazorWasmApp.ServerAPI"));
    builder.Services.AddTransient(sp => new HttpClient { 
      BaseAddress = new Uri(builder.HostEnvironment.BaseAddress)
    });
    ...

そして、保護された API エンドポイントに HTTP 要求を送信する際には、DI から直接HttpClient を取得するのではなく、IHttpClientFactory から名前付きの HttpClient オブジェクトを明示的に指定して取得すればよい。


@* @inject HttpClient Http *@
@inject IHttpClientFactory HttpClientFactory
...
@code {
  protected override async Task OnInitializedAsync()
  {
    ...
    // 👇 保護された API にアクセスするためには、
    //    DI から直接 HttpClient を取得しない。
    // forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");

    // 👇 代わりに IHttpClientFactory サービスから
    //    明示的に名前を指定して HttpClient を取得して使用。
    var http = HttpClientFactory.CreateClient("BlazorWasmApp.ServerAPI");
    forecasts = await http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");
}

解決策その 3

解決策その 3 は、解決策その 2 とは逆の解決方法である。

この解決策は、匿名アクセスを許可されたエンドポイントに HTTP リクエストを送信する際に、IHttpClientFactory からプレーンな HTTP クライアントを、名前を指定して明示的に取得する方法だ。

これを行うためには、クライアント側プロジェクトの Program クラスの Main メソッドにて、IHttpClientFactory サービスの構成処理に対し、プレーンな HttpClient を名前付きで登録しておく。


public static async Task Main(string[] args)
{
  ...
  // 👇 プレーンな HttpClient を、
  //    IHttpClientFactory サービスに名前を付けて追加する。
  builder.Services.AddHttpClient("BlazorWasmApp.AnonymousAPI", client => {
    client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress);
  });

  builder.Services.AddHttpClient("BlazorWasmApp.ServerAPI", ...)
      .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();
  ...

そうした上で、公開 API のエンドポイントに HTTP 要求を送信する際には、DI から HttpClient オブジェクトを直接取得するのではなく、IHttpClientFactory から名前を指定して明示的にプレーンな HttpClient オブジェクトを取得して使うとよい。


@* @inject HttpClient Http *@
@inject IHttpClientFactory HttpClientFactory
...
@code {
  protected override async Task OnInitializedAsync()
  {
    ...
    // 👇 公開 API にアクセスするためには、
    //    DI から直接 HttpClient を取得しない。
    // RecentlyUpdates = await Http.GetFromJsonAsync<string[]>("RecentlyUpdates");

    // 👇 代わりに IHttpClientFactory サービスから
    //    明示的に名前を指定して HttpClient を取得して使用。
    var http = HttpClientFactory.CreateClient("BlazorWasmApp.AnonymousAPI");
    RecentlyUpdates = await http.GetFromJsonAsync<string[]>("RecentlyUpdates");
}

まとめ

Visual Studio のプロジェクトテンプレートから "認証 "オプションを有効にして作成した Blazor WebAssembly アプリは、ユーザがサインインしているかどうかに関わらず、常にアクセストークンを HTTP 要求に添付しようとする。

この実装では、たとえ匿名のエンドポイントへのアクセスであっても、ユーザがサインインしていない場合は "AccessTokenNotAvailableException" 例外が発生してしまう。

この問題は、以下のいずれかの方法で回避することが可能だ。

解決策 1. - 指定されたサブパス以下の URL のみにアクセストークンを添付するように制限を設定する。
解決策 2. - 保護された API にアクセスする場合に、アクセストークンを添付するよう構成した HttpClient を明示的に名前を指定して取得して使用する。
解決策 3. - 匿名でアクセス可能な API にアクセスする場合に、プレーンな HttpClient を明示的に名前を指定して取得して使用する。

今回の問題の再現と、上記 3 つの解決策を収録したサンプルコードを、下記 GitHub リポジトリで公開してある。

以上

# by developer-adjust | 2020-06-20 15:45 | .NET | Comments(0)

2020年 05月 27日

ASP.NET Core で静的ファイルを認証で保護する

"Microsoft Docs" サイトに記載のやり方は好きになれず...

C# 等による Web アプリ開発フレームワーク "ASP.NET Core" を用いた、サーバー側実装での話。

数週間ほど前から、新しい ASP.NET Core Web アプリ開発の案件が始まった。

この案件では、この Web アプリ上に配置される静的ファイルの一部を認証で保護、すなわち匿名アクセスは拒否する要件があった。

実のところ、ASP.NET Core 上に配置された静的ファイルを認証で保護する方法についてはわかっていなかった。

そこで、インターネット上で "protect static files, authorization, asp.net core" といったキーワードで検索するところから始めた。

相当数の検索結果がヒットしたが、その多くは "stackoverflow.com" に投稿された質問とその回答だ。

それらの回答は、以下のいずれかの解決策を提案しているケースが多かった。

(A) 自分で ASP.NET Core ミドルウェアのカスタム実装を作り、静的ファイルミドルウェアより前の HTTP 処理パイプラインにそのミドルウェアを差し込み、認証されていない要求をそのミドルウェアで拒否する。
(B) 保護したい静的ファイルを "wwwroot" フォルダの外部に配置し、代わりに、[Authorized] 属性付きの自作の ASP.NET Core MVC コントローラでその保護したい静的ファイルを応答で返すようにする。

特に上記解決策のうち (B) については、下記 URL の "Microsoft Docs" サイトでも公式に説明が掲載されている。

しかしながら、詳細はここでは割愛するが、今回案件特有の要件や背景事情をはじめ、いくつかの要因から、上記解決策 (A) (B) はちょっと採用したくなかった。

そこでもう暫し検索結果を読み進めた結果、幸いなことに、「これはよさそう!」と思われる解決案を stackoverflow.com 内で発見した。

その解決策とは、

「静的ファイルミドルウェアが提供している、"OnPrepareResponse" というコールバックポイントをフックする」

という方法だ。

ASP.NET Core 静的ファイルミドルウェアが提供しているフックポイント

静的ファイルミドルウェアを HTTP 処理パイプラインに登録するとき、すなわち Statrtup クラスの Configure メソッド内で UseStaticFiles() メソッドを呼び出すときだが、この際、StaticFileOptions 型のオプション指定をその引数に渡すことができる。

この　StaticFileOptions クラスに、静的ファイルを処理する直前に自前の処理を差し込みすることができる、あつらえたプロパティが用意されていたのだ。

そのプロパティの名前は OnPrepareResponse。

この OnPrepareResponse プロパティに自前の関数を設定すると、静的ファイルをブラウザに返す直前に、この設定した関数を呼び出してくれるのだ。

この自前の関数内で、要求が認証済みであるか否かに応じて、ブラウザへの応答を変更できる。

早速に、"stackoverflow.com" の下記回答にあるサンプルコードをコピーしてきて試してみた。

なお、もちろんのこと、認証ミドルウェアが静的ファイルミドルウェアよりも先に HTTP 処理パイプラインに登録されている必要がある。静的ファイルミドルウェアが要求を処理するより前に、認証済みであるか否かを判定済みにしておく必要があるからだ。

ということで自分のサンプルコードは下記のようになった。

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
  ...
  app.UseAuthentication();
  app.UseStaticFiles(new StaticFileOptions
  {
    OnPrepareResponse = ctx =>
    {
      // 現在の要求が認証済みでないなら...
      if (!ctx.Context.User.Identity.IsAuthenticated)
      {
        // "HTTP 401 Unauthorized" を返す.
        ctx.Context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
      }
      ...

...なのに秘密のファイルが丸見え!

続けて先のサンプルコードをビルド、実行してみた、のだが...

ASP.NET Core で静的ファイルを認証で保護する_d0079457_21463503.png

期待に相反し、保護したはずの静的ファイルが、匿名アクセスでも見えてしまった!

たしかに自分が設定したコールバック関数は、認証されていない要求がきたら、 "401 Unauthorized" HTTP ステータスをブラウザに返せてはいるようだ。

しかしながら、静的ファイルミドルウェアがブラウザにコンテンツを返す処理に対し何の処置もしていなかったので、こんなことになったらしい。

応答全体を阻止する

HTTP ステータス 401 を返すことに加えて、静的ファイルミドルウェアによる応答本文をどうにかして破棄する必要がある。

これを実現するために、あともう2行、先のサンプルコードに追加した。

...
// "HTTP 401 Unauthorized" を返し...
ctx.Context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;

// さらに下記の2行を追加して、応答ボディを破棄!
ctx.Context.Response.ContentLength = 0;
ctx.Context.Response.Body = Stream.Null;
..

この追加の2行で、静的ファイルミドルウェアによる応答ボディをすべて破棄することができる。

というのも、応答オブジェクトの Body ストリームを System.Null に差し替えているためだ。

System.Null への書き込みはすべて単純に破棄され、また、読み取りは空を返すので、静的ファイルミドルウェアは応答ボディに対して何の影響も及ぼさなくなる。

こうすることで、めでたく、秘密のファイルを保護することに成功した。

ASP.NET Core で静的ファイルを認証で保護する_d0079457_21463908.png

なお、さらなる考慮事項として、ブラウザキャッシュの挙動にも気を付けた方が良さそうだ。

というのも、自分が試した範囲だと、いちど認証を済ませて保護された静的ファイルを開いたことがある場合、その後サインアウトして未認証の状態でも、ブラウザキャッシュから当該静的ファイルを見ることができた場合があったからだ。

自分は "Cache-Control" 応答ヘッダに "no-store" を指定し、キャッシュに保存することを一切禁止とブラウザに知らせることで、この挙動を回避した。

ctx.Context.Response.Headers.Add("Cache-Control", "no-store");

リダイレクトさせたい場合

未認証の状態で保護された静的ファイルの URL が要求されたときに、HTTP 401 応答を返すのではなく、"サインイン" ページなどにリダイレクトさせることも可能だ。

コードは次のようになるだろう。

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
  ...
  app.UseAuthentication();
  app.UseStaticFiles(new StaticFileOptions
  {
    OnPrepareResponse = ctx =>
    {
      if (!ctx.Context.User.Identity.IsAuthenticated)
      {
        // 任意の URL にリダイレクト可能.
        ctx.Context.Response.Redirect("/")
      }
      ...

まとめ

静的ファイルミドルウェアを HTTP 処理パイプラインに登録するとき (UseStaticFiles() 呼び出し) のオプション引数の OnPrepareResponse プロパティを活用することで、静的ファイルを認証で保護することができる。
但し、UseAuthentication() 呼び出しを、UseStaticFiles(...) 呼び出しよりは前に済ませておくこと。
また、HTTP 401 応答を返して要求を拒否する場合は、加えて静的ファイルミドルウェアによる応答ボディ書き込みも阻止すること。
完璧に保護するためには、キャッシュ制御についても考慮が必要。
もちろん、HTTP 401 応用を返すのではなく、特定の URL にリダイレクトさせることもできる。

サンプルコード全体は下記 URL の GitHub リポジトリで公開している。

実際に動作するライブデモサイトも下記 URL で稼働中だ。

https://protect-staticfiles-with-auth-on-aspnetcore.azurewebsites.net/

以上!

# by developer-adjust | 2020-05-27 21:59 | .NET | Comments(0)

2020年 04月 13日

(エディタのXML自動整形でレイアウトが崩れてしまわないよう) プロジェクトファイル外に NuGet パッケージリリースノートを書く

プロジェクトファイルをエディタで編集するのは容易

昨今の C# プログラミングにおける話。
とくに Windows OS 上で Visual Studio を使っての開発場面を想定している。

最近では、XML 形式である C# プロジェクトファイル (.csproj) を、Visual Studio のプロジェクトのプロパティ表示 GUI 経由ではなく、テキストエディタで直接 XML を編集する機会が増えているように思う。

というのも、"SDK スタイル" と呼ばれる今風の形式のプロジェクトファイルであれば、その内容はきわめて簡素だからだ。

加えて既定の設定だと、Visual Studio のソリューションエクスプローラにてプロジェクトのノードをダブルクリックしたときに、そのプロジェクトが "SDK スタイル" であるならば、プロジェクトのプロパティ GUI ではなく、XML テキストエディタで開かれたりもする。

しかしリリースノートの編集は酷いことに...

さてところで、NuGet パッケージライブラリを開発しているような場合は、パッケージに記載されるリリースノートを記述することと思う。

パッケージのリリースノートを、Visual Studio のプロジェクトプロパティ GUI にて編集している間は何の問題もない。

しかしひとたび、Visual Studio のテキストエディタにて、プロジェクトファイルの XML を直接編集し始めると状況は一転する。

というのも、Visual Studio は親切にも、XML 形式であるプロジェクトファイルを保存するたびに、その書式を自動整形してくれるからだ。

そしてこの自動整形が、なんと、プロジェクトファイル内に記載された、改行を含むリリースノートのレイアウトをぶち壊してくれるのである!

(エディタのXML自動整形でレイアウトが崩れてしまわないよう) プロジェクトファイル外に NuGet パッケージリリースノートを書く_d0079457_21171768.gif

ご覧のとおり自動整形が適用されることで、リリースノートに、無用な空白や改行が大量に追加されてしまうのだ。

もちろん、自動整形の機能を無効に設定すれば、このような悲劇は防ぐことが出来る。
とはいえ、今度は、自動整形なしでプロジェクトファイルの編集 (例えば、カスタムビルド処理を書く場合とか) が厄介なことになってしまう。

さてどうしたものか。

解決策

こんなことで悩んでいたある日、ようやく解決策を思いついた。

その方法は、リリースノートをプロジェクトファイル外に記述し、代わりにプロジェクトファイル内からその外部リリースノートファイルを取り込む、というものだ。

以下、その手順を記す。

Step 1. プロジェクトファイル外にリリースノートを記述

まず始めに、"RELEASE-NOTES.txt" といったファイル名のテキストファイルとして、パッケージリリースノートを記述する。

例えばこんな感じ。

v.1.0.1
- Support to Blazor v.3.2 Preview 3.

v.1.0.0
- Initial release.

"RELEASE-NOTES.txt" はどこに配置しても構わないが、以降の説明では、ソリューションがあるフォルダに配置したものとする。

Step 2. プロジェクトファイルからこれを取り込む

次の手筈として、数ステップの MSBuild スクリプトをプロジェクトファイル内に実装し、"RELEASE-NOTES.txt" ファイルの内容を取り込むようにする。

この目的で、MSBuild ターゲットをひとつ作成し (ターゲット名は既存のターゲットと衝突しなければ何でも良い)、"GenerateNuspec" ターゲットよりも前に実行されるようにする。

"GenerateNuspec" ターゲットが実行される直前は、パッケージリリースノートの準備をするのに最適なエントリポイントとなっている。

この MSBuild ターゲットでは、MSBuild に標準で備え付けの "ReadLinesFromFile" タスクを使って "RELEASE-NOTES.txt" ファイルの各行を読み出し、適当なアイテム名 (ここでは "ReleaseNoteLines" とした) の MSBuild アイテムに、読み込んだ各行を出力する。

そしてこれら読み込んだ結果の MSBuild アイテムを使って、"PackageReleaseNotes" MSBuild プロパティを上書き設定すればよい。

なお、既定では、MSBuild はアイテムの連結時、区切り文字をセミコロン (";") で連結する。

しかしここでは、リリースノートを改行区切りで連結する必要がある。

なので、下記のように区切り文字として LF (ラインフィード) を明示的に指定して、MSBuild アイテムの参照を記述する必要がある。

@(ReleaseNoteLines, '%0a')

("%0a" は、MSBuild スクリプトファイル内では "LF" コードを意味する。)

MSBuild ターゲットの全体像は下記のとおりとなる。

<Target Name="BuildPackageReleaseNotes" BeforeTargets="GenerateNuspec">
  <ReadLinesFromFile File="../RELEASE-NOTES.txt" >
    <Output TaskParameter="Lines" ItemName="ReleaseNoteLines"/>
  </ReadLinesFromFile>
  <PropertyGroup>
    <PackageReleaseNotes>@(ReleaseNoteLines, '%0a')</PackageReleaseNotes>
  </PropertyGroup>
</Target>

Step 3. 同僚や他の開発者に向けて、コメントを残す

最後に仕上げとして、もとのリリースノート記述場所に、「パッケージリリースノートは "RELEASE-NOTES.txt" に書いて下さい」というコメントを記載して完成だ。

(エディタのXML自動整形でレイアウトが崩れてしまわないよう) プロジェクトファイル外に NuGet パッケージリリースノートを書く_d0079457_21170860.png

おわり

こうしてようやく、プロジェクトファイルをバリバリと直接エディタで編集もしつつ、安心してパッケージリリースノートも記述できる環境を整えることができた。

# by developer-adjust | 2020-04-13 21:30 | Visual Studio | Comments(0)

2020年 03月 23日

MSBuild の WriteLinesToFile で、改行、あるいはセミコロンを含むテキストを、ファイルに書き出す方法

ビルドスクリプト "MSBuild"

C# プログラミングなどで使われるビルドスクリプト MSBuild のお話。

すなわち、C# プログラミングなどにおいて、"プロジェクトファイル" と呼ばれる、例えば拡張子 .csproj の、XML 書式のあのファイルが、実は MSBuild (エムエスビルド) スクリプトファイルである。

最近は .NET Core の進出により、プロジェクトファイル (MSBuild スクリプトファイル) の中身が、"SDK スタイル" と呼ばれる随分とすっきりした内容に進化している。

また、Visual Studio を使って開発中の場合、この "SDK スタイル" のプロジェクトファイルを、Visual Studio のソリューションエクスプローラからのダブルクリックで、Visual Studio 内のエディタで中身が開かれる (※Visual Studio の設定によって動作は変更可能)。

このようなこともあり、最近はプロジェクトファイル (MSBuild スクリプトファイル) をエディタで直接編集して、ビルド時のカスタム処理などを MSBuild スクリプトとして書くことも多くなった。

MSBuild スクリプトでテキストファイルを書き出す

さてそんな MSBuild スクリプトであるが、つい先日、ビルド時のカスタム処理のひとつとして、とあるテキストファイルの生成を、MSBuild スクリプト内で実装したい要件が発生した。

このようなケースで使える MSBuild スクリプトの標準タスク (プログラミング言語で言うところの標準ライブラリ関数の MSBuild 版) として、WriteLinesToFile タスクがある。

上記公式ドキュメントにあるとおり、使い方は難しくない。

書き込み先のファイルのパスと、書き込む内容の文字列を、それぞれしかるべき属性に指定してやれば良い。

例えば以下のような XML ファイルを、例えば foo.msbuild とかいうファイル名で保存しておき、

<Project>
  <Target Name="test">
    <WriteLinesToFile 
      File="foo.txt" 
      Lines="Hello World" />
  </Target>
</Project>

.NET Core SDK がインストールされている環境 (Windows でも macOS でも各種 Linux ディストリでも OK) で、この foo.msbuild ファイルがあるディレクトリ上で以下のように dotnet コマンドを実行すれば、

dotnet msbuild test.msbuild -t:test

同ディレクトリ直下に、"foo.txt" というファイル名で、中に "Hello World" と書かれたテキストファイルが生成される。

なお、既に指定されたファイル名のファイルが存在している場合は、そのファイルに行追加されるのが既定の動作。

追記ではなく上書きとしたい場合は Overwrite 属性を書き足して true を指定してやればよい。

そうすることで、追記ではなく、上書きの動作となる。

また Overrite="true" を設定している場合に、これから書き込もうとしている内容と、既に存在する書き込み先ファイルの内容とが合致している場合は何もしない、すなわち、書き込み先ファイルの最終更新日時を変更しないようにすることもできる。

そのためには WriteOnlyWhenDifferent 属性に true を設定してやるとよい。

改行を含むテキストファイルを生成するには?

さてそんな WriteLinesToFile 標準タスクであるが、さて、内容が単一行のテキストファイルではなく、複数行の内容のテキストファイルを書き出したい場合はどうすればよいだろうか?

まずひとつめのやり方だが、そもそもとして、MSBuild スクリプトは XML 書式で記述する。

なので、WriteLinesToFile 標準タスクの Lines 属性に指定する内容に、改行を意味する文字コードを XML の文法に従ってエンコードして指定 (実体参照) することで実現可能だ。

LF での改行を行なうなら、以下のように "
" を指定するとよい。

<WriteLinesToFile 
  File="foo.txt" 
  Lines="line1&#xa;line2&#xa;line3"
  Overwrite="true"/>

そして、他にも MSBuild 特有の方法がある。

実は、MSBuild では、「複数の項目 (リスト)」を即値で記述するには、セミコロンで区切る、という文法となっている。

強引にざっくり例えると、JavaScript であれば "[1, 2, 3]" というように「複数の項目」を表現するところを、これを MSBuild で示すと "1;2;3" という記法になる、ということだ。

そして、WriteLinesToFile 標準タスクにおける、書き出すテキスト本文を指定する属性の名前をよくよく見ると、"Lines" というように複数形になっている。

そう、実は WriteLinesToFile 標準タスクは、書き出すテキスト本文の指定に「複数の項目 (リスト)」を渡せる仕様なのだ。

ということで、改行を含むテキストファイルの生成は以下のように記述できる。

<WriteLinesToFile 
  File="foo.txt" 
  Lines="line1;line2;line3"
  Overwrite="true"/>

※こういった MSBuild の書き方は、下記書籍で勉強させていただきました。

...じゃぁセミコロンを書き出すにはどうすれば?

さてここで注意が必要となるのは、「改行がしたいんじゃなくて、セミコロンを含むテキストを書き出したい」場合だ。

実体参照方式で ";" などとセミコロンの文字コードで指定しても、これは効果はない (改行になる)。

よく考えればわかることではあるが、実体参照方式で記述しようとしまいと、その XML を読み込んだ側、すなわち MSBuild エンジンの身にしてみれば、セミコロンはセミコロンである。

つまり、元の XML 側での表現方法が違っても、パース (読み込み) した結果には違いがない訳だ。

このケースで必要なのは XML の書き方の知識ではなく、MSBuild における特殊文字のエスケープ表記方法の知識だ。

幸い、その方法は公式ドキュメントに明記されている。

上記にあるとおり、「% に続く、ASCII 文字コードを意味する16進数表記」という記法で、MSBUild 上における特殊文字、すなわち今回のケースではセミコロンを、表現可能だ。

セミコロンについては、具体的には `%3b` と記述すればよい。

ということで、下記のような C# ソースコードを生成することも可能である。

<WriteLinesToFile 
  File="foo.cs" 
  Lines="var foo = &quot;bar&quot;%3b"
  Overwrite="true"/>

おわり

以上。

XML の実体参照による特殊文字の記述と、MSBUild 固有の特殊文字をエスケープする記法とで、つい頭の中がこんがらがってしまうことがあったので、改めて本記事にまとめてみた次第。

MSBuild スクリプトで、ビルド時に同時に C# ソースファイルを自動生成しようとして、「行末のセミコロンが書き出されない!」と焦っていたのは内緒だ。

# by developer-adjust | 2020-03-23 22:24 | .NET | Comments(0)

2020年 02月 17日

Twitter 認証を実装した ASP.NET Core 3.1 Web アプリで、Twitter 認証時にキャンセルをしたら、アプリがクラッシュした件

背景

ASP.NET Core 3.1 による、C# で実装した自作 Web アプリでの話。

昨今の Web アプリ用フレームワークの例に漏れず、ASP.NET Core においても、いわゆる "Twitter アカウントでサインイン" といった外部認証を実装することは容易である。

例えば Twitter での認証の仕組みを組み込みたい場合は、下記公式ドキュメントなどを参考に実装すればよい。

上記公式ドキュメントを参照することでわかるとおり、他にも、Google アカウントや Microsoft アカウント、Facebook アカウントなどなど、様々な外部アカウントを使った認証が容易に組み込み可能だ。

実装例

実際、自分が開発しているとある Web アプリ (ソースコードは下記) でも、Twitter による認証を実装している。

実装についてポイントだけかいつまむと、まずは自作の Web アプリのソースコード中、DI 機構へのサービス登録を行なっている、Startup クラスの ConfigureServices() メソッド内にて、標準的な Cookie ベースの認証用のサービスに加えて、Twitter 認証のためのサービスを "AddTwitter()" 拡張メソッドで登録してやる。

このタイミングで、Twitter 側で作業を済ませておいた、コンシューマー API キーとシークレットを、Twitter 認証構成オプションに設定するよう実装しておく。

// Startup.cs
...
public void ConfigureServices(IServiceCollection services)
{
  ...
  services.AddAuthentication(...)
    .AddCookie(...)
    // Twitter アカウントでのサインイン機構を組み込み
    .AddTwitter(options =>
    {
      options.ConsumerKey = ...;
      options.ConsumerSecret = ...;
    });
    ...

続けて、HTTP 要求を処理するパイプライン中に、認証の処理を挿入するため、同じく Startup クラス内の Configure() メソッド内にて、"UseAuthentication()" 拡張メソッドをしかるべき順序で呼び出し・ミドルウェアの挿入を行なっておく。

// Startup.cs
public void Configure(IApplicationBuilder app, ...)
{
  ...
  app.UseAuthentication();
  ...

最後に、Twitter アカウントでの認証を開始するための MVC アクションや API エンドポイントを実装し、これを呼び出してやれば良い。

// 何かコントローラなど
...
[HttpGet("/auth/signin")]
public IActionResult SignIn()
{
  // 認証スキーマとして Twitter による外部認証を指定している
  return Challenge(TwitterDefaults.AuthenticationScheme);
}

詳細はかなり端折っているが、概ね上記のような実装にて、この Web アプリの ~/auth/sigin へ遷移すると、Twitter の認証画面が開き、Twitter アカウントによる認証ができるようになる。

Twitter 認証を実装した ASP.NET Core 3.1 Web アプリで、Twitter 認証時にキャンセルをしたら、アプリがクラッシュした件_d0079457_18564335.png

実装の "手抜き" が発覚!

さて、そんな自作 Web アプリにおいて、ちょっと手抜きしていた点が発覚してしまった。

自作 Web アプリから認証を開始し、Twitter 側のページに遷移したあと、この Twitter の認証画面で「キャンセル」された場合を考慮していなかったのだ。

で、実際に Twitter の認証画面でのキャンセルを試してみたところ、あえなく、この自作 Web アプリは HTTP 500 Internal Server Error を吐いてしまった。

ローカル開発環境にて確認してみると、下記のような例外が発生していた。

System.Exception:
  An error was encountered while handling the remote login.
System.Exception:
  Access was denied by the resource owner or by the remote server.
 at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.HandleRequestAsync()

解決方法

では、外部認証先でのキャンセルの操作に対応するにはどうしたらよいのか?

某氏に教えてもらったところ、下記 Stackoverflow のスレッドに答えがあった。

すなわち、Twitter 認証のためのサービスを DI 機構に登録する際、そのオプション構成指定時に「Twitter による認証が失敗した」ときに呼び出されるコールバック関数を指定することができる。

具体的には、オプション引数の Events > OnRemoteFailure プロパティがそのコールバック関数となる。

というか、コールバック関数を指定してアプリケーション開発者が外部認証失敗時の処理を明示しないと、前述の例外発生となってしまうようだ。

さて、OnRemoteFailure で指定するコールバック関数、その引数には RemoteFailureContext オブジェクトが渡される。

このコンテキストオブジェクトには、Exception 型の Failure プロパティが公開されている。

これを参照することで、同じ「認証失敗」であっても、キャンセルなのかもっと他の要因で失敗したのか、処理の場合分けができそうだ (※自分は未確認)。

また、このコールバック関数の引数 = RemoteFailureContext オブジェクトには Response プロパティが提供されている。

この Repsonse オブジェクトを使うことで、外部認証失敗時における、お好みの HTTP 応答を返すことができる。

自分のアプリの場合は、何があろうと雑に、しれっとアプリのトップページに戻すこととした。

具体的には下記のとおり実装してみた。

...
.AddTwitter(options =>
{
  ...
  options.Events.OnRemoteFailure = context =>
  {
    var appUrl = $"{context.Request.Scheme}://{context.Request.Host}/";
    context.Response.Redirect(appUrl);
    context.HandleResponse();
    return Task.CompletedTask;
  };
})
...

まとめ

以上で Twitter の認証画面でキャンセルされた場合でも、HTTP 500 ページになることなく、それなりの動作 (今回の例では単にアプリケーションのトップページに戻るだけ) に収めることができた。

自分は Twitter アカウントによるサインインでしか確認していないが、おそらくは他の外部認証の場合でも、この Events.OnRemoteFailure による外部認証失敗時のハンドリングの仕組みは同じことだろう。

# by developer-adjust | 2020-02-17 19:04 | .NET | Comments(0)

2020年 01月 02日

ASP.NET Core + Angular の組み合わせの Web アプリで、Angular 側にもアプリ自身のバージョン番号を埋め込む

背景

サーバー側実装に ASP.NET Core、クライアント側実装に Angular (本投稿時点で v8) の組み合わせによる Web アプリ開発の話。

昨今は micro service 化であるとか、サーバー側実装は Server less プラットフォームを使うとかも多いのかもと思う。

しかし今回は上記のとおり、サーバー側実装と Angular 側実装とが、Visual Studio / dotnet CLI 開発における単一プロジェクトファイルで集約され、サーバー側もクライアント側も同時並行で開発を進めるような、モノシリックな種類の Web アプリ開発の話である。

サーバー側実装のアプリケーションバージョン番号

さて、サーバー側実装は ASP.NET Core ということで、アプリケーションのバージョン番号の管理 (?) は簡単だ。

方針としては、当該 ASP.NET Core Web アプリプロジェクトの、主たる出力アセンブリのアセンブリバージョンが、そのアプリのバージョン番号であるとする。

実際のバージョン番号の指定方法は、とりあえずプロジェクトファイル (.csproj) 内の <Version> プロパティで、アプリケーションのバージョン番号を記述しておけば無難だろう。

<!-- これは .csproj ファイル -->
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    ...
    <Version>1.2.3.4</Version>
    ...
  </PropertyGroup>
  ...
</Project>

Visual Studio で開発中であれば、プロジェクトファイル (.csproj) を直接エディタで編集するだけではなく、プロジェクトのプロパティ画面から、"パッケージ" セクションの GUI 経由で、"パッケージバージョン" の欄に記入して <Version> プロパティを設定することも可能だ。 ASP.NET Core + Angular の組み合わせの Web アプリで、Angular 側にもアプリ自身のバージョン番号を埋め込む_d0079457_13462702.png

ASP.NET Core + Angular の組み合わせの Web アプリで、Angular 側にもアプリ自身のバージョン番号を埋め込む_d0079457_13462702.png

なお、上記 Visual Studio の GUI 経由での編集でもわかるように、<Version> プロパティは厳密にはパッケージ化する際のパッケージのバージョン番号である。

別途明示しなかった場合にアセンブリバージョンもパッケージバージョンに倣うこととなっている。

ちゃんと区別して取り扱う場合は、<AssemblyVersion> プロパティに、アプリケーションのバージョン番号を記載するとよい。

もちろん、Visual Studio の GUI 上からも設定可能だ。

ASP.NET Core + Angular の組み合わせの Web アプリで、Angular 側にもアプリ自身のバージョン番号を埋め込む_d0079457_13485257.png

こうしてプロジェクトファイルに記載したアセンブリバージョンは、サーバー側実装 (今回は C#) のコードからは、下記コードで取得可能だ。

// これはサーバー側実装の任意の C# コード。
// 変数 appVer に System.Version オブジェクトが入る。
// (上記 .csproj の例だと、ver.1.2.3.4 を示す System.Version オブジェクト)
var appVer = typeof(Program).Assembly.GetName().Version;

なお、プロジェクトファイル (.csproj) 中に記載するアプリケーションのバージョン番号を、どのように加算していくか、CI/CD なども絡めたバージョン番号管理とその自動化などについては、本投稿では割愛する。

クライアント側にも、サーバー側実装と同じバージョン番号を埋め込みたい!

さて、サーバー側実装でこのように管理することとしたアプリケーションのバージョン番号であるが、同じバージョン番号を、クライアント側実装である Angular のコードでも埋め込みたくなった。

というのも、今回案件は前述のとおり、サーバー側実装とクライアント側実装とが割と密接につながっているモノシリック構造である。

そのため、ブラウザに古いバージョンのクライアント側実装がキャッシュされて残ってて、しかしサーバー側実装が新しくなっている、という、サーバー側とクライアント側との間での "アプリケーションのバージョン番号の不一致" が問題になるのである。

その点、ビルド時のタイミングで、クライアント側実装にサーバー側アプリケーションバージョン番号を埋め込むことができれば、あとはサーバー側アプリケーションバージョン番号を返すような Web API をサーバー側に設け、これをクライアント側から呼び出すことで、クライアント側実装が、自身のバージョン番号がサーバー側と食い違っていないか、セルフチェックできるわけだ。

ということで、プロジェクトファイル (.csproj) はすなわち MSBuild スクリプトであるわけなので、プロジェクトファイル (.csproj) 内に MSBuild スクリプトを書き足してこれを実現してみた。

方針としては、「<Version> プロパティの内容を、TypeScript コード表現にして .ts ファイルを生成する」としてみた。

生成する .ts ファイルは、"~/ClientApp/src/app/app.version.ts" とし、生成されるこの .ts ファイルの内容は、以下の TypeScript コードとする。

export const appVersion = "1.2.3.4"

サーバー側とクライアント側とでバージョン番号の不一致がないかチェックする処理などでは、この "app.version.ts" を import して、文字列定数 "appVersion" を参照すればよいようにする。

以上の仕様・要件を実現する、プロジェクトファイル (.csproj) 内に書き足す MSBuild スクリプトは下記のとおりとなった。

<!-- これは .csproj ファイル -->
<Project Sdk="Microsoft.NET.Sdk.Web">
  ...
  <Target 
    Name="GenerateAppVersionFileForSPA" 
    BeforeTargets="PreBuildEvent">
    <WriteLinesToFile 
     File="$(SpaRoot)src/app/app.version.ts"
     Lines="export const appVersion = &quot;$(Version)&quot;"
     Overwrite="true" 
     WriteOnlyWhenDifferent="true">
    </WriteLinesToFile>
  </Target>
  ...
</Project>

まず、(ターゲット名は何でも良いのだが) BeforeTargets 属性として "PreBuildEvent" を指定し、ビルド開始時点で実行されるターゲット枠を用意する。

そして、MSBuild には標準で "WriteLinesToFile" という、テキストファイルへの書き出しを行なうタスクが装備されているので、これを用いて "app.version.ts" ファイルの作成・内容の書き込みを行なっている。

MSBuild スクリプトの仕組みとして、<Version> プロパティの内容は、"$(Version)" の記法で参照、該当部分が置換される。

これを利用して、.ts ファイルの内容としてアセンブリバージョン (厳密にはパッケージバージョン) を書き込んでいる次第。

MSBuild スクリプトファイルは XML 記法なので、ダブルクォーテションの記述などに XML 実体参照記法で記載している点が少し注意すべきところであろうか。

あとは、上書きを許可 (Overwrite="true") しつつ、内容に変化がなければいたずらに書き込んでタイムスタンプを更新してライブリロードが走ったりしないよう、WriteOnlyWhenDifferent="true" の指定を付け加えるなど、微調整して完成である。

以上の仕込みでビルドを実行すると、めでたく、プロジェクトファイル (.csproj) 中で指定したバージョン番号が、TypeScript ソースファイルとしても自動生成されるようになった。

補足

なお、この app.version.ts ファイルであるが、このような MSBuild スクリプトによる自動生成であることを、コメントで明記したほうがよいだろう (下記例)。

// このファイルは "GenerateAppVersionFileForSPA" MSBuild タスクによって自動生成されました。
export const appVersion = "1.2.3.4"

このように複数行にわたるテキストファイルを、"WriteLinesToFile" MSBuild 標準タスクで作成するには、同タスクの "Lines" 属性に指定するテキスト内容を、1行ごとにセミコロン (;) 区切りで記述すればよい。

<!-- これは .csproj ファイル -->
<Project Sdk="Microsoft.NET.Sdk.Web">
  ...
  <Target 
    Name="GenerateAppVersionFileForSPA" 
    BeforeTargets="PreBuildEvent">
    <WriteLinesToFile 
     File="$(SpaRoot)src/app/app.version.ts"
     Lines="// このファイルは～;export const appVersion = &quot;$(Version)&quot;"
     ...
</Project>

まとめ

以上、サーバー側とクライアント側との双方に、プロジェクトファイル (.csproj) に記載されたバージョン番号を埋め込む方法であった。

あとは前述のとおり、サーバー側に自身のバージョン番号を返す Web API を設けつつ、これをクライアント側から呼び出すことで、サーバー/クライアント間のバージョン番号不一致を検出できる。

バージョン番号の不一致を検出したらどうするか (UI 上にその旨通知するとか、問答無用でハードリロードを実行するとか) は、アプリケーションの仕様・要件次第だろう。

また、クライアント側実装にアプリケーションのバージョン番号が埋め込まれているので、気軽にアプリケーションのバージョン番号表示をクライアント側実装のみで行なうことも可能だ。

# by developer-adjust | 2020-01-02 08:41 | .NET | Comments(0)

2019年 12月 28日

Visual Studio 2019や dotnet CLI での "発行" 処理時に、発行したファイルを Zip ファイルにまとめる方法

背景

Visual Studio や dotnet CLI を使っての、C# による ASP.NET Core アプリ開発における話。

一般的な ASP.NET Core Web アプリケーションは、インターネット上に配置して利用してもらうものだ。

しかし今回の案件はちょっと変わってて、開発した Web アプリを、クライアント台数が数十台程度の閉鎖系のローカルエリアネットワーク内で稼働させることとなった。

(ちなみに、開発した ASP.NET Core Web アプリを稼働させるサーバーPCは Windows OS が採用された)

そこで、この案件で開発する ASP.NET Core Web アプリは Windows サービスとして開発。

サーバーPC上への最初のセットアップ (Windows サービスとしての登録) を済ませた以後は、xcopy 配置にて簡易にバージョンアップできるようにすることとした。

さてこのような形態だと、開発した ASP.NET Core Web アプリは、Visual Studio 上で開発中ならば「フォルダへ発行」のプロファイルで、ファイルシステム上に成果物を吐き出すようにすることもあろうかと思う。

但し、そうして吐き出されるファイルはかなりの本数に上る。

今回の案件だと、発行された成果物のファイル本数は 184 ファイルに達した。

このように発行された成果物のファイル群を、そのままやりとりするのは無茶がある。

通常は Zip などのアーカイブファイル x 1つにまとめて、そのアーカイブファイルをやりとるすることであろう。

ということで本案件でも実際、発行された成果物のファイル群は、単一の Zip ファイルに固めて持ち運ぶこととなった。

プロジェクトファイルにちょっと書き足して、自動で Zip 化!

さて、MSBuild 15.8 からは、「指定されたフォルダ内のファイルを、ディレクトリ構造もそのままに、サブフォルダのファイルも含めてまるっと Zip アーカイブファイルにまとめてしまう」という、"ZipDirectory" タスクが追加されたそうだ。

(そう、それまでは、MSBuild 標準では、Zip アーカイブにまとめる機能は備えられておらず、MSBuild 内で Zip アーカイブを作成するためには MSBuild 拡張を導入する必要があった。)

そこで、今回案件では、Visual Studio から「発行」を行なったら、 (発行された成果物のファイル群を収録した) Zip アーカイブファイルを自動で生成するよう、MSBuild スクリプトを仕込むことにしてみた。

MSBuild スクリプトへの仕込みはあっけない。

対象の MSBuild スクリプトファイル = プロジェクトファイル (.csproj) 内に、下記内容のような <Target> ノードを追記するだけだ。

<!-- これは .csproj ファイル -->
<Project Sdk="Microsoft.NET.Sdk.Web">
  ...
  <!-- ↓この Target 要素を記述 -->
  <Target Name="MakeZipPackage" 
          AfterTargets="AfterPublish">
    <MakeDir Directories="$(ProjectDir)..\_release" />
    <ZipDirectory
      SourceDirectory="$(ProjectDir)$(publishUrl)"
      DestinationFile="$(ProjectDir)..\_release\$(AssemblyName)-v.$(Version).zip"
      Overwrite="true" />
  </Target>
  ...
</Project>

もう少し解説を加えよう。

まず Target 要素の Name 属性を "MakeZipPackage" としているが、このビルドターゲットの名前は重要ではない (衝突しなければ/他のターゲットから依存されていなければ、名前は何でも良い)。

それよりも肝心なのは、AfterTargets 属性で指定している、"AfterPublish" というターゲット名。

すなわちこの指定により、発行が行なわれたあとのタイミングで、上記の「Zip アーカイブを作成する」ターゲットが実行されるようになる仕掛けだ。

あとは MakeDir タスクで、作成する Zip アーカイブファイルの配置先フォルダを作成。
そして最後に満を持して ZipDirectory タスクによって、発行先フォルダの中身を Zip アーカイブファイルにまとめて完了だ。

発行先フォルダのパスは、"$(ProjectDir)$(publishUrl)" で参照できるので、これを "ZipDirectory" タスクの "SourceDirectory" パラメータ (Zip 化対象のフォルダの指定) に渡している。

作成する Zip アーカイブファイルの配置先フォルダは概ねどこでも構わない。

ただしプロジェクトフォルダの直下にするのだけは、ややこしいことになりかねないので止めておくのが良さそうだ。

出力先フォルダ (~/bin) より下のサブフォルダか、あるいはプロジェクトフォルダの兄弟フォルダがいいのではないかと思われる。

上記例では、プロジェクトフォルダの兄弟フォルダのレベルで、"_release" というサブフォルダを作成して、そこを Zip アーカイブファイルの配置先としている。

作成する Zip アーカイブファイルのファイル名も、これまた何でも良い。

上記の例では、ビルドで生成されるアセンブリ (.dll) の名前を "$(AssemblyName)" で参照できるので、、これを Zip アーカイブファイルのファイル名としつつ、さらにパッケージバージョンの指定が "$(Version)" で参照できるので、これを利用して、作成する Zip アーカイブファイルのファイル名の後半にバージョン番号を含めるようにしてみた。

上記例のようなビルドターゲットの MSBuild スクリプトをプロジェクトファイル内に仕込むことで、発行された成果物のファイル群を単一の Zip アーカイブファイルにまとめることができるようになった。

dotnet CLI であれば、下記のように、Release 構成でのビルドを指定しつつ、発行を実行することで、発行成果物ファイル群を収録した Zip アーカイブファイルが生成される。

> dotnet publish -c:Release

複数ある発行プロファイルの内ひとつで Zip 化したい場合

もしも、複数の発行プロファイルを使い分けつつ、そのうちのひとつの発行プロファイルで発行する場合のみ、Zip アーカイブファイルを作成したい場合はどうするか。

いくつかやり方はあるのだが、ひとつの方法として、発行プロファイル内に Zip アーカイブファイルを作成する MSBuild スクリプトを仕込むという方法がある。

先の例で記述した <Target Name="MakeZipPackage" ...>...</Target> 要素をいったん .csproj 内からは削除し、代わりに、対象の発行プロファイル、すなわち .pubxml ファイル内に記述するのだ。

<!-- これは Zip 作成を伴いたい発行プロファイル (.pubxml) -->
<Project ...>
  ...
  <Target Name="MakeZipPackage" AfterTargets="AfterPublish">
    <!-- 中身は先の例と同じ -->
    ...
  </Target>
  ...
</Project>

発行プロファイル (.pubxml) を指定しての発行の場合は、発行対象のプロジェクトファイル (.csproj) と発行プロファイル (.pubxml) を合成しての MSBuild 実行に等しい。

なので、ある特定の発行プロファイルでのみ何かさせたい場合 (今回の例では Zip アーカイブファイルの作成を行ないたい) は、発行プロファイル (.pubxml) 側に MSBuild スクリプトを仕込むことで実現可能である。

ちなみに、dotnet CLI で、発行プロファイル (.pubxml) を指定しての発行を行なうには、下記のように、"PublishProfile" MSBuild プロパティに、発行プロファイル (.pubxml) へのプロジェクトからの相対パスを設定して実行すればよい。

> dotnet publish -c:Release -p:PublishProfile={ここに.pubxmlへの相対パス}

複数ある発行プロファイルの内いくつかで Zip 化したい場合

もうちょっと込み入ったケースでは、複数の発行プロファイルがあって、しかしそのうちのひとつだけではなく、いくつかの発行プロファイルで Zip アーカイブファイルを作成したい、というケースも想定される。

ではということで、Zip アーカイブファイルの作成スクリプトを、複数の .pubxml にベタで書いても、まぁ、それで実現はできる。

しかし、できるのではあるが、"DRY 原則" というか、同じスクリプトがコピペで複数のファイルに散在するのは気持ち悪い。
書いていた Zip 作成のスクリプトに手直しが必要になったら、すべての発行プロファイル (.pubxml) で修正作業をするのもどうかと思うわけである。

このようなケースに対処するにはどうするか。

これまたいくつかやり方があるが、一例として、Zip 化する処理はプロジェクトファイル (.csproj) に記載しつつ、「発行後に Zip アーカイブファイルの作成を行なうかどうか」を MSBuild スクリプト内のプロパティでフラグ表現する方法がある。

まず、Zip アーカイブファイルを作成するターゲットは最初の紹介のとおり、(発行プロファイル (.pubxml) ではなく) プロジェクトファイル (.csproj) 内に記述しておく。

但し最初の紹介例に加えて、"Condition" 属性を追加して、「発行後に Zip アーカイブファイルの作成を行なう」フラグが立てられていたときだけ、Zip アーカイブファイル作成ターゲットを有効とするよう書き加える。

なお、「発行後に Zip アーカイブファイルの作成を行なう」フラグを表現する MSBuild プロパティの名前は何でもよく、スクリプトの実装者が決めればよい。

ここでは "MakeZipAfterPublish" というプロパティ名とすることとし、このプロパティに "true" と設定されていた場合にのみ Zip アーカイブファイルを作成する仕様としよう。
その場合、.csproj 内のターゲットの記述は下記要領となる。

<!-- これは .csproj ファイル -->
<Project Sdk="Microsoft.NET.Sdk.Web">
  ...
  <Target Name="MakeZipPackage" 
    AfterTargets="AfterPublish"
    Condition="'$(MakeZipAfterPublish)' == 'true'"><!-- ←これを追加 -->
    <!-- 中身は先の例と同じ -->
    ...
  </Target>
  ...
</Project>

ここまでの段階ではまだ、発行しても、MSBuild プロパティ ”MakeZipAfterPublish" の値は "true" ではない (既定だと空文字になる) ため、Zip アーカイブファイルは作成されない。

最後の仕上げとして、発行後に Zip アーカイブファイル作成を行ないたい各発行プロファイル (.pubxml) 中で、MSBuild プロパティ "MakeZipAfterPublish" の値に "true" を設定してやればよい。

<!-- これは Zip 作成を伴いたい発行プロファイル (.pubxml) -->
<Project ...>
  ...
  <PropertyGroup>
    <!-- どこでもいいので MakeZipAfterPublish プロパティを "true" で定義 -->
    <MakeZipAfterPublish>true</MakeZipAfterPublish>
    ...
  </PropertyGroup>
  ...
</Project>

こうすることで、Zip アーカイブファイル作成を行なう発行プロファイル (.pubxml) を使って発行を実行すると、プロジェクトファイルの内容 + その発行プロファイルの内容が合成されて MSBuild が実行されるので、結果、以下の流れで Zip アーカイブファイルが生成されることとなる。

当該発行プロファイル (.pubxml) 内で MakeZipAfterPublish プロパティに true が設定されている
プロジェクトファイル (.csproj) 内に仕込んでおいた Zip アーカイブファイル作成ターゲットの Condition 属性による条件を満たす
Zip アーカイブファイル作成ターゲットが実行され、Zip アーカイブファイルができあがる

他の実現方法としては、Zip アーカイブファイル作成を行なうターゲット定義を、独立した外部の MSBuild スクリプトファイル (拡張子に決まりはないっぽいが .targets ファイルとか?) に書いておいて、発行プロファイル (.pubxml) からインポートするといった方法も思い浮かぶ。

補足

本投稿では割愛するが、今回紹介したのと同じような要領で、「発行」時ではなく、「ビルド」時に、ビルド成果物のファイル群を自動で Zip アーカイブファイルにまとめるよう、MSBuild スクリプト (.csproj) を記述することも可能だ。

なお、ちょっとした注意事項だが、この MSBuild 標準の "ZipDirectory" タスク、拡張子やファイル名パターンを指定しての、Zip アーカイブファイルへの収録を除外することはできないようだ。

指定したフォルダの中身を、一切合切、Zip アーカイブファイルに収録してしまう他ないらしい。

拡張子やファイル名パターンを指定しての Zip アーカイブファイルへの収録を除外するには、MSBuild 標準の "ZipDirectory" タスクに頼らずに、MSBuild.Extension.Pack NuGet パッケージをプロジェクトに追加して、"MSBuild.ExtensionPack.Compression.Zip" タスクを利用するのがよさそうだ。

NuGet Gallery | MSBuild.Extension.Pack

まとめ

以上、Visual Studio や dotnet CLI を使っての、ASP.NET Core Web アプリケーション開発における、ファイルへの「発行」時に、自動で、発行成果物ファイル群を単一の Zip アーカイブファイルにまとめる、MSBuild を使った方法の紹介であった。

さてさて、しかしながら昨今であれば、何らかの CI/CD のパイプラインで、このような Zip アーカイブファイルを作成するのかな、と想像する (自分はよく知らない)。

また、Docker イメージを構築して、コンテナ上で稼働させるようなケースでは、単一の Docker イメージとして持ち歩けるので、このような Zip アーカイブファイルにまとめるような需要はそもそも発生しないことだろう。

ということで、今となっては、このような方式で、発行成果物の Zip アーカイブファイルを作成するケースはあまりないかもしれない。

...ところで、MSBuild の v.15.8 って、いつリリースされたんでしたっけ??

# by developer-adjust | 2019-12-28 19:16 | .NET | Comments(0)

2019年 11月 22日

EntityFramework Core の ver.3.0 から、"所有されているエンティティ型" に関したテーブル構造が変わってしまった

EFCore の "所有されているエンティティ型"

.NET プログラミングにおけるデータベースアクセスライブラリの定番である、EntityFrame Core (以下、EFCore)。

EFCore を用いたデータベースを読み書きするプログラム開発において用いられる技法のひとつとして、"Code First" と呼ばれる作り方がある。

すなわち、EFCore を基盤とした C# ソースコードとしてデータベースのテーブル構造を記述してプログラムをビルドし、そのプログラムの実行によって、データベースとその構造を自動生成するというものだ。

自分は趣味/仕事の双方で、この "Code First" スタイルのプログラム開発を行なっている。

さてそのような "Code First" スタイルでの EFCore プログラミングにおいて、"所有されているエンティティ型" という機能が EFCore に用意されている。

これは何か、ちょっとサンプルコードを示してみよう。

まず、データベース上で People テーブルにマップすることにする、Person クラスというのを C# ソースコードとして記述する。

public class Person {
  
  public int Id { get; set; }
  
  [Required]
  public string Name {get; set; }

  public double Height { get; set; }

  public double Weight { get; set; }
}

ところで、このプログラム開発において、Height と Weight の 2つのプロパティのペアが、この Person クラスに限らず他の多数のクラス (=テーブル) でも頻出するとしよう。

その場合、Height と Weight の 2つのプロパティを持つ独立したクラスを "所有されているエンティティ型" として作成し (ここでは Metric クラスとする) 各所で再利用できるようになる。

public class Person {
  
  public int Id { get; set; }
  
  [Required]
  public string Name {get; set; }

  public Metric Metric { get; set; }
}

[Owned] // <--  "所有されているエンティティ型" であることを記す
public class Metric {
  
  public double Height { get; set; }

  public double Weight { get; set; }
}

こうして実装したプログラムを実行し、データベースを自動生成されると、次のような People テーブルを作成してくれるのである。

$EntityFramework Core の ver.3.0 から、\"所有されているエンティティ型\" に関したテーブル構造が変わってしまった_d0079457_19544646.png$

"所有されているエンティティ型" を使った実装について、このサンプルコードだと今ひとつ効能がわかりにくいかもしれない。

しかし、同じセンサーデータ構成をセンサーの数だけ同一レコード上に列として並べたい場合など、効率良く且つミスなく実装できるので便利なのである。

なお、"所有されているエンティティ型" は他にもいくつかその自動生成されるデータベース構造にバリエーションがあるのだが、自分はもっぱら上記サンプルコードで示したようなパターンで利用している。

その他、"所有されているエンティティ型" について詳しくは、公式ドキュメントを参照されたし。

EFCore の v2.x と v.3.0 とで生成されるテーブル構造が異なる!

...と、まぁ、このような "所有されているエンティティ型" を活用したプログラム開発を、EFCore の ver.2.1～2.2 ベースで行なってきた。

そしてあくる日。

EFCore の次バージョン、ver.3.0 がリリースされたので、手持ちのプロジェクトの EFCore のバージョンを、ver.2.x から ver.3.0 に更新した。

そして動作を確認していたところ、"所有されているエンティティ型" に関して、自動生成されるテーブル構造が変わっていることに気がついた。

まずおさらいだが、EFCore v2.x においては、最初に示したサンプルコードだと、Height および Weight は、C# コード上は double 型なので、自動生成されるデータベース上の型は float NOT NULL というように非 null 許容となっている。
（以下にデータベース構造の図を再掲する）

$EntityFramework Core の ver.3.0 から、\"所有されているエンティティ型\" に関したテーブル構造が変わってしまった_d0079457_19544646.png$

これは少なくとも自分にとっては直感と相違ない振る舞いである。
もしデータベース上の型を null 許容としたければ、C# コード側を double? と記述することになる。

ところが、である。

EFCore v3.0 だと、同じコードからデータベースを自動生成するようにすると、なんと、C# コード上、"所有されているエンティティ型" に含まれる double 型が、データベース上では float NULL というように null 許容になってしまったのだ（下図）。

$EntityFramework Core の ver.3.0 から、\"所有されているエンティティ型\" に関したテーブル構造が変わってしまった_d0079457_19544610.png$

これが、"所有されているエンティティ型" に含まれるプロパティではなく、テーブルにマップされるクラス直属のプロパティであれば、これまでと変わらない振る舞いとなる。
すなわち、C# コードの double 型はデータベース上の float NOT NULL に、double? 型は float NULL となるようにデータベース構造が生成される。

この "所有されているエンティティ型" に含まれるプロパティが null 許容になってしまう振る舞いは、現時点での最新バージョン (但し安定版ではない) である v.3.1 Preview 3 や、安定版の最新パッチバージョン v.3.0.1 でも同じであった。

破壊的変更があるのは仕方がないが...

まぁ、EFCore も v.2 から v3 へとメジャーバージョンがあがるくらいなので、破壊的変更があるのは仕方がないとは思う。

また、もう既にこの振る舞いで ver.3.0 として安定版リリースされていることもあるだろうから、今更 ver.2.x と同じ動作に戻すことも無理があろう。

しかしである。

ちょっと問題視してる点、というかホントに困った点は、いろいろ調べた限りでは、どうも、"所有されているエンティティ型" に含まれるプロパティを、明示的に非 null 許容としてデータベース生成する方法がなさそうなのだ。

あちこちに Required 属性をつけたり、OnModelCreating() メソッド内で fluent API であれこれモデルの指定を行なっても、 "所有されているエンティティ型" に含まれるプロパティが null 許容になってしまう動作は変えられなかった。

唯一の回避策としては、データベースマイグレーションの仕組みを使ってデータベース自動生成の処理を C# ソースファイルとして生成し、その自動生成されたマイグレーション用の C# ソースファイルを手で編集して、nullable: true になってる箇所を nullable: false に書き直してくれ、というのである (出典は下記)。

$EntityFramework Core の ver.3.0 から、\"所有されているエンティティ型\" に関したテーブル構造が変わってしまった_d0079457_19544615.png$

これはちょっとあんまりではないかと個人的には思われるのだが、どうだろうか。

EFCore は Apache License 2.0 のオープンソース製品であり、リポジトリは GitHub にある。

そして EFCore の GitHub リポジトリ上には本件に関する Issue があがっており（下記 #12100）、いちおう EFCore の開発チームはこの問題(?)を承知しているようではある。

また、必要な人はこの Issue (#12100) に投票しよう、との呼びかけもある。

$EntityFramework Core の ver.3.0 から、\"所有されているエンティティ型\" に関したテーブル構造が変わってしまった_d0079457_19544652.png$

とはいえ、1,000 を超える Issue が開かれたままであり、また、この問題についての Issue についての Vote (投票) 数も目立って多いとはいえず、近い将来の内にも何かしらの対応がなされるのかどうかはあまり期待が持てないでいる。

最後に

この問題(?)を再現するソースコード一式は下記にて公開している。

EFCore の ver.3.x は、ver.2.x に比べていろいろ魅力的な改善が施されており、早く移行したいところではある。

しかし自分がたずさわっているプロダクトではこの件がネックになって、未だに EFCore ver.2.x を使用したまま足踏みしている。

同じ悩みを抱えている方々はいないのだろうか、あるいは、どのように回避されているのであろうか、気になる次第。

# by developer-adjust | 2019-11-22 20:14 | .NET | Comments(0)

12 3 4 5次へ >>>


	ファン申請 ※ メッセージを入力してください

開発途中、エンティティ名変更の要件が発生

生成されたマイグレーションコードが期待と違う!

EFCore は悪くない

まとめ

はじめに ― "Razor Class Library" パッケージについて

「Razorクラスライブラリ」を作成してパッケージ化する方法

パッケージを再配布して使用するには？

ところで。静的 Web アセットファイルはどこ？

重要なのは ".StaticWebAssets.xml" ファイル

やっと本題 ― ある日、コンポーネントのスタイルが失われた!

真の原因は ...

別の回避策

まとめ

プロジェクトテンプレートから認証有効 な Blazor Wasm アプリを作るのは簡単

次は公開 API エンドポイントを追加

だがしかし... 捕捉されない例外が発生!

この例外の原因は...

解決方法

解決策 その 1

解決策 その 2

解決策 その 3

まとめ

"Microsoft Docs" サイトに記載のやり方は好きになれず...

ASP.NET Core 静的ファイルミドルウェアが提供しているフックポイント

...なのに秘密のファイルが丸見え!

応答全体を阻止する

リダイレクトさせたい場合

まとめ

プロジェクトファイルをエディタで編集するのは容易

しかしリリースノートの編集は酷いことに...

解決策

Step 1. プロジェクトファイル外にリリースノートを記述

Step 2. プロジェクトファイルからこれを取り込む

Step 3. 同僚や他の開発者に向けて、コメントを残す

おわり

ビルドスクリプト "MSBuild"

MSBuild スクリプトでテキストファイルを書き出す

改行を含むテキストファイルを生成するには?

...じゃぁセミコロンを書き出すにはどうすれば?

おわり

背景

実装例

実装の "手抜き" が発覚!

解決方法

まとめ

背景

サーバー側実装のアプリケーションバージョン番号

クライアント側にも、サーバー側実装と同じバージョン番号を埋め込みたい!

補足

まとめ

背景

プロジェクトファイルにちょっと書き足して、自動で Zip 化!

複数ある発行プロファイルの内ひとつで Zip 化したい場合

複数ある発行プロファイルの内いくつかで Zip 化したい場合

補足

まとめ

EFCore の "所有されているエンティティ型"

EFCore の v2.x と v.3.0 とで生成されるテーブル構造が異なる!

破壊的変更があるのは仕方がないが...

最後に

ファン申請

プロジェクトテンプレートから認証有効な Blazor Wasm アプリを作るのは簡単

解決策その 1

解決策その 2

解決策その 3