境界を破壊せよ：VB.NETにおける動的アセンブリロードと「安全な」アンロードの深淵
かつてVB6の時代、私たちは `CreateObject` でCOMコンポーネントを呼び出し、メモリリークの恐怖と戦いながらシステムを構築してきた。時は流れ、.NETという巨大なエコシステムの中で、我々は「動的ロード」という強力な武器を手に入れた。
しかし、多くのエンジニアが犯す過ちがある。それは、安易に `Assembly.LoadFrom` を使い、メモリを汚染し、プロセスを再起動なしでは修正不可能な状態に追い込むことだ。
本稿では、シニアエンジニアの視点から、「AppDomainを用いた隔離と、動的な機能拡張」という、極めてプロフェッショナルなアーキテクチャの真髄を解き明かす。
—
1. なぜ「AppDomain」なのか：隔離の哲学
.NETにおいて、アセンブリを一度ロードすると、デフォルトではプロセスが終了するまでアンロードできない。これはメモリ管理の観点からは致命的だ。
ここで登場するのが `AppDomain` である。AppDomainは論理的な「プロセス内のプロセス」であり、これを利用することで、特定のDLL群を隔離された空間にロードし、不要になればその空間ごと破棄（Unload）できる。
これは、24時間365日稼働する基幹システムにおいて、システムを停止させることなく機能をアップデートするための唯一の解法である。
—
2. 実装の要諦：インターフェースによる疎結合
プラグイン構造の鉄則は、「ホストとプラグインを完全に抽象化すること」だ。プラグイン側は、ホストが提供する共用インターフェースのみを知っていればよい。
‘ ホストとプラグインが共通で参照するインターフェース
Public Interface IPlugin
Function Execute(ByVal data As String) As String
End Interface
3. AppDomainを用いた動的ロードの実装例
以下は、分離されたドメインでアセンブリを読み込み、実行後に安全に破棄するためのプロトタイプだ。
Imports System.Reflection
Public Class PluginLoader
‘ 新しいドメインを生成し、DLLをロード・実行する
Public Sub ExecutePlugin(ByVal assemblyPath As String)
‘ 1. 新しいAppDomainを生成
Dim domainSetup As New AppDomainSetup()
Dim domain As AppDomain = AppDomain.CreateDomain(“PluginDomain_” & Guid.NewGuid().ToString())
Try
‘ 2. ホスト側からプラグインオブジェクトを生成 (プロキシ越しに操作)
‘ CreateInstanceFromAndUnwrap は重要。型をマーシャリングしてやり取りする
Dim plugin As IPlugin = CType(domain.CreateInstanceFromAndUnwrap(
assemblyPath, “PluginNamespace.PluginClass”), IPlugin)
‘ 3. 実行
Dim result As String = plugin.Execute(“DataPayload”)
Console.WriteLine(“Plugin Result: ” & result)
Finally
‘ 4. ドメインの解放 (これが重要。メモリからアンロードされる)
AppDomain.Unload(domain)
End Try
End Sub
End Class
—
4. 伝説のアーキテクトが教える「陥穽」
このコードを実装する際、以下の3点に注意せよ。これを見落とすと、どれだけコードを書いてもメモリリークは止まらない。
- MarshalByRefObjectの活用: プラグインクラスは、必ず `MarshalByRefObject` を継承せよ。これを怠ると、オブジェクトがドメイン間でコピーされてしまい、隔離の意味をなさなくなる。
- イベントハンドラの解除: AppDomainを破棄する前に、ドメイン内のオブジェクトがホスト側のイベントを購読していないか確認せよ。循環参照はアンロード失敗の最大の要因である。
- Windows APIとの共存: もしプラグイン内で `DllImport` を使用している場合、アンロード時に `FreeLibrary` が適切に呼ばれるか確認が必要だ。必要であれば `Finalizer` を慎重に設計せよ。
—
5. レガシー環境と.NET Core/5+の対比
留意すべきは、.NET Core / .NET 5+ 以降では `AppDomain` は非推奨（または利用不可）という点だ。現代の設計では `AssemblyLoadContext` を使用するのが正解である。
しかし、レガシーシステムのリプレースや、WinFormsを用いた長寿な社内ツールの保守において、AppDomainの知識は依然として強力な武器だ。
- レガシー保守時: AppDomainの隔離能力を信じろ。
- モダンな開発時: `AssemblyLoadContext` の複雑な依存関係解決（DependencyContext）をマスターせよ。
—
最後に：自動化とは「変化」を受け入れること
システムを止めることは、ビジネスを止めることと同義だ。
今回提示したプラグインアーキテクチャは、コードの柔軟性を高めるだけでなく、エンジニアに「壊しても直せる」という技術的自由を与える。
VB.NETという枯れた言語であっても、その深淵を覗き込み、メモリとプロセスライフサイクルを掌握した時、あなたはただのコーダーから、システムの運命を操るアーキテクトへと進化する。
次回の更新では、このプラグイン構造をさらに発展させ、メモリマップドファイルを用いた超高速なプロセス間通信について深掘りしよう。
技術に妥協するな。境界を定義し、それを支配せよ。
