とりあえず簡単に。
ちゃんとしたのはそのうち気が向いたら書くかも。
でも既存開発者はわかってる人たちだからこれでも十分な気が……
新規開発も追々。
むしろちゃんと書くべきはこっち。。
KanColleViewer 4.0
KanColleViewer 4.0 がリリースされましたが、プラグインシステムが刷新されたため、3.x のプラグインは利用できなくなりました。
Release version 4.0 · Grabacr07/KanColleViewer
プラグイン システムの刷新 (version 3.8.2 またはそれ以前に向けて作られたプラグインは使用できなくなります)
というわけで、3.x プラグインをどう移行すればいいかを 雑に 簡単に説明します。
実際のコードは、本体に付属しているプラグインの実装などを参考にすると良いでしょう。
1. 古いアセンブリ参照を消す
古い KanColleWrapper や KanColleViewer に加え、本体で使わなくなった FiddlerCore への参照を削除しましょう。
2. NuGet Gallery からプラグイン開発用アセンブリを取得
「NuGet パッケージの管理」を kancolle で検索し、必要なアセンブリを取得しましょう。
パッケージソースはv3じゃないとダメかも？
全部入れてもいいんですが、必要なやつだけでもOKです。
| Package | Description |
|---|---|
| KanColleWrapper | KanColleViewer の通信部とデータ部です。 本体が保持するデータへのアクセスや、通信の読み取りに利用します。 |
| KanColleViewer.Composition | 必須。 プラグイン向けのインターフェイス郡です。 これがないとプラグインが作れません。 |
| KanColleViewer.PluginAnalyzer | 推奨。 プラグイン開発を支援する Roslyn Analyzer です。(要: VS 2015) 必要な実装方法や修正候補を提示してくれます。 |
| KanColleViewer.Controls | KanColleViewer のUI部品です。Style, Theme も含みますので、UI があるプラグインなら参照したほうが良いでしょう。 |
また、設定等を保存したい場合などは MetroTrilithon が便利です。
これも本体(exe)が導入していますので、プラグイン側でも普通に使って問題ないでしょう。
便利な Control や Converter も含みます。
設定については SerializableProperty と ISerializationProvider を用いれば簡単に保存できるようになります。
実際の実装方法は Grabacr07.KanColleViewer.Models.Settings あたりを参考にしましょう。
CallMethodButton なんかもよく使われてた気がしますが、それもこの中です。
3. プラグイン インターフェイスの実装を修正する
実装すべき内容が変更されていますので、修正します。
基本的には
- 実装している interface を変更する
Export、ExportMetadata属性を修正/追加する
の2点です。
Interface
| Interface | Description |
|---|---|
| IPlugin | 必須。 プラグインを表します。 |
| ITool | [ツール] タブに表示される画面を用意したい場合に実装します。 |
| ISettings | プラグインの設定画面を用意したい場合に実装します。 |
| INotifier | 通知要求を受けて、ユーザーに通知を行いたい場合に実装します。 |
| IRequestNotify | プラグイン側から本体に通知を要求したい場合に実装します。 |
Export, ExportMetadata
この項については、基本的には KanColleViewer.PluginAnalyzer を入れていればそれが全部指摘してくれます。
- プラグイン インターフェイスを実装したら、対応する
Exportを記述しなければならなりません。 IPluginインターフェイスを実装したクラスは、ExportMetadataのGuid,Title,Description,Version,Authorを記述しなければなりません。- その他のプラグイン インターフェイスを実装したクラスは、
ExportMetadataのGuidを記述しなければなりません。 ExportMetadataのGuidが同一なクラスは、同一プラグインとみなされます。- つまりもし機能別にクラスを分割した場合、機能側のクラスには、機能を付与したい
IPluginのクラスのGuidと同じGuidを記述する必要があります。 - 逆に1クラスに全て集約する場合は
GuidのExportMetadataの記述は1つで済みます。
- つまりもし機能別にクラスを分割した場合、機能側のクラスには、機能を付与したい
4. ビルド
基本的にはこれだけで動くようになるはずです。
ただし、KanColleViewer.exe に強く依存しているプラグインについては、これだけでは動作しない可能性はあります。
引き続き exe を参照することも不可能ではありませんが、本体の更新により動かなくなるリスクが通常よりかなり高くなってしまうため、お勧めはしません。
また FiddlerCore は Nekoxy に置き換えられているため、KanColleProxy を使って通信を独自に読み取っている場合などは若干の修正が必要です(APIはかなり近いですが、プロパティの位置などが少々異なります)。