問題タブ [wix3]

Wix v3.0 (要するに MSI インストーラー) を使用しており、Excel 2003 がインストールされていることを確認する条件を作成しようとしています。マシン上に Excel 2003 が存在することを検出する最良の (最も堅牢な) 方法は何ですか?

さまざまな提案を見てきましたが、決定的または信頼できる答えはありません。

Feature Tree UI を備えた Wix3 ベータ版を使用しています。いくつかのアセンブリを別々のコンポーネントとして、ProgramFiles 内のカスタム サブディレクトリと GAC にインストールしています。さらに、同じアセンブリの DEBUG バージョンを 1 つのコンポーネントとしてパッケージ化し、それらをインストールするかどうかをユーザーが決定できるようにしたいと考えています。現在、デバッグ アセンブリを使用したこの機能はデフォルトで無効になっていますが、デバッグ アセンブリは関係なくインストールされます。

関連するスニペットの下:

奇妙なことに、msi ファイルを再度実行して [変更] に移動し、デバッグ機能を無効にすると、デバッグ アセンブリが削除されます。たとえば、今度はロジックが正常に動作します。

デフォルトの INSTALLLEVEL は 3 です。

助言がありますか？

WiX バージョン 3 を使用した MSI ビルドがあります。

展開している製品の以前のインストーラーはすべて、指定された構成で正常に機能しました (つまり、以前のバージョンが存在する場合は、削除してから新しいバージョンをインストールします) - ただし、ビルドした新しい MSI は、実行時にすべてのファイルをインストールしません。 「最初に削除」パス。

既存のインストールを手動で削除してから新しいバージョンを実行すると、すべてのファイルがインストールされます。Orca で MSI ファイルを調べると、ファイルと機能が表示され、問題ないようです。

詳細ログと追加ログをオンにして実行してみましたが ( /l*vx)、ファイルが登録されていないか、インストールされていないかを確認できます。

何か考えや提案はありますか？これは私たちを壁に押し上げています。

私たちのビルド プロセスでは、現在、コード ベースではないファイル (イメージ ファイルなど) が Web プロジェクトに追加される可能性がありますが、WiX によってビルドされた MSI インストーラーには含まれません。

これを防ぐために、WiX プロジェクトの AfterBuild ターゲットで次のことを実行します。

• ビルドされたすべてのファイルの数を取得します (Web 配置プロジェクトからの出力)
• MSI に組み込まれているすべてのファイルの数を取得します (MSI の「ファイル」テーブルから)
• カウントを比較し、一致しない場合はビルドに失敗します

Orca を起動すると、ファイル テーブルとカウントを簡単に確認できますが、MSBuild からこれを自動化する方法がわかりません。この情報を MSI から取得するための API またはその他のメカニズムはありますか?

MSI ファイル テーブル カウントを抽出するために、カスタム MSBuild タスクを作成してもかまいません。

ここでSiによるこの質問の精神で：WiXのトリックとヒント。ディレクトリに基づいて wix フラグメントを作成する最良の方法を決定しようとしています。いわばファイルハーベスティング。たとえば、bin\release フォルダーの下に、さまざまなフォルダーと、フラグメントで非常に簡単にキャプチャしたいファイルを含めることができます。私はそれらを入力するか、wixeditを使用してこれを行ってきました。

ここでリサーチを行っただけで、何も試していないことに注意してください: A )熱について少し読みました。msbuildから実行することについてはわかりませんか? B）t4スクリプトの使用について説明しているNewagesolutionのこのブログ記事を見つけました：http://blog.newagesolution.net/2008/06/how-to-use-msbuild-and-wix-to-msi.html

これを解決するために他の人が何をしているのか知りたいです。

よろしく、ブライアン

FeatureTree/SelectionTree のアプリケーションのインストーラーの構造は次のとおりです

アプリケーション コア
    |_ _ 機能 1
    |_ _ 機能 2
    |_ _ 機能 3

ユーザーがアプリケーション コアを選択するときに、機能 1、機能 2、または機能 3 の少なくとも 1 つを選択する必要があることを確認します。

機能の下の条件要素が役立つことは知っていますが、それを機能させることができませんでした。救助に来た人はいますか?

(Wix 3.0.4805.0 以降) を使用しheatて、Visual Studio によって生成された typelib から Wix ドキュメントを生成すると、エラーが発生します。次のようなウィンドウが表示されます。

「heat.exe - 悪いイメージ」

アプリケーションまたは DLL c:\path\to\file.tlb は有効な Windows イメージではありません。これをインストール ディスクと照らし合わせて確認してください。

しかし、「OK」を押した後、続行し、正常に生成されます

Wixバグボードのこのバグ レポートには、私のリリースより前のリリースで修正されたと書かれているようですが、修正されていないようです。彼らは、エラーが発生するのは、最初にそれを DLL としてロードしようとする (失敗する) ためだと言いますが、その後、正しいことを続けます。

これは、Windows XP SP3 で発生しています。

これに対する回避策を知っている人はいますか？

私は私たちの製品の新機能に取り組んでいます。そのコンポーネントにはかなり大きなセキュリティ上の影響があります。それはWCFサービスとして実行され、いくつかの非常に特権的なアクションを実行します。そのため、そのコンポーネントは、ユーザーが必要とする場合にのみインストールし（必要がなくなった場合は削除し）、プログラムでインストールできるようにしたいと思います。

私は広告（具体的には、割り当てられたインストール）を調べましたが、これを達成するための優れたメカニズムのようです。 アドバタイズされた機能のインストールを元に戻すことができるかどうかはわかりませんが、コンポーネントが不要になったときにコンポーネントを削除するのに役立ちます。また、プログラムによるインストールがアドバタイズで達成できるかどうかも完全にはわかりません。アドバタイズされたCOMクラスは推奨されていないようです。

したがって、コンポーネントをインストール/削除するためにmsiexecを呼び出すだけの方が賢明かどうか疑問に思います。コンポーネントは、別のMSIにパッケージ化することも、メインのMSIの別の機能としてパッケージ化することもできます。

オンデマンドで機能をインストールするためにどのような手法を使用しましたか？

特定のアセンブリがGACにあるかどうかをWiX 3で（できれば条件を介して）検出したいと思います。上記のアセンブリの名前、バージョン、および公開キー トークンを知っています。これを行うための組み込みの方法はありますか、それとも CustomAction を作成する必要がありますか? そして、その CustomAction を設定するにはどうすればよいでしょうか? (これは、インストールが開始される前になります。)