MSDNマガジンが日本語で読めるようになったってんで見に行ってみたら、なんと、シェル拡張コンポーネントをマネージコードで書くような話が載っているじゃないですか。
これは読まずにはいられないわけでして。
ところが、読み進めてみると意外な一文が。
【マイクロソフトとしては、最終的に、シェルのアドインをマネージ コードで実装しないことを強くお勧めします。
】
な、なんですと！？
当ブログの存在意義が根底から揺るがされるようなことが…
これは、以下のような理由があるためだそうです。
- アドインはインプロセスでシェル (explorer.exe) に読み込まれる
- 特定のプロセスに読み込める共通言語ランタイム (CLR) のバージョンは 1 つだけ
- あるバージョンのランタイムを対象に作成されたマネージ コードが、以前のバージョンのランタイムを実行するプロセスでは実行されない可能性がある
要するに、.NET Framework 1.1と2.0を対象として作られたシェル拡張コンポーネントが同じマシンにインストールされていた場合、1.1の方が先に読み込まれてしまうと、2.0のCLRはロードされず、2.0対象のアドインを1.1のエンジンで動かそうとするためうまく行かない、ということだそうです。
しかし、解決策が無いわけではありません。
いや、根本的な解決策は無いのですが、少なくとも俺がこの問題を逃れる方法はあります。
要は簡単。当サイトでは、.NET 2.0を対象としたコンポーネントのみを公開すればよい。それだけです。
もとより、今からわざわざVisualStudio .NET 2003を用いての開発なんかやるつもりはありませんし、シェル拡張コンポーネントではWPFやWCFのような、.NET 3.0からの新機能なんて縁がありません。
第一、対象言語としているC++/CLIでは.NET 3.0開発がサポートされていないので、3.0用のシェル拡張ライブラリなど作りようがありません。
なにより、たとえ.NET 3.0の機能を利用したコンポーネントを公開したとしても、前述したような1.1と2.0の競合問題は起こりません。3.0のコア部分は2.0と全く同じなので、3.0から新たに追加されたライブラリさえインストールされていれば、2.0のCLRをロードしたプロセスで、3.0のアセンブリは問題なく動くからです。