1

Windows Server 2008 用の製品の .msi パッケージの構成を更新中です。インストールの主なコンポーネントは、Windows サービスとして実行されるアプリケーションです。また、サービスで使用するレジストリ エントリをセットアップするためにインストール中に実行される構成アプリケーションもあります。

サービスと構成アプリケーションは、マージ モジュールとして .msi に含まれている Microsoft C/C++ ランタイムと MFC に依存しています。C/C++ ランタイムと MFC のアセンブリは、InstallFinalize 中にコミットされます。これにより、Windows インストーラーによって提供されるメカニズムを使用したサービスの開始が妨げられているようです (これは正しいですか?)。 InstallFinalize の前に実行される場合は、少なくとも構成アプリケーション。

私たちが採用したアプローチは、InstallFinalize の後に "commit" カスタム アクションとして構成アプリケーションを実行し、このアプリケーションでサービスを開始させることです。これには、昇格された特権でアプリケーションを実行する必要があります (これには、trustInfo セクションを含むマニフェストを使用します)。さらに、このアプリケーションを偽装なしで実行するように .msi を構成する必要があります (そうしないと、特権の昇格が混乱します)。

これは受け入れられるアプローチですか？これはどの程度将来性があるのでしょうか? 注意すべき落とし穴はありますか?

これは他の人が遭遇した問題のようです:

http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg12666.html

このような問題に対処するための公式 (または非公式) の方法はありますか?

これの補足として、インストール プロセス中にカスタム アクションとして実行されるアプリケーションが起動時にフォーカスされるようにする方法はありますか? この方法で開始されたアプリケーションは、常にインストーラーの背後にポップアップ表示され、インストーラーがフォーカスを維持するように見えますが、これは特にユーザー フレンドリーな効果ではありません。

どうもありがとう、

ブルース。

4

2 に答える 2

1

Windows Installer を使用してソフトウェアを再パッケージ化するときに、この種の問題に対して私が使用した解決策は次のとおりです。「ブートストラップ」ランチャーです。つまり、ランタイムにマージ モジュールを使用する代わりに (他のすべてのインストール済みファイルと同時にすべてがコミットされます)、次のいずれかを実行できます。

  1. ランタイム/MFC 用の再配布可能な MSI を提供し、ブートストラップ setup.exe によって最初に起動します。プログラムの MSI はもちろん、必要なバージョンがインストールされていることをテストする必要があります。(この方法は、InstallShield によって一般化されました。これは、Windows インストーラーのエンドランを行うのが好きだからです。)

  2. さらに良いことに、2 つ (またはそれ以上) の組み込み MSI をインストールする親パッケージとして MSI をパッケージ化できます。まず、必要なランタイムをインストールしてから、ソフトウェアを子 MSI にインストールします。親パッケージは、MSI のインストールを続行する前に、ランタイムの MSI が正常にインストールされたことを確認します (前提条件が既に存在するため、サービスを自由に開始できます)。

アーリー コミットのカスタム アクションなど、他にもトリッキーな方法はありますが、今述べた実績のある方法ほど信頼できるものではありません。

それが理にかなっていることを願っています！私はかつてMSIを生きて呼吸していましたが、最近はそうではありません...

于 2009-07-30T21:18:27.123 に答える
0
  1. MFC&C-Runtime の静的な使用をコンパイルできるため、この方法ではそれに依存することはありません。
  2. UI をセットアップに追加すると、これが構成プログラムとして機能するため、セットアップ中に構成プログラムを実行する必要がなくなります (これは良い考えではありません)。
  3. サービスを無効モードでインストールし、セットアップが終了したときに構成を実行できます。構成は、サービスのアクティブ化を担当します。
于 2009-06-04T19:29:34.243 に答える