System.Addinを使う

| コメント(0) | トラックバック(0)

めずらしく開発ネタですよ。

System.Addin、
.NET Frameworkに用意されている、アプリケーションにアドインとかプラグイン機構を作りこむためのライブラリ。

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

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

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

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

 

全く同じ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を使うと結構手間をかけずに書ける。

 

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

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

トラックバック(0)

トラックバックURL: http://blog.fne.jp/mt/mt-tb.cgi/807

コメントしちゃいなよ

    

サイトカウンタ

Total: 202,617 Hits, (Recent24Hours: 25 Hits)
~ Since 2010/01 ~

埋め込みツイッター

取得失敗;;
Now: 2017/09/21 21:15:02 JST

このブログ記事について

このページは、ふぅみんが2017年4月 4日 13:18に書いたブログ記事です。

ひとつ前のブログ記事は「ちいさいPCをそこそこ活用してみる」です。

次のブログ記事は「70-697 Configuring Windows Devices」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

2017年8月

 日   月   火   水   木   金   土 
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

埋め込みQRコード