Office のマネージド COM アドインの DLL のバージョン番号
は、1.0.0.0 より大きくないといけないらしい。つまり、先頭を「0」にしてはいけないらしい。
これは、つまり、RegAsm で登録する DLL の VersionInfo に書くバージョン番号で、もともとは Visual Studio のプロジェクトのプロパティの Assembly Info... に書くバージョン番号だ。
これを 0.8.0.0 にしたら、Excel が、アドインの初期化を途中で止めて LoadBehavior を 2 に変更しちゃうようになってしまったのだった。(それに気づくのに4時間くらいかかったよ…。)
ウソでした。
バージョン番号だけ変えて試すと、0.X.X.X は全滅で、1.0.0.0 にすると動いたので、上に書いたような秘密の仕様があるのだと思い込んでしまったのですが、そういうことではありませんでした。
(原因不明のトラブルで苦しみ、午前0時ころにやっと動き、その後1時間ほどかけて原因の切り分けをして、ついにわかった、と思ってしまったわけです。一晩寝て、疲れが取れた頭でもう一度考えたら、おかしい気がしたのです。それを検証したら(昨夜はそこまでやらなかった;疲れていたので)やはりダメだったという…。ま、言い訳ですが。)
ということで、あいかわらず未解決なのですが、RegAsmとcodebaseとバージョン番号との関係がうまく行っていない(というか、たぶん私が何かを誤解している)のは間違いなく、Excelは無実だろうと、今は考えています。
と、いうことで、今回の教訓:「トラブルシュートが深夜まで長引いて、やっとうごいて『これで解決』と思っても、すぐブログに書かず、一晩寝て頭を冷やして翌日もう一回よく考えよう。」
追記
本件は、結局、アセンブリのバージョンが1.0.0.0以外の値だとRegAsmしたときに変なcodebaseレジストリエントリが作られてしまうというNetOfficeのバグに、私のテスト手順が悪かったことが複合したことによる謎動作だった、というのが、私の結論です。Excelは無実だと今は確信しています。
« 自作のXmlWriterをXslCompiledTransformにわたす | トップページ | 意味のわからないウェブの記載 »
« 自作のXmlWriterをXslCompiledTransformにわたす | トップページ | 意味のわからないウェブの記載 »


コメント