上級プロフェッショナル向け：VB.NETでの「AssemblyName」と「Assembly.LoadFrom」によるアドイン機構：プラグイン型アーキテクチャの構築と動的機能拡張の実現
業務システムの寿命は、保守性と拡張性の高さで決まる。
「新しい帳票出力形式を追加してほしい」「外部の基幹システム連携モジュールを差し替えたい」といった要望のたびに、何GBもある巨大なメインアプリケーションをリビルドし、全社展開をやり直す……そんな不毛なデプロイ地獄にいつまで身を置くつもりか。
真にスケーラブルな業務アプリケーションとは、「本体（ホスト）のコードを一切変更することなく、後から追加されたDLLを動的に読み込み、安全に実行できる構造」を持つものである。
今回は、VB.NETの底力を証明する「AssemblyName」と「Assembly.LoadFrom」を駆使した、実戦で通用するプラグイン型アドイン機構の構築手法を、一切の妥協なく伝授する。
—
1. なぜ「Assembly.LoadFrom」と「インターフェイス」なのか？
動的ロードにおいて、アマチュアとプロの決定的な違いは「型安全性をどう担保するか」にある。
よくあるアンチパターンとして、`System.Reflection`の動的バインディング（`InvokeMember`など）を多用し、コンパイル時チェックの恩恵をすべて捨て去る実装が見受けられる。これではちょっとしたメソッド名のタイポで本番障害を引き起こす。
我々が目指すべきアーキテクチャの原則はこうだ：
1. 厳格な契約（Contract）の共有: ホストとプラグインは、共通の「インターフェイス（Interface）」のみを介して会話する。
2. 疎結合なロード: ホストは具象クラスを知らない。知っているのは「特定のインターフェイスを実装したアセンブリ」という事実だけである。
3. 安全なライフサイクル管理: メモリリークやファイルロック（DLLが掴まれたまま削除できない現象）を回避するローディング戦略。
ここで登場するのが、`System.Reflection.Assembly.LoadFrom` と `AssemblyName` である。
—
2. アーキテクチャの全体像
堅牢なプラグイン機構は、以下の3層で構成する。
1. 共通インターフェイス（Shared Contract / .dll）
- ホストとプラグイン双方が参照する共通規格。
2. ホストアプリケーション（Host / .exe）
- プラグインフォルダを監視・スキャンし、動的に読み込んで実行するメインエンジン。
3. プラグイン群（Plugins / .dll）
- 共通インターフェイスを実装した独立した機能モジュール。
—
3. プロダクションコード実装
百聞は一見に如かず。実際にそのまま業務アプリへ組み込めるレベルの、厳格なエラーハンドリングと型安全性を備えたコードを提示する。
Step 1: 共通インターフェイスの定義
まず、ホストとプラグインの「共通言語」となるインターフェイスを定義する。このプロジェクトは独立したクラスライブラリ（例: `Enterprise.Plugin.Contract`）として作成し、ホストとプラグイン双方から参照させる。
Namespace Enterprise.Plugin.Contract
”’
”’
Public Interface IBusinessPlugin
”’
ReadOnly Property PluginName As String
”’
ReadOnly Property Version As Version
”’
”’ 業務データやログ出力基盤を渡すコンテキスト
Sub Execute(context As Dictionary(Of String, Object))
End Interface
End Namespace
Step 2: プラグイン側の実装（別プロジェクト）
次に、プラグイン側の実装例だ。共通インターフェイスを参照する独立したDLLプロジェクトを作成する。
Imports Enterprise.Plugin.Contract
Public Class ExcelExportPlugin
Implements IBusinessPlugin
Public ReadOnly Property PluginName As String Implements IBusinessPlugin.PluginName
Get
“高度Excel出力プラグイン”
End Get
End Property
Public ReadOnly Property Version As Version Implements IBusinessPlugin.Version
Get
Return New Version(1, 0, 0, 0)
End Get
End Property
Public Sub Execute(context As Dictionary(Of String, Object)) Implements IBusinessPlugin.Execute
‘ 実業務の処理（例：コンテキストからデータを取り出して処理）
Dim targetData = DirectCast(context(“TargetData”), String)
Console.WriteLine($”[{PluginName}] 処理を開始します。対象データ: {targetData}”)
‘ TODO: 実際のExcelエクスポート処理をここに記述
Console.WriteLine($”[{PluginName}] 処理が正常に完了しました。”)
End Sub
End Class
Step 3: ホスト側の動的ロードエンジン（真骨頂）
ここからがホストアプリケーション側の実装だ。指定されたディレクトリからDLLをスキャンし、`AssemblyName` でアセンブリの整合性を検証した上で、安全にインスタンス化する。
Imports System.IO
Imports System.Reflection
Imports Enterprise.Plugin.Contract
Public Class PluginManager
‘ 読み込んだプラグインのコレクション
Private ReadOnly _plugins As New List(Of IBusinessPlugin)
”’
”’
”’ プラグインDLLが格納されているパス
Public Sub LoadPlugins(pluginDirectory As String)
If Not Directory.Exists(pluginDirectory) Then
Throw New DirectoryNotFoundException($”プラグインディレクトリが見つかりません: {pluginDirectory}”)
End If
‘ ディレクトリ内のすべてのDLLを取得
Dim dllFiles As String() = Directory.GetFiles(pluginDirectory, “.dll”)
For Each filePath As String In dllFiles
Try
‘ 1. AssemblyNameを使用して、ファイルを実行前に安全に検査（ファイルロックを最小限に）
Dim an As AssemblyName = AssemblyName.GetAssemblyName(filePath)
‘ 必要に応じてここで公開キーの検証（署名チェック）やバージョン検証を行う
Console.WriteLine($”[Loader] 発見したアセンブリ: {an.Name} (Version: {an.Version})”)
‘ 2. Assembly.LoadFromによる動的ロード
‘ ※注意: LoadFromは依存関係も含めてロードするため、同一フォルダに契約DLLが存在必須
Dim asm As Assembly = Assembly.LoadFrom(filePath)
‘ 3. リフレクションによる型探索とインターフェイスの検証
Dim pluginTypes = asm.GetTypes().Where(
Function(t) t.IsClass AndAlso
Not t.IsAbstract AndAlso
GetType(IBusinessPlugin).IsAssignableFrom(t)
)
‘ 4. インスタンス生成と安全な型キャスト
For Each t As Type In pluginTypes
Dim instance = Activator.CreateInstance(t)
If TypeOf instance Is IBusinessPlugin Then
Dim plugin = DirectCast(instance, IBusinessPlugin)
_plugins.Add(plugin)
Console.WriteLine($”[Loader] プラグイン登録成功: {plugin.PluginName} v{plugin.Version}”)
End If
Next
Catch ex As ReflectionTypeLoadException
‘ プラグイン内部の依存関係エラーなどを詳細にキャッチ
Console.WriteLine($”[Error] プラグインの型読み込みに失敗しました: {Path.GetFileName(filePath)}”)
For Each loaderEx In ex.LoaderExceptions
Console.WriteLine($” -> 詳細: {loaderEx.Message}”)
Next
Catch ex As Exception
Console.WriteLine($”[Error] 予期せぬエラー ({Path.GetFileName(filePath)}): {ex.Message}”)
End Try
Next
End Sub
”’
”’
Public Sub ExecuteAll(sharedData As String)
Dim context As New Dictionary(Of String, Object) From {
{“TargetData”, sharedData},
{“ExecutionTime”, DateTime.Now}
}
For Each plugin As IBusinessPlugin In _plugins
Try
Console.WriteLine($”— プラグイン実行: {plugin.PluginName} —“)
plugin.Execute(context)
Catch ex As Exception
‘ 個別プラグインのクラッシュがホスト全体に波及しないよう完全に隔離
Console.WriteLine($”[Fatal] プラグイン [{plugin.PluginName}] の実行中に例外が発生しました: {ex.Message}”)
End Try
Next
End Sub
End Class
—
4. 現場で絶対に知っておくべき「罠」と回避策
上級エンジニアとして、綺麗事だけではなくプロダクション環境で直面する「泥臭い罠」と、その回避策を共有しておく。
① ファイルロック問題（Assembly.LoadFromの呪縛）
`Assembly.LoadFrom` で読み込まれたアセンブリは、AppDomainが終了するまでホストプロセスがファイルを掴み続ける（ロックする）。つまり、アプリを起動したままプラグインDLLを上書き更新することができない。
- 対策（高度な設計）:
もし「アプリを再起動せずにプラグインをホットリロード（動的差し替え）」したい場合は、`Assembly.LoadFrom` ではなく、`Assembly.Load(Byte())`（バイト配列としてのロード） を採用するべきだ。
一度DLLファイルを `File.ReadAllBytes()` でメモリ上に読み込んでからロードすれば、元のファイルはロックされず、自由に上書きが可能になる。
② 依存関係地獄 (Dependency Hell)
プラグイン側が、ホストとは異なるバージョンのNewtonsoft.JsonやEntity Frameworkなどを参照している場合、`ReflectionTypeLoadException` が発生してロードに失敗する。
- 対策:
プラグインが依存するサードパーティ製ライブラリは、可能な限りホスト側とバージョンを完全一致させるか、`AppDomain.CurrentDomain.AssemblyResolve` イベントをフックして、依存アセンブリの解決パスを動的にコントロールするルーチンをホストに実装すること。
—
5. 結び：スケーラブルなコードこそがエンジニアの武器
「動的ロード」や「リフレクション」と聞くと、初学者は魔法のような、あるいは得体の知れない複雑な技術だと身構えがちだ。しかし、その内部で何が行われているのか（ファイルシステム、AssemblyNameによるメタデータ解析、インターフェイスによる多態性）を正確に理解していれば、恐るるに足りない。
このプラグインアーキテクチャを手に入れたあなたなら、もう巨大化したモノリスなプロジェクトに頭を悩ませる必要はない。機能ごとにモジュールを切り出し、必要なパーツだけを後から組み込む――。プロフェッショナルとして、美しく、そして拡張性に満ちたシステムを構築してほしい。
