私たちのVB6アプリケーションは、scrrun.dll（Windows Scripting Host）の使用に大きく依存しています。1年前まで、インストーラーを使用してこのdllをデプロイしていました。Windows ScripitngホストはWindowsの一部であると想定されているため、インストールパッケージからdllを削除しました。ただし、システムに機能していないscrrun.dllを使用しているお客様は、再インストールまたは再登録を支援する必要があります。
では、scrrun.dllをインストールパッケージに戻す必要がありますか？インストールのチェックを行う必要がありますか？それとも、システムを正しく設定するために、一部のお客様に実践的なサポートを提供する必要があるという事実を受け入れる必要がありますか？
通常のセットアップの一部としてこれらのライブラリを展開しようとしないでください。
Microsoft Scripting Runtimeは、自己解凍型の.exeファイルを使用してインストールする必要があります。この記事の冒頭で述べたスクリプトランタイムのバージョンの場合、それを配布する唯一の方法は、次の場所にある完全な自己解凍型.exeファイルを使用することです...
一部のユーザーが古いマルウェア対策スイートを使用している可能性があり、その多くはスクリプトを無効にしようとしました。一部のユーザーは、自分自身で、または不適切にパッケージ化されたアプリケーションを使用してこれらのライブラリを含めようとし、アンインストール時にシステムから盲目的に削除することで、Windowsのインストールを中断した可能性があります（cough、cough-Inno）。
関連するライブラリは、しばらくの間、コードを調整してきました。これが、古代の.CABファイルがずっと前に「リコール」された理由です。ランダムなバージョンのWindowsで実行することを目的としたそれらの単一のコピーはなく、最新バージョンのWindows用のredistパックもありません。正しい修正は、システムの復元または修復インストールです。
これは、作成が不十分なスクリプトの結果であるため、InnoSetupで直接非難することはできませんが、マルウェア対策スイートに署名が追加されたときに泣かないほどイライラし、一般的です。あまりにも多くの人々によって野生のコピー/貼り付けされた、あまりにも多くの不十分に書かれた例が緩んでいます。
私はこれらのアプリケーションのアンインストールによって引き起こされたダメージを元に戻すのに多くの時間を費やし、それにかなりうんざりしてきました。可能であれば、私は現在、護身術で隔離されたアセンブリを使用しています。これは非常に役立ちます。 Windowsファイル保護は、システムファイルに対する不正なアクションの防止についても改善されています。
ただし、一般的には、アプリケーションのスクリプトツールへの依存を回避する方がはるかに優れています。とにかくストレートコードほどできることはあまりありませんが、代替ロジックを書くのに時間がかかるかもしれません。