xin9le.net

Microsoft の製品/技術が大好きな Microsoft MVP な管理人の技術ブログです。

SDK Style の csproj で ASP.NET (.NET Framework) を動かす

世の中は .NET 6 RC1 がリリースされ、.NET 6 (LTS) の時代がもうすぐそこまで来ています。が、現実はそんなに甘くない!.NET Framework 4.8 + ASP.NET MVC 5 で頑張っている人もいるんです!ただ、一度でも .NET Core 時代の SDK Style の .csproj (新形式) という甘い蜜を吸ってしまうと .NET Framework の .csproj (旧形式) はかなり厳しく感じます。むしろその一点だけでも .NET Framework を敬遠するレベル。特にどの辺りが嫌いかと言うと、

  • NuGet Package の管理が煩雑で、どの dll と依存関係にあるのかが全然分からない
  • .cs ファイルひとつ追加するだけでも .csproj にタグが 1 行増える
  • 多人数開発している際に .csproj がコンフリクトすることがちょくちょくある

などです。SDK Style の .csproj はこういった部分が解決されていて大変スッキリします。昨今は特に Web 開発をすることが多いので ASP.NET + SDK Style .csproj の組み合わせで開発できるようにしておくと何かと平和そう。ということで、今回はそんなアナタ (= 僕自身) のために SDK Style 版の ASP.NET プロジェクトの作り方を書き残します。

書き換え手順

備忘録ということで Step-by-step で作業メモを残します。でき上がりのサンプルプロジェクトは GitHub に Push しておいたので、そちらも併せてご参照ください。

今回は ASP.NET MVC 5 のみを取り扱いますが、一部読み替えれば WebForms / Web API / WebPages / SignalR などでも使えるのではないかと思います。

Step.1 : ASP.NET MVC 5 のプロジェクトを作成

まず、Visual Studio で .NET Framework の ASP.NET Web アプリケーションのプロジェクトを作成します。Wizard をポチポチっとするだけなので簡単です。

f:id:xin9le:20210921170350p:plain

f:id:xin9le:20210921170532p:plain

f:id:xin9le:20210921170905p:plain

親の顔より見た構造のプロジェクトが出来上がりました。.csproj を見てみると、複雑でイヤーな感じの旧形式の XML が見えます。ここから SDK Style の .csproj に書き換えていきましょう。

f:id:xin9le:20210921171401p:plain

Step.2 : .csproj を SDK Style に書き換える

.csproj をテキストエディタで開き、以下のように書き換えましょう。あのクソ長い XML がたったこれだけになります!

<Project Sdk="MSBuild.SDK.SystemWeb/4.0.50">

    <PropertyGroup>
        <TargetFramework>net48</TargetFramework>
    </PropertyGroup>

    <ItemGroup>
        <!-- 必須 -->
        <PackageReference Include="Microsoft.AspNet.Mvc" Version="5.2.7" />
        <PackageReference Include="Microsoft.AspNet.Web.Optimization" Version="1.1.3" />
        <!-- 依存関係パッケージの最新化 -->
        <PackageReference Include="Antlr" Version="3.5.0.2" />
        <PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
        <PackageReference Include="WebGrease" Version="1.6.0" />
    </ItemGroup>

    <ItemGroup>
        <Reference Include="Microsoft.CSharp" />
        <Reference Include="System.Web" />
    </ItemGroup>

</Project>

特に重要なのが 1 行目の <Project Sdk="MSBuild.SDK.SystemWeb/4.0.50"> の部分で、System.Web を利用した IIS 向けアプリケーションビルドをしてくれるようになります。細かいことは気にせず、これを使いましょう。

Step.3 : 不要なファイルを削除

SDK Style にすることで不要になる以下のファイルを削除しましょう。

  • \Properties\AssemblyInfo.cs
  • packages.config

f:id:xin9le:20210921182459p:plain

Step.4 : Assembly Binding のバージョン調整

参照しているアセンブリと Web.config に指定されている Assembly Binding 等のバージョン不一致を調整します。これは直接的には SDK Style 化には関係がないことですが、せっかくなので NuGet Package を最新化しておきましょう。つまりオマケです。

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />
</dependentAssembly>

Step.5 : DotNetCompilerPlatform のバージョン調整

最後に Microsoft.CodeDom.Providers.DotNetCompilerPlatform のバージョンを揃えます。今回だと 3.6.0 の NuGet Package を参照することになるので、該当箇所を 3.6.0.0 にしましょう。これをしないと実行時にエラーになってしまうので、とっても大事!

<system.codedom>
    <compilers>
        <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=3.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701" />
        <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=3.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
    </compilers>
</system.codedom>

できあがり!

以上の 5 step が済んだら以下のようなプロジェクト構成になっているかと思います。特にアセンブリの依存関係部分がスッキリしたのではないでしょうか。

f:id:xin9le:20210921225908p:plain

では最後にデバッグ実行して動作確認をしてみましょう。IIS Express が立ち上がり、これまた親の顔より見た ASP.NET MVC 5 テンプレートの画面が立ち上がるはずです。

f:id:xin9le:20210921183752p:plain

注意点

ここまで来て「最高じゃないか!」と思いたいところですが、実は盛大な落とし穴があります。dotnet publish や Visual Studio の 発行 が .NET Framework の .csproj と同じようには挙動しません...!なんなら全然ダメダメで頭を抱えるレベル。たとえば

  • dotnet publish で bin フォルダの中身のみ出力される
  • web.config が Debug / Release で合成されない

などなど、Production 環境に乗せるにはかなり致命的なものが多いです。ビルド環境を整えようと思ったら華麗なる (?) CI 芸が必要になりそうというか、その部分さえクリアできれば使い物になりそうな予感はします。まさに「あともう一歩」というところでしょうか。

LINE Profile+ に対応した LINE ログイン Provider ライブラリを作りました

業務で LINE ログインを実装することになり、合わせて LINE Profile+ から情報を取得する必要が出ました。ということで LINE Profile+ をサポートした OAuth2 ライブラリを作りました

弊社メンバーで Microsoft MVP for Azure の吉野くんが以前 .NET Core 2.x 世代向けに LINE ログインのライブラリを作っていたので、そこに相乗りさせてもらいました。

Getting Started

このライブラリは ASP.NET Core における外部プロバイダー認証の実装に準拠しています。なので、以下のような感じで始められます。

dotnet add package LineAuthentication
services
    .AddAuthentication()
    .AddLine(options =>
    {
        options.ClientId = Configuration["Authentication:Line:ChannelId"];
        options.ClientSecret = Configuration["Authentication:Line:ChannelSecret"];
    });

LINE Profile+ の情報取得

LineAuthentication-AspNetCore を利用すれば、OAuth の認可スコープを指定することでユーザーの LINE Profile+ から以下の情報を取得できるようになります。会員登録などで利用したいですね。

  • 姓 / 名
  • 姓 / 名 (カナ)
  • 性別
  • 生年月日
  • 住所
  • 電話番号
  • E-mail アドレス

ちょこっと注意が必要なのは、LINE Profile+ にアクセスするためには LINE 側への利用申請が必要な点です。個人情報を扱うのでこればっかりは致し方ない感じはあります。詳細は LINE Developers のドキュメントをご参照ください。

こんな感じで利用します。なんてことはなく、標準に準拠してるので他の外部ログインを実装したことがある方にとってはメッチャ簡単です。

services
    .AddAuthentication()
    .AddLine(options =>
    {
        options.ClientId = Configuration["Authentication:Line:ChannelId"];
        options.ClientSecret = Configuration["Authentication:Line:ChannelSecret"];

        // 認可スコープを追加
        options.Scope.Add("real_name");
        options.Scope.Add("gender");
        options.Scope.Add("birthdate");
        options.Scope.Add("address");
        options.Scope.Add("phone");
        options.Scope.Add("email");

        // JSON ペイロードとの Claim 情報のマッピング
        options.ClaimActions.MapJsonKey(ClaimTypes.Email, "email");

        // JSON ペイロードに丸ッとアクセス
        options.Events.OnCreatingTicket = context =>
        {
            // context.User に JsonElement 形式で入ってます
            var json = context.User.GetRawText();
            return Task.CompletedTask;
        };
    });

なぜ作ったか

ASP.NET Core で OAuth2 による認証 / 認可を実装しようと思ったら、大半の実装は AspNet.Security.OAuth.Providers にあります。この中にも LINE Provider のライブラリは当然あるのですが、

  • LINE Profile+ に対応していない
  • Pull-Request を出してもスピーディ NuGet 化されない
  • .NET 5 のみのサポート

という部分が気掛かりでした。特に最初の 2 点が今回ビジネス的に大変困るということで、別ライブラリとして実装することにしたという感じです。

実際をのところは AspNet.Security.OAuth.Line で LINE Profile+ に対する拡張ポイントが全くないのかと言うとそうではないんですが、ライブラリ規模が非常に小さいのもあって「作り直しするのとほぼ変わらないなぁ」という肌感だったというのが正直なところです。

.NET 5 未満でもモジュール初期化子を利用する

.NET 5 じゃなくても C# 9.0 をできる限り使いたい!そんなあなたのために「.NET 5 未満でも」シリーズ第 2 弾。第 1 弾はこちら

今回はタイトルにある通りモジュール初期化子についてですが、それ自体の用途や詳細挙動は岩永さんのサイトに譲ります。

.NET 5 未満でモジュール初期化子を有効化

モジュール初期化子は ModuleInitializerAttribute を以下の条件を満たすメソッドに付与することで利用できます。

  • 引数なし
  • 戻り値なし
  • static メソッド
  • public / internal のどちらかのアクセシビリティ
  • 非 Generics

逆に言うと ModuleInitializerAttribute をプロジェクト内で用意してあげればコンパイラは解釈できることになります。ということで、準備しましょう。プロジェクト内に閉じるだけであれば internal 型でも問題ありません。

#if !NET5_0_OR_GREATER
// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(AttributeTargets.Method, Inherited = false)]
    internal sealed class ModuleInitializerAttribute : Attribute
    { }
}
#endif

あとは C# 9.0 を明示的に有効化すれば OK です。第 1 弾で紹介した init の有効化の方法と全く同じですね。積極的に (?) コンパイラをハックしていきましょう!

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <!-- これで .NET 5 以外のターゲットに対しても init が有効になる -->
        <TargetFrameworks>netstandard2.0;netstandard2.1;net461;net5</TargetFrameworks>
        <LangVersion>9.0</LangVersion>
    </PropertyGroup>
</Project>

.NET 5 未満でも C# 9.0 の init アクセサを利用する

init アクセサは大変良いです。C# 9.0 で追加された初期化のタイミングでのみプロパティに値を設定できる set アクセサです。アクセシビリティは狭ければ狭いほどコードは安全になるので、僕は set を見たらとりあえず init に置き換える勢い!

.NET 5 未満で init を利用する

init アクセサは内部的にはただの set アクセサです。set アクセサに対して IsExternalInit という型と共に modreq という謎の (?) 修飾を行うことでコンパイラが init な挙動と解釈してくれます。逆に言うと IsExternalInit という型があり、それを解釈できるコンパイラがいれば利用できるとも言えます。

ということで .NET 5 以外のプロジェクトに対して IsExternalInit 型を準備します。.NET 5 で用意されている型は public ですが、プロジェクト内だけに閉じる場合は internal な型で大丈夫です。

#if !NET5_0_OR_GREATER
// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.

namespace System.Runtime.CompilerServices
{
    internal sealed class IsExternalInit
    { }
}
#endif

あとは C# 9.0 を明示的に有効化すれば OK です。

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <!-- これで .NET 5 以外のターゲットに対しても init が有効になる -->
        <TargetFrameworks>netstandard2.0;netstandard2.1;net461;net5</TargetFrameworks>
        <LangVersion>9.0</LangVersion>
    </PropertyGroup>
</Project>

readonly struct の制約緩和

個人的にこれの何が嬉しいかと言うと、C# 7.2 から導入された readonly struct の条件緩和があります。init でコンパイラがアクセシビリティをより細かく制御できるようになったおかげで、以下のように書けるようになりました。

// C# 8.0 までは「getter only + コンストラクタ」しか認められなかった
public readonly struct Person
{
    public string Name { get; }
    public Person(string name)
        => this.Name = name;
}
// C# 9.0 からは init でも大丈夫
public readonly struct Person
{
    public string Name { get; init; }
}

C# 9.0 が利用できるコンパイラさえあれば (= 最新の Visual Studio を利用してさえいれば)、Target Framework が .NET 5 でなくても init を利用できるのは大きなメリットです。

_FunctionsSkipCleanOutput を利用しないで Azure Functions プロジェクトのビルド時 DLL 自動削除から DLL を保護する

タイトルが長過ぎてなんのこっちゃワカランと思います。僕も良いタイトルが浮かびません...(

今回は下記の Issue の内容と公式回答についてザックリ解説します。僕の理解が正確かは分からないので、Issue も読んでもらえると助かりますw

Issue の内容

  • System.Interactive.Async v4.1.1 を NuGet 参照してる Azure Functions プロジェクトがある
    • この NuGet パッケージは C# 8.0 以降で言語サポートされた IAsyncEnumerable<T> を利用するときに高頻度で利用する
  • Azure Functions v3 にデプロイしたら「dll がないぜ!」って例外飛んで動かない!
  • どうやら RemoveRuntimeDependencies のせいで System.Interactive.Async.dll が削除されちゃってるっぽい
  • Microsoft.NET.Sdk.Functions を更新したのが問題ぽい
    • v3.0.3 までは動いてた

背景

Azure Functions は起動高速化などを目的として Functions Host が利用している dll と重複している dll をビルド時に削除するようになっています。これは .csproj ビルド時に RemoveRuntimeDependencies タスクが動くことで実現されていて、既定で有効です。削除対象となる dll は runtimeassemblies.json にリストされているのですが、ここに System.Interactive.Async.dll が入っています。Microsoft.NET.Sdk.Functions v3.0.4 以降で System.Interactive.Async.dll が追加されたようで、「Functions SDK を更新 (v3.0.4+) したら突然動かなくなった!」という感じです。実際僕も業務で同じ問題にブチ当たってしばらくハマりました。

ここで問題だったのが RemoveRuntimeDependencies で削除する際に dll のバージョンを見てくれていなかったことです *1。Azure Functions v3 Host は System.Interactive.Async.dll v3.x.x を参照しているのですが、プロジェクト側で NuGet 参照して利用している v4.x.x を問答無用で削除してしまうことで問題が発生していました。C# 8.0 以降を利用するときに大変相性が悪い事案でツラぽよでした。

これまでの回避策

アセンブリ自動削除が行われなければ問題が起こらないので、RemoveRuntimeDependencies タスクを Opt-out します。_FunctionsSkipCleanOutput = true を .csproj に記述すれば OK です。

<PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>

    <!-- ↓↓ コレを追加 ↓↓ -->
    <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
</PropertyGroup>

という workaround を知っていたのでコメントしておきました。それが 2020 年 7 月の話です。

新しい回避策

それから半年以上経過した 2021 年 3 月。つい最近です。オフィシャルな回答として以下が提示されました。簡単に言うと除外する dll を除外リストに入れられるようになったという感じです。

  1. Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator 1.2.1 以降を参照
  2. <FunctionsPreservedDependencies Include="xxx.dll" /> で除外リストに追加
<ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.11" />

    <!-- ↓↓ コレを追加 ↓↓ -->
    <PackageReference Include="Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator" Version="1.2.1" />
    <FunctionsPreservedDependencies Include="System.Interactive.Async.dll" />
</ItemGroup>

削除されると困る dll を適宜羅列することで、RemoveRuntimeDependencies による出力アセンブリの最適化の恩恵も得られる形になりました。大変ハッピー!

*1:今はバージョンも見て削除しているような気がしなくないですが、まだ未確認なのであまり信じないでください