System.Addinを使う

ででですね、これをぐちゃぐちゃすれば、ほーらアドインのできあがり・・・ってほど簡単じゃないのが現実。

でも、一応、手順を踏まえればできる。

フォルダ構造が決まっちゃってるのは、若干悲しいところではあるが、まぁ許そう。

あと、各アドインはそれぞれのサブフォルダを必要とするらしいので注意。

全く同じinterfaceだったとしても、AddInSideAdaptersとHostSideAdaptersにそれぞれ定義が必要だったりするのも面倒だといえば面倒。

アセンブリ間の依存度を下げたり、ロード時に不要な検索を避けるためとは言え、このパイプラインを作るだけで、結構な手間になるのは間違いない。

interface1つ作って、本体でもアドインでもこれ経由でアクセスしましょうとか、
DLLの動的取り込みはAssembly.LoadFromとか使えばいいじゃん
などという、なんちゃってアドインではないわけですよ。

さて、プログラム内部の動きとして、アドイン自体のAppDomainが、本体のAppDomainと異なるらしいということが、ちょっと調べると分かる。

これは別プロセスで動いているのと大きく変わらないと思ってもらっていいかも知れない。

本体がGUIだった場合、アドイン側から直接書き換えるような処理は、非常に困難だということになる。

描画データをシリアライズ化してアドインから本体に渡して本体側で描画する必要があるだろう。

本体のリソースにアクセスするにも、パイプラインを経由させる必要があるので注意。

ただ、ここまでして、System.Addinでの実装をするメリットというのは、やはりあるわけで。

どうやら、Addinの動的再構築が可能らしいということ。

C#というか、.NET FrameworkではDLL(.NET Assembly)の動的読み込みは出来ても、アンロードができない。
＃win32なdllならLoadLibrary/FreeLibraryをP/Invokeして使えばいい。

これが、System.Addinを使うと結構手間をかけずに書ける。

フォルダ構造の問題は、ビルド出力先の調整で何とかなるので、あとは同じコードを書く手間を何とかすれば、拡張性があるアプリケーションを構築できるようになる。

＃パイプラインについては、ツールを使えば楽にできるらしいのだが・・・