最近、VB6 アプリケーションのメンテナンスを依頼されました。これには、いくつかのファイル IO が含まれます。Windows スクリプト ホストを参照し、FileSystemObject を使用することによって提供される IO 操作は、VB6 に付属する IO 操作よりもはるかに使いやすいと思います。
しかし、セキュリティ上の問題や、一部のユーザーのコンピューターでスクリプト ホストが無効になるという事実のために、これによって問題が発生するのでしょうか?
更新(2012 年 8 月 20 日): この質問をして以来、3000 人の顧客の間で 3 回、scrrun.dll が機能しないという問題に遭遇しました。これらは、リモート サポートを通じて手動で修正する必要がありました。ウイルススキャナーが原因の場合もあるようです。
Robert Harvey がコメントで述べたように、これは通常、実際には問題になりません。scrrun.dllがインストールされていないか、特定のマシンに正しく登録されていない可能性があります。顧客のマシンに独自の VB6 アプリケーションをインストールするときに、両方のシナリオに遭遇しました。
スクリプトが無効になっていることに関しては、実際に他のアプリケーション (Microsoft InfoPath など) でこの問題に遭遇し、InfoPath フォーム (ファイル I/O を実行する必要がある) を VB6 に呼び出すことで問題を回避しました。 DLL は WSH を使用していたFileSystemObjectので、どちらかといえば、このライブラリを VB6 と組み合わせて使用することで、実際にスクリプトのセキュリティの問題を回避できます。私の知る限り、WSH のセキュリティ設定は実際のスクリプトにのみ適用され、スクリプト ランタイムのコンポーネントをたまたま使用するプログラムには適用されません。
実際、マシン上の Windows Scipt Host を完全に無効にしてFileSystemObjectも、VB6 アプリケーションからなどの WSH コンポーネントにアクセスできます。
VB のファイル IO は、Q/BASIC から継承されているため、常に少し構文上の「奇妙さ」を持っていましたが、直接の読み取り/書き込み (Line Input/Write/Get を回避する) に固執する場合は簡単に使用できます。ネイティブ メソッドを使用すると、FSO よりも高速になり、依存関係の問題を回避できます。
もう 1 つの考慮事項は、バイナリ ファイル IO を実行する場合は、FSO がテキストのみであるため、とにかくネイティブ メソッドを使用する必要があることです。
FileSystemObjectおそらく偏執的な IT 部門が何らかの方法でそれを無効にしたために、動作しない顧客のマシンに時々遭遇しました。私は今、可能であれば避けようとしていFileSystemObjectます。
FileSystemObject通常は、ネイティブ VB6 コードまたは Windows API への直接の API 呼び出しに置き換えることができます。たとえば、Karl E Peterson の優れたVB6 Web サイトには、完全に VB6 で記述された優れたオブジェクトがいくつかあります。
いくつかの例