2

ほとんどの場合、WiX コンポーネントには常にGuid属性が必要です。そのため、コンポーネントの定義、たとえば iis:WebAppPool および iis:WebVirtualDir (または別のサンプル - アクセス権を持つログ フォルダーをコンテンツとするコンポーネント) を含むコンポーネントをWiX ライブラリ プロジェクトに移動したい場合これらの定義を異なるGUIDで再利用する可能性はありません...私にとっては問題です.異なるGUIDで異な​​るコンポーネントを定義するための定義を共有したいです!

そして、周りに何かをする方法はありません。

次のようなプロパティを介してGUIDをセットアップしようとしました

<Component Name="cmpKuku" Guid="[cmpGUID]" />

しかし、これは機能しません => コンポーネントの GUID はパラメーターを受け入れません。コンポーネントの GUID をパラメータ化する方法は他にもあるのでしょうか? もちろん、プリプロセッサ変数によるパラメータ化は、Wix ライブラリ プロジェクトの場合にも機能しません。

Guid="*" は計算可能ですが、私が理解しているように、親、製品、機能ではなく、コンポーネントのコンテンツのみに依存していますか? 異なる機能/製品で参照する場合、wix が * ... に対して異なる GUID を計算するとよいでしょう。

x) iis:WebVirtualPage と iis:WebAppPool の定義を、フレーム化されたコンポーネントなしで共有する他の方法はありますか?

4

1 に答える 1

4

まったく同じ投稿を読みました。Rob Mensching がそう言っている理由は、wix 固有のものであるため、wixlibs を他のツールで使用できなかったからです。ただし、wixlibs とマージ モジュールは非常に似ています (ただし、wixlibs の方が優れた/高速で新しい選択肢です)。したがって、あなたの質問に答えるには、はい、wixlibs を使用してコンポーネントを含めることができます。これは、上で述べたように、マージ モジュールに似ているためです。基本的に、単一の共有コンポーネントは、その有効期間全体で同じ GUID を持つ必要があり、Windows インストーラーはそれらを追跡する方法を知っています。

たとえば、あるコンポーネントを含む a.wixlib があるとします。次に、同じ wixlib を参照する 2 つの別個のインストーラー b.msi と c.msi を作成し、それらをインストールします。Windows インストーラーは、コンポーネントの参照カウントを 2 に設定します。後で、b.msi をアンインストールすることにしました。Windows インストーラーは、コンポーネントの参照カウントを 1 に減らしますが、まだアンインストールしません。その理由は、共有コンポーネント ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa369820(v=vs.85).aspx ) にマージ モジュールが使用されるのと同じように、wixlibs があるためです。そのため、c.msi をアンインストールすると、コンポーネントのみが削除されます。

もう一つ。guid="*" 属性を配置することで、リンク中に GUID を生成できます。私は一般的に反対ですが、有効です。

編集: アスタリスクについて誤解を招くのを避けるために、アスタリスクを使用することは悪い習慣ではありません。そのため、ビルドに追加の複雑さがなければ、アスタリスクを使用しても問題ない可能性があります。

于 2012-04-22T17:56:54.943 に答える