VBエディタから参照設定で「Windows Script Host Object Model」と、「Microsoft Scripting Runtime」の両方にチェックを入れると、どちらのライブラリにもFileSystemObjectが存在する。
今回はこの2つが同じものなのか、それとも別物なのかを検証してみた。
発端は、いみひとさんのツイート。
WSHとScriptingRuntimeの両方にFSOが有ったから試してみたが、
— いみひと (@nukie_53) 2017年2月3日
問題無く通るということは、示しているものが同じものだとちゃんと認識されているのだろうな#VBA pic.twitter.com/NkEXCXJ3mk
実は私も以前から気にはなってたのだけど、ライブラリが違う以上別物だと思っていた。
Windows Script Host Object Modelの本体はC:\Windows\system32\wshom.ocxである。
一方で、Microsoft Scripting Runtimeの本体はC:\Windows\system32\scrrun.dllである。
まったく同じ機能を備えた、完全な同等品、しかし参照先のバイナリーが違う以上は別物だろうと結論づけていたのだが、相互に代入できるとなってはやはり気になる。
ちなみにこれらのオブジェクトはComponent Object Model(COM)という技術で作成されており、その実態はインターフェースの塊らしい。FileSystemObject型が単なるインターフェースであれば、異なるバイナリーを代入できてもなんら不思議なことではない。
さて、どうしたものかと思ったところで、以前以下の記事でやったファイルを一時的にリネームするという強引な手段を思い出した。
thom.hateblo.jp
そして今回もscrrun.dllをリネームすれば、Scripting.FileSystemObjectが利用できなくなるはず。
それで、実際に試した結果、Scripting.FileSystemObjectに加えてIWshRuntimeLibrary.FileSystemObjectまでもが利用できなくなった。
ということは、WSHのFileSystemObjectは実質scrrun.dllに依存しているということになる。
つまり、この2つのFileSystemObjectは同一ということになる。
WSHを参照設定しているなら、FileSystemObjectを使うためだけにわざわざScriptingを追加で参照設定する必要は無く、IWshRuntimeLibrary内のFileSystemObjectを利用すれば良いということかな。
まぁただ、IWshRuntimeLibrary.FileSystemObjectはなじみが薄いので、私はあえて重複と知ってもScriptingを参照すると思う。。
両方参照している場合、どちらのライブラリのものかはっきりさせるために変数宣言やNewの時にライブラリ名から指定すべきと考えていたが、VBAがどう解釈しようと同じバイナリを指すのだから、これは別にどっちでもいいってことになる。
ちなみにバイナリーってそもそも何？という型はこちら参照。
thom.hateblo.jp
