ASP.NET Coreが.NET Frameworkサポートを終了

先週の金曜日、ASP.NET Coreはひっそりと、.NET Standard 1.*と.NET 4.*から.NET Core 2.0のみに、そのサポート対象を変更した。これにより、Monoあるいはフル.NET Frameworkを実行するASP.NET Core 1.0 / 1.1アプリケーションは、2～3ヶ月内にリリースされる予定のASP.NET Core 2.0にアップグレードできない、ということになる。公開議論や正式発表もなくプラットフォームを大きく変更したと受け取られたことにより、多くの著名な開発者から怒りの声が上っている 。

クロスフレームワークのサポートはこれまで、ASP.NETコアの重要な要素である 考えられてきた。その基本となる考え方は、企業が既存のサービスクラスやリポジトリ、サードパーティ製のライブラリを使用しながら、ASP.NET Coreに即時に切り替えることができる、というものだ。.NET Coreが.NET Frameworkに追いつけば、完全な切り換えが可能になる。

ASP.NETの開発マネージャであるEilon Lipton氏は、今回の変更の背景について次のように解説する。

そうです。ASP.NET Core 2については、ほとんどのライブラリが、.NET Standard TFMではまだ利用できない新しいAPIを使用するため、.NET Core 2をターゲットとするようになります。Microsoft.Extensions.*やEntity Framework Coreのように、複数のプラットフォームをターゲットにする必要のあるコードについては、引き続き.NET Standardを使用することになるでしょう。

必要なAPIを備えた.NET Standard 2.1をなぜ開発しないのか、という疑問を抱くKévin Chalet氏は、次のような疑問を投げ掛ける。

私の疑問は単純です – .NET Desktop上でASP .NET Core 2.0を使用可能にするために、RTMまでのある時点で、これらの変更を修正ないし破棄する予定はあるのでしょうか、あるいは.NET Desktop上のASP.NET 2.0はこのまま、その寿命を終えることになるのでしょうか？(そうであれば、私を含む多くの人々にとって大きな障害になります。)

ここではすべてを紹介しないが、他の多くの開発者も同様の意見だ。

Scott Hanselman氏は、.NET Framework上でASP.NET Coreを使用する主な理由と氏が考えるものを示して、開発者たちの動揺を鎮めようとしている。

AD – LDAPを直接呼びたい場合は、これが完全な差異になります。現時点では、Windows Authに対する認証が可能です。Core 2.0用のDirectoryService名前空間が用意されるのは夏頃になる予定です。

描画 – 全般的に違いがあります。Core 2.0には夏頃の提供を予定しています。このようなnetstandardのオプションとしては、これまでにもImageSharpやImageResizer、Mono optionsなどがありました。

COMオートメーション – これはCore 2.0下では不可能ですが、苦労を厭わないのであれば、Pinvokeは可能です。WebAPIをローカルなnet461+プロセスにすることも不可能ではありません。

WEFアプリとのコード共有 - netstandard2.0ならば完全に可能です。

Hanselman氏はさらに、

.NET Coreはサイドバイサイドで、高速に動作します。(フル).NET Frameworkよりも速く、動作も良好です。ASP.NET Core 2.0を.NET Core 2.0(.NET Standardのスーパーセットであることに注意)上に構築することにより、NetFxよりも、さらにはNetstandardよりも動作の速いものを仕上げることができるのです。

.NET Core 2.0が.NET Standardのスーパーセットであるのは事実だが、.NET Frameworkのスーパーセットではない。Kévin Chalet氏が次のように書いている。

.NET Core 2.0に再導入された“古い”APIの大部分は、実際には(機能的に)動作しないスタブです。.NET Coreから意図的に除外された領域(IdentityModel、WCFサーバ、リモート、AppDomainの完全サポートなど)を含め、いまだ多くのAPIが不足していることは言うまでもありません。

ASP.NET Core 1.0を使用した.NET DesktopアプリをASP .NET Coreと.NET Coreに“安全に”移行できる、と人々に納得させようとするのは - 私に言わせれば - 単に嘘つきです。

今回の唐突な変更に関しては、

(ほとんどの)人たちが望んでいるものだとは思いません。多くの人たちにとって、ライブラリの急な変更は望ましくないのです。すべてを失うリスクを冒すことなく、古いものともうまく統合できるような安定感が求められます。

Allan Lindqvist氏ら何人かの開発者は、コミュニティの分裂を危惧している。

asp.net core 1.1を強く求める開発者の多くは、coreなしで2.0に移行できなくなることを裏切りだと思うでしょう。それが正当化されるか、あるいはされないかは別として、私が言いたいのは、多くの人たちがそのように感じるだろう、ということです。彼らには、彼らよりも保守的な同僚に対する説明が必要なのです。

何か問題があるのでしょうか？これによって、asp.netとcore2/dotnet core2は“死んで”しまうのでしょうか？そうではなく、移行が遅れて、エコシステムが破壊されるだけです。ですがそれは、本当に残念なことです。多くの人たちが、2.0で提供される素晴らしい機能を使えるようにしてほしいと思います。net standardへのクロスコンパイルの廃止は、それに大きく影響するのです。リポジトリを相手にしている人たちにとっては、確かに何の問題もないでしょう。開発者のJoeやJane、さらには彼らのマネージャにとって問題なのです。

もうひとつの問題は、発表や公開議論もなく、この決定が内密に行なわれたことである。Demis Bellot氏は言う。

公式な発表、フィードバック要請、投票、理論的根拠の提示といったものがまったくなかったため、今回の決定は、コミュニティの関与や既存の.NETエコシステムへの影響を考慮することなく実施されたように“思われます”。今後何年にもわたって、エコシステム全体を断片化するのではないでしょうか。.NET v4.xサポートが廃止されたことで、多くの企業は、既存のコードベースをASP.NETの新たな開発モデルに移行できなくなります。これは開発者を.NET Coreに早く移行させるのではなく、逆に採用そのものを思いとどまらせることになり、.NETエコシステムを二分するような大規模な断片化を引き起こしかねません。10年近くを経てもまだ回復できない断片化という、取り返しのつかない傷を負ったPython 2/3と今回の問題に、何らかの違いを見出すことが私にはできないのです。

ライブラリサポートの問題に戻ると、gulbanana氏は、.NET Coreにないもので、自身が必要とするものをいくつか挙げている。

私たちはCore CLRと移植性を完全に支持しています。これまでに数多くのコンポーネントが、ターゲットないしマルチターゲットの対象としてnetstandardに移植されてきました。現時点でLinuxでホストされているアプリをひとつ所有していますが、今後もっと多くのアプリを開発したいと思っています。しかしながら、何でもすぐに移植できる、という方法はありません！まだ開発途上のコードが、次のようなものに依存しているのです。

NTLM認証 (トークンとSPNに関わる高度なシナリオを含む)

前述のSystem.Drawing (ちなみに、私たちに必要なTIFFなどの古いフォーマットは、最近のOSSライブラリではサポートされていません)。

WCF/SOAP APIへの接続 – これにはまだ多くのものがあります。

Windows暗号化API (RSACng、ECDSA、PKIトークン用CSPなど)

WPF GUI - ユーザにはWindows 10にすぐに乗り換える予定がありませんし、たとえそうであっても、Storeアプリは望んでいません。

Microsoft Office interop (特にaccessとexcelに関する)データのインポートとエクスポート

Visual Studioの拡張機能

Oracle ADO.NETプロバイダなどサードパーティプラグイン

これらテクノロジの中には、Core CLRではサポートされないものもあります。ですが、これらは、新しいアプリケーション開発の基礎となる重要な技術です。これらにアクセスできる.NETバージョンが必要なのです。現在の状況であれば何とかなります - “従来の”(実際にはプラットフォーム固有の)依存関係を、net461固有のコンポーネントに分離すればよいのです。これらの機能が必要な一部のビジネスアプリケーションではnetfxを選択しますが、そうでない場合では選択しません。今後新たに開発するアプリでは、レアケースではあると思いますが、0%になるとは考えにくいのです。

interopが重要な開発は、これまでは、すべてcsprojとSDKで行なわれてきた。ASP.NET Coreはinteropを欲する人のための、いわば餌なのだ。それを廃止するというのは、正気の沙汰ではない。そして、“参照を一方向でロードするのは可能だが、実行時に失敗する可能性が高い”のでは、相互運用性とはいえないのだ。

Tim Miller氏が付け加える。

私たちも、現在のWebアプリケーションでODataとSignalRを使用しています。ASP.NETに移行するためには、それらが必要なのです。一方で、ASP.NET Core 1.xのサポートが廃止されて、現在サポートされていないフレームワークパーツのマイグレーションパスがないために、立ち往生するような状況には陥りたくありません。私はASP.NET Coreが、最終的にはASP.NETを置き換えるだろうと見ています。いつになるか分かりませんが、きっとそうなります。数年後にASP.NETの終焉が来た時にはASP. NET Coreで書き直さなければならないのですから、私たちのUIをASP.NET MVC 5で書き直すようなことは(いくつか作業があるとはいえ、規模が小さいので移行は簡単なのですが)、今更やりたくはありません。

常に指摘されているもうひとつの懸念がEntity Frameworkだ。EF Coreは存在するが、以前のバージョンの機能を一部しかサポートしていないため、EF 6上で利用する開発者は比較的少ない。事実、Redditなどフォーラムでの一般的なコンセンサスとして、新プロジェクトにはASP.NET Coreを使用するが、.NET CoreとEF Coreについては安定するまで使用を避けるべきだ、というものがある。

Louis Lewis氏が抱える開発上の問題点は、ハードウェア検出だ。

私たちが使用しているもので、まだ移植されていない項目のリストは、system.management.dllの項目と一致しています。特に重要なのはハードウェア識別子で、Azure Service Busの自動リンク生成、ライセンスサーバとクライアントパッケージ全体のリンク生成に使用しています。これらが現在のAPIにないことで、何か重大な問題が発生するのではないかと思っています。

Christian Weiss氏は、

それから、Azure Service Fabricライブラリももちろん、.NET Core上では動作しません - これも私たちにとって障害です。

計画の見直し

これら批判のすべてに応える形で、Damian Edwards氏が改訂計画を発表した。

.NET Framework上でのASP.NET Core 1.xのサポートを、少なくとも1年(2019年7月まで)延期します。これを毎年見直し、ASP. NET Core 1.xのサポートが終了するまで、12ヶ月の猶予を持って通知します (つまり、2018年7月までに、2020年7月までさらに12ヶ月延期するかどうかを発表します)。(すでに2020年の話をしている、ということに驚く人はいますか？いない？OK、私だけですね。)

新しいSignalRは、ASP.NET Core 1.x(今年後半に提供予定)を対象としてフルサポートします。

System.Webで行なったように、新たな言語をサポートするためのASP.NET Core 1.xのアップデートは今後も継続します。

.NET Core 1.x上で動作するASP.NET Core 1.xは、2018年7月までサポートします(変更なし)。

.NET Core 2+で動作するASP.NET Core 1.xについては、.NET Framework上でASP.NET Core 1.xがサポートされる限りサポートします。つまり、サポート対象の.NET Core上で動作するASP.NET Coreについては、.NET Framework上で動作するものをオーバーラップしてサポートすることで、サポート対象の期間中にユーザが移植できる機会を提供する、ということです。

(ランタイムとしての).NET Core 1.xサポートについて変更ありません。2018年7月までです。ASP.NET Core 1.xを実行しているユーザは、.NET Core 2.0に移動するか、あるいはその時点の.NET Framework(または.NET Core 2.0上のASP.NET Core 2.0)に移行する必要があります。

今年中にSystem.DirectoryServicesとSystem.Drawingを.NETコアに移植します(フルサポート、クロスプラットフォーム、夏までには少なくともWindows版プレビュー)。

後日.NET Coreに移植される対象のリストには、今のところ、ServiceBase(.NET Core Windows Servicesをサポートするため)が含まれていますが、その他については、まだスケジュールがありません(作業の進捗に伴って、スケジュールはより具体的になります)。リストは今後、ユーザからのフィードバックに基づいて修正される予定です。

System.ServiceModel(サーバー側WCF)を.NET Coreに移植する予定は、現時点ではありません。.NET Core用のWCFは引き続き強化され、HTTPメッセージの暗号化など、フィードバックに基づいた機能が追加される予定です。

これがもっと早く述べられていれば苦情の数も減ったかも知れませんが、Micrsoftが.NET Standardから脱却したい理由について、David Fowler氏がリストを挙げています。

.NET Coreで取り組みたい重要なもののひとつに文字列があります。アイデアはたくさんありますが、文字列のデフォルトをutf-8にすることがそのひとつです(互換性の問題が多数ありますが、ここではそれを選択しました)。

もうひとつ修正したい部分として、配列/文字列、あるいは連続したメモリの任意の部分から、スライスを手軽に取得可能にしたいと思います。そのためにSpan<T>を追加し、これを表現する手段としてBuffer<T>を使用します。メモリアロケーションをせずにスライスを取得可能にするために、StringとArrayに新たなインターフェースを実装することになるかも知れません。

この結果として、配列を毎回確保することなく分割可能な、Stringの新しいメソッドを追加します。

IntやUintなど(TryParse)には、Span<char>とSpan<byte>を取るオーバーロードを追加します。

Span<byte>をパラメータとするエンコーディングルーチンを追加します。

Buffer<T>とSpan<T>が、統一的な方法でメモリを表現できるようにします。また、ネットワーキングスタックをアップグレードして、Span<T>またはBuffer<T>を使った固定バッファを渡せるようにしたいと思っています。

Kestrelは2.xのタイムフレーム(現時点では2.1が目標)ではHTTP2を実装します。これによってALPNの実行には、SSLストリームをベースとした新しいAPIが必要になります(https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation)。

.NET CoreのHttp Clientは双方向ストリーミングをサポートしているため、websocketではない単一のHTTP要求を使用した、HTTP経由のストリーミングエンドポイントの実装も可能です。

私たちは、HttpClientとSystem.Net.Httpからヘッダパーサの実装をフォークして、改良のために名称を変更し(https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers)、.NET Frameworkと.NET Coreの両方をサポートしました。.NET Coreにも改良版のコピーがありますが、必要がないので(取り込むことができなかったので)、その改善内容を反映することはしていません。

新しいAPIを利用したスレッドプリミティブがたくさんあるので、それらを利用できれば、新たなシナリオが明らかになるでしょう(https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+author%3Adavidfowl+label%3Aarea-System.Threading)。これらは私が個人的に集めたものの一部です。

これによって問題は部分的に緩和されるが、その一方でStefan Olson氏は、多くの開発者たちの考えを整理している。

asp.net coreは.net standardではなく、.net coreで動作するようになるようです。.net standardのポイントが何であるかはまだ分かりません - 開発されてすぐ、実質的に破棄されることにならなければ、ですが。

現時点でフレームワークに含まれていないものが必要なのですから、asp.net coreに.net standard 2.1が必要だというのは理解できます。ですから、Asp.net coreの最新バージョンが使用可能になるまでは、フルセットの.net frameworkでそれらの機能が追加サポートされるまで、待たなくてはなりませんでした。そうであれば問題はありません。

ところが彼らはそうではなく、standardを破棄して、(この混乱した状況を私が正しく理解しているのならば)使い物にならなくしようとしているのです。

.NET Standardの状況はそれほどひどいものではない。.NET Frameworkと.NET Core両方に対応するサードパーティライブラリを提供する方法として、便利なものであることに変わりないからだ。

不満は続く

Stack OverflowのNick Craver氏が、多くのチームの抱く不満を代弁している。ASP.NET Core + .NET Frameworkへのコードの移植に多くの時間を費やした彼らは、それが無駄な努力であったと感じているのだ。

根本的に大きな違いが残っています。1.xへの移植作業の大部分は同じような作業ですが、私たちの必要な機能もいくつかあります。2.xには価値のあるアップグレードがいくつかありますが、それらを活用できる保証はまだありません。フルフレームワークへの依存が原因で、1.xへの移植に時間やお金や労力をさんざん使った揚げ句、どうしようもなくなる可能性も大きいのです。そんな賭けを仕事でするつもりはありません。現在のASP.NET 4.xよりも、結局はサポートが少なくなってしまうでしょう。

これが変わらない限り、私たちのアプリをASP.NET Coreに移植するつもりはありません。社内利用ができなくなりますから、ライブラリの質も低下するでしょう。

今回の決定が再考されることを、心から願っています。.NET Coreプラットフォームの開発支援に捧げてきた何千時間という個人的時間が、Staxck Overflowの役に立つ日がいつか来れば、と思います。

Quentin氏はこれに同意して、

そうですね、理由は理解できますし、予想できたことだとは言えますが、それでも事前の警告なしで押し付けられた、という点には大きなフラストレーションを感じています。

他の多くと同じく、私たちにも10年以上の歴史を持つ多様な共有ライブラリ、さまざまなMVC 3, 4, 5アプリ、コンソールアプリ、Windowsサービス、数十万行のコードなどで構築されたアプリケーションのエコシステムがあります。アップグレード状況に関しても、遅れは取っていません。

私たちは最近、ASP.Net Core 1.1を使用した新たなWebアプリ開発を２つほど立ち上げました。これらは必然的に、フル4.6.2 Frameworkをターゲットにすることになります。これらのアプリでは、既存の共有ライブラリを大幅に使用しています。 最初はproject.jsonで、次に新しい.csproj、そして新旧の.csprojのミックスを同じソリューションで試した後、以前の.csprojタイプで実行するためにVS15に戻って、System.の依存性が破壊、アセンブリのバインディングに関する問題が次々と発生、さらにはビルドとパブリッシングに関する問題 ... こんな感じで、開発時間の浪費が延々と続いています。

今は行き詰まって、完全なお手上げ状態です。数人月の開発成果を無駄にしながら何をどうすればうまくいくのかを最初に確認して、次にアップデートの方法を検討して、可能ならば実行する、ということを何度も繰り返しているのです。

方向性と必要性に同意できないとは言いませんが、もっと早くからコミュニケーションを取ってくれれば、と思いますね。

未公開の意図

今回の話題において重要なのは、かねてからMicrosoftには変更の意図があったにも関わらず、それについて公表していなかったことだ。David Fowler氏は次のように書いている。

ASP.NET Core 1.1の寿命が引き伸ばされたのは、そういった理由からです(永遠ではありませんが)。SignalRはASP.NET Core 2.0を使用する主な理由のひとつとされているので、確実にサポートします。一方のASP.NET Coreについては、長期的にどこへ向かうのかは分かりませんが、.NET Coreプラットフォームに統合されて、その一部として提供されることに変わりはありません。

これに対してScott Sauber氏は、

私はブログを読み、Twitterをチェックし、カンファレンスに毎年2回以上参加し、ユーザグループに参加するなどして、文字通りASP.NETに関する一挙手一投足をつぶさに見てきました(Hanselman氏とGlenn氏の3時間にわたるDockerのトラブル対応も ... 私には何もできませんでしたが)。ですが、これまでASP.NET Coreの開発方針について聞いたことは一度もありません。その代わりに、“両方のプラットフォームで動作する”ということは何度も耳にしました。当然ながら、それに関しては誰かが、何らかの話し合いの場を設けるものと思っていたのです。私自身もASP.NET Coreに関する講演を行なって、“どちらのプラットフォームでも動作する”と言ってきました。それを信じて行動した人たちに対して、今は申し訳なく思っています。ここITTでは常に最新の環境を求めていますので、この種のニュースを最も受け入れる場所だと思います。そんな場所においても、これほど大きな反発があるのです。時代の最先端を求めていない、ITTに比べれば保守的であろう開発者やそのマネージャにこのニュースが流れれば、事態が悪化することは必至です。

.NET Frameworkに関するさらなる懸念

今回の話題におけるもうひとつのテーマは、.NET Frameworkが今後どうなるかだ。David Fowler氏は言う。

Span自体には動作場所を選ばないポータブルバージョンがあるので、.NET Frameworkへの早急な対応を行なうかどうかは分かりません。Spanを利用するAPIの.NET Frameworkへの追加は、対象が広範囲であるため、Spanそのものより時間を要する可能性があります。最後に.NET Frameworkで、文字列と配列を変更したのはいつだったでしょうか？

問題はSpanそのものにはなく、.NET Frameworkと.NET Coreの拡張機能が.NET Frameworknに引き継がれない場合の実装にあります。Matt Nischan氏によれば、

私は常々、使えるものならばどんなファンキーなライブラリ(kastrelのような)でも利用しようと考えていますが、今は.NET Coreが安定する(ツーリングの変更だけであればうれしいのですが)か、あるいはCoreのクールなコードがFrameworkに戻るのを待っている状況です。ほとんどの人たちが前提としているのは、すべてではないにせよ、corefxが進めてきたことの大部分が、次あるいはその次のFrameworkに反映される、ということだと思います。ですが、今回の変更やその状況を見れば、Frameworkは将来的なプラットフォームではない、ということが(30,000フィートの上空からでも)分かります。

Frans Bouma氏は、

非常によい質問: .net coreの機能からフルスペックの.NETにバックポートするものは、あと何が残っていますか？ここで述べられているとおり、フル.NETの動作は非常に不安定なので、コードの移植に時間が掛かる(作業の速度が遅い)上に、(どこがどう絡まっているか分からないので)いつ動作しなくなるかも知れません。つまりは、不幸な目に合うことが非常に多いのです。

どちらもできない: フル.NETへのバックポートは可能であっても、リリース頻度が非常に低くなる(6ヶ月から1年周期)か、あるいは非常に複雑でエラーが多くなります。もし前者ならば、ユーザが無駄な出費をしないように開発ペースを上げる必要があります。その場合、後者を言い訳に使ってはいけません。後者ならば、結論が正しくないのであって、netstandardは誤りです。将来的に重要なのは.netcoreのAPIだけなのですから。