2

WiX 3.7 を使用してインストーラーを作成しています。インストーラーは古い VB6 プログラムをインストールします (これはソース コードを持っていないベンダー独自のプログラムです)。そのため、このプログラムは、最新バージョンの Windows (たとえば、Windows 7 以降。Vista または XP については不明) ではインストールされていない古い COM ライブラリを使用します。

私は最近、COM ライブラリをグローバル システム登録なしで、レジストリ フリーの COM 登録を使用して非公開でインストールできることを知ったので、Windows OS で配布されなくなった COM ライブラリに対して、まさにこれを行うつもりです。

そのために、ライブラリが読み込まれ、アプリケーションによって使用されるときに、すべての COM 登録情報を検索するために使用される必要なマニフェスト ファイルを作成しました。これらのライブラリの MSI コンポーネントを作成しました。これら 2 つのライブラリに関連する WiX マークアップは次のとおりです (コンポーネントの GUID を削除したので、誰も独自のインストーラー用にそれらをコピーしません)。

<Component Id="C__MsComm32.ocx" Guid="PUT-YOUR-GUID-HERE" DiskId="1">
  <File Id="F__MsComm32.ocx" Vital="yes" KeyPath="yes"
        Assembly="win32"
        AssemblyApplication="F__MyApp.exe"
        AssemblyManifest="F__MsComm32.sxs.manifest"
        Name="mscomm32.ocx" Source="[to be filled in]" />
  <File Id="F__MsComm32.sxs.manifest" Vital="yes" KeyPath="no"
        Name="mscomm32.sxs.manifest" Source="[to be filled in]" />
</Component>
<Component Id="C__threed32.ocx" Guid="PUT-YOUR-GUID-HERE" DiskId="1">
  <File Id="F__threed32.ocx" Vital="yes" KeyPath="yes"
        Assembly="win32"
        AssemblyApplication="F__MyApp.exe"
        AssemblyManifest="F__threed32.sxs.manifest"
        Name="threed32.ocx" Source="[to be filled in]"  />
  <File Id="F__threed32.sxs.manifest" Vital="yes" KeyPath="no"
        Name="threed32.sxs.manifest" Source="[to be filled in]" />
</Component>

MyApp.exe.manifestこれらすべてが機能するためには、このアプリケーションがどのアセンブリに依存しているかを OS に伝える、アプリケーション実行可能ファイルのマニフェスト ファイルも提供する必要があります。そのため、必要なマニフェスト ファイルも作成しました。ここで、アプリケーションとそのマニフェストをデプロイするためのコンポーネント (または複数のコンポーネント) を作成する必要があります。

のVSインテリセンスによるとFile/@Assembly：

このファイルが、グローバル アセンブリ キャッシュ (GAC) にインストールする必要がある Win32 アセンブリまたは .NET アセンブリであるかどうかを指定します。値が「.net」または「win32」の場合、このファイルはコンポーネントのキー パスでもある必要があります。

そして、次の場合File/@AssemblyManifest:

アセンブリを記述するマニフェスト ファイルのファイル識別子を指定します。マニフェストは、それが記述するアセンブリと同じ Component にある必要があります。この属性は、Assembly 属性が「.net」または「win32」に設定されている場合にのみ指定できます。

それはそれでいいことです。私はそのすべてを完全に理解しています。したがって、WiX のアプリケーションのFile要素については、これまでのところ次のようになっています。

<File Id="F__MyApp.exe" Vital="yes" KeyPath="yes"
      Assembly="win32"
      AssemblyManifest="F__MyApp.exe.manifest" />

今、私が理解していないのは、File/@AssemblyApplication属性のインテリセンスです:

アプリケーション ファイルの識別子を指定します。このアセンブリは、アプリケーション ファイルと同じディレクトリに分離されます。この属性がない場合、アセンブリはグローバル アセンブリ キャッシュ (GAC) にインストールされます。

明らかに、アプリケーションを GAC にインストールしたくありません (そして、に設定File/@Assemblyしたので、そうすべきではないと思いますwin32)。問題は、属性値がその親要素の属性を指すことができるかどうかです。File/@AssemblyApplication@Id例えば：

<Component Id="C__MyApp.exe" Guid="PUT-YOUR-GUID-HERE" DiskId="1">
    <File Id="F__MyApp.exe" Vital="yes" KeyPath="yes"
          Assembly="win32"
          AssemblyManifest="F__MyApp.exe.manifest"
          AssemblyApplication="F__MyApp.exe" />
    <!-- @AssemblyApplication references it's parent element's @Id attribute. -->
    <File Id="F__MyApp.exe.manifest" Vital="yes" KeyPath="no"
          Name="MyApp.exe.manifest" Source="[to be filled in]" />
</Component>

Componentこれは、アプリケーション マニフェストを含むアプリケーションの要素を作成する正しい方法ですか? Assembly*それとも、さまざまな属性の設定を忘れて、 2 つComponentの を作成する必要がありますか? 1 つはアプリケーションの実行可能ファイル用、もう 1 つはそのマニフェスト用です。

4

1 に答える 1