3

私は純粋な InstallScript プロジェクトを持っていますが、この問題が原因で問題が発生することが判明しました。これは、新しいファイルがインストールされる前に特定のディレクトリを消去する InstallScript を追加することで一時的に解決されましたが、これは理想的ではありません。ただし、この一連のフォーラム投稿は、InstallScript MSI プロジェクトまたは基本の MSI プロジェクトが、アップグレード時に動的にリンクされたファイルの削除を大幅に簡素化することを示しています。

Flexara フォーラムを検索すると、InstallScript MSI プロジェクト タイプに反対する投稿がたくさんあるので、基本の MSI を調べています。Flexara には、 InstallScript プロジェクトを Basic MSI に変換できる Repackager という製品があるようです。ただし、IS Premier または Admin Studio しか付属していないため、多少の費用がかかります。その道を進む前に、これが機能する可能性が高いという兆候が必要です。

  • Repackager ツールを使用して InstallScript から Basic MSI に変換すると、機能が失われる可能性はありますか? スクリプトには、インストールのいくつかのステップで情報を渡すこのようなものを含め、かなりのロジックがあります。また、IS2010 とは別にインストールする必要があったレガシー オブジェクトである InstallShield NT サービス オブジェクトもいくつか使用しています。Repackager が処理しないことが知られている InstallScript プロジェクトの側面はありますか?
  • Repackager がプロジェクトを魔法のように変換しない場合、手動で変換を行うために従うことができるガイドはどこかにありますか? 私は、InstallShield のドキュメントとフォーラムがかなり不足していることに気づきました。
  • 古い (純粋な InstallScript) バージョンがインストールされているシステムで、結果として得られる基本の MSI インストール パッケージでアップグレード インストールを実行できる方法はありますか? これは本当にボーナスになります。この時点で、完全なアンインストール/再インストールを強制されることになると思います。
4

2 に答える 2

3

クリストファーが言及しているのと同じ理由で、リパッケージャーソリューションはお勧めしません。

InstallScriptプロジェクトと新しいBasicMSIプロジェクトの間の適切な橋渡しは、InstallScriptカスタムアクションを使用する新しいBasicMSIプロジェクトを作成することです。このアプローチでは、MSIエンジンがインストールの非独占的な側面を管理し、レガシーのInstallScriptコードを再利用してインストールの独占的な側面を管理できます。

これにより、両方の長所が得られます。完全に制御できる堅牢なBasic MSIパッケージ（リパッケージャーによって自動生成されなかったため）に加えて、InstallScript関数を最初から再実装する必要がないため時間の節約になります。

于 2011-03-04T15:35:03.597 に答える
3

リパッケージャーはせいぜい、インストールのビジネス ルールの 1 つのインスタンスしか取得できません。インストールを単純に「変換」することはできませんが、再設計する必要があります。理想的には、MSI の専門家に InstallScript プロジェクトをレビューしてもらい、MSI のベスト プラクティスへのリファクタリングによって排除できる部分を特定し、残りの部分を MSI のシーケンス テーブルに合うように書き直します。

古いアンインストールが適切に動作する場合は、それを削除するカスタム アクションを作成できます。これは、潜在的なファイル コストの問題を排除するため、新しい製品を新しいインストール ディレクトリに移動する場合に最も簡単です。これが不可能である場合、および/または古いインストールに適切に動作するアンインストールがない場合、これはより複雑になります。

また、古いインストール コンテキストから新しいコンテキストに永続化したい構成データがある場合は、さらに複雑になる可能性があります。

私は何年にもわたってこれらの多くを行ってきましたが、非常に困難な場合もありますが、途中で多くのゴミを片付けることができるので、やりがいもあります.

于 2011-03-03T23:33:49.960 に答える