我々の.NET記事のパート2では、.NET Coreに飛び移ることのできなかった、.NETの歴史的テクノロジを振り返ってみたい。これらテクノロジに関して興味深いのは、APIがそのままコピーされており、将来的な.NET Coreでの実装が示唆されていることだ。
Global Assembly Cache
Global Assembly Cache(GAC)の背景にある考え方は、すべての.NETライブラリをひとつの場所に集中して格納できる、というものだ。この意味においてはCOMライブラリと共通しているが、それぞれのライブラリの複数バージョンを格納できる点が異なる。この方法によってMicrosoftは、90年代のアプリケーションを悩ませた"DLL地獄(DLL hell)"を回避しようとしたのだった。
しかしながら、バージョニングの問題は解決しなかった。その上、コード署名証明を取得する必要性や、Windows Vistaで導入されたセキュリティの強化が原因となって、結果的にGACは敬遠されるテクノロジになったのだ。.NET 4.5がリリースされた頃には、Microsoft以外のライブラリにGACを使用するアプリケーションはごく少数になっていた。おもな例外は有償ライブラリだったが、それらもやがて、よりNuGetフレンドリな配信モデルへと移行していった。
そのような状況であったので、.NET Coreの下で、Microsoftが思想を大幅に変更したのは意外なことではなかった。新たなモデルでは、依存関係ライブラリをすべてアプリケーションと合わせてデプロイすることにより、他の.NET Coreアプリケーションからの分離が実現される。従って.NET CoreにはGACの概念は存在しないはずなのだが、
それにも関わらず、GAC APIは残されている。ただし機能はほとんどなく、例えば、アセンブリがGAC内にあるかどうかを示すプロパティは、falseを返すようにハードコードされている。
同社の意図をより明確にするため、GAC APIはすべて廃止予定(obsolete)とマークされており、将来バージョンでは削除される予定である。
Remoting
.NET RemotingはDCOMとJava Remoting (Java RMI)にヒントを得たテクノロジである。3つとも、その基本的な考え方は、プロキシオブジェクトを使用して他のアプリケーション内で動作する実際のオブジェクトを操作することができる、というものだ。 技術的に動作はするものの、適切な使用が難しい上に、不安定だという一般的認識のため、.NET Remotingは普及には至らなかった。
この結果を考慮して、.NET Coreでは.NET Remoting APIは実装されず、GAC APIと同じように、操作不能なプレースホルダとしてのみ存在している。廃止予定にマークされることで、将来的に削除する意図が示されている点も同じだ。
Code Access Security
同じテーマが続くが、Code Access Security (CAS)もまた、実装を伴わないAPIが.NET Coreにコピーされた.NET Frameworkテクノロジのひとつである。他と同じく、このAPIも廃止予定にマークされている。
Code Access Securityは、Dockerなど分離コンテナの時代より前に開発されたものだ。.NET Frameworkの時代には、複数のアプリケーションがひとつのInternet Information Service(IIS)インスタンス内にホストされていた。理論上はそれぞれ分離したApp Domainに隔離されてはいたが、それを破ってIIS上で動作する他のアプリケーションを侵害することは難しくなかった。
想定される被害量を制限するために、Code Access Securityは開発されたのだ。基本的な考え方は、危険なAPIにリスクを示す属性でフラグ付けする、というものだった。IISなどのホストは、アプリケーションをさまざまな"信頼"レベルで実行するように構成することが可能で、理論上はそれらをサンドボックスに格納している。
CASのもうひとつの用途は、ブラウザにホストされるアプリケーションだ。Silverlightよりもはるか前には、Internet Explorer内部でWindows Formsアプリケーションを実行することが可能だった。そのようなアプリケーションの信頼レベルは、イントラネットサイトには高い権限を与えるというように、それがロードされた場所によって部分的に決定されていた。
しかしながら、他の.NETテクノロジと同じように、CASを正しく実装するのは困難だった。悪意を持ったアプリケーションがCASの制限を回避するさまざまな方法が存在する一方で、正しいアプリケーションがその制限によって動作を妨げられることが少なくなかったのだ。結果として、ブラウザにホストされるアプリケーションはほどなく禁止され、IISのCAS信頼性レベルはほとんど無視されるようになった。
Thread.Abort
Thread.Abortが.NET Coreで実装されなかったことには、驚きもあったかも知れない。危険だという認識は常にあったが、不可避なものでもあったからだ。ASP.NETでは、要求のタイムアウトやクライアントの切断といった単純な処理でThread.Abort呼び出しがコールされていたが、コードがそれを処理するように綿密に記述されていないために、取得済のロックやオープン済のデータベーストランザクションなどのリソースリークが発生する場合があった。
ASP.NET Coreが開発されたことで、CancellationTokenがThread.Abortの安全かつ広く受け入れられる代替手段となったため、.NET Coreの最初のバージョンでは実装する必要がなくなっていた。その後、.NET Coreの機能はWebサイトを越えて広がったが、その他の主要なアプリケーションフレームワークでThread.Abortが必要になることはなかったので、PlatformNotSupportedExceptionがスローされるままになっていた。
そして.NET 5で、このメソッドがついに廃止予定にマークされたのだ。
シリーズ最後の記事となるパート３では、ASP.NET Coreについて取り上げる予定である。