DLLの登録、WindowsインストーラーXMLツールセットを使用したMSIファイルでのCOM相互運用機能のアセンブリの登録の例を見つけました。、およびWiXは「AssemblyRegisterComInterop」属性について文句を言います。
これを削除して「Assembly」属性をwin32に変更すると、AssemblyManifest属性を指定する必要があると表示されますが、何を配置する必要がありますか?
DLLの登録、WindowsインストーラーXMLツールセットを使用したMSIファイルでのCOM相互運用機能のアセンブリの登録の例を見つけました。、およびWiXは「AssemblyRegisterComInterop」属性について文句を言います。
これを削除して「Assembly」属性をwin32に変更すると、AssemblyManifest属性を指定する必要があると表示されますが、何を配置する必要がありますか?
最も簡単な方法(そしてRob Mは、これがどのように間違っているかについて怒鳴り、絶賛します)は SelfRegCost=1
、DLLのFileタグで使用することです。
これは間違っています。DLLの登録を明示的に制御する必要があり、DllRegisterServerを介して任意のコードを実行することを許可しないためです。DLLは、DllRegisterServerが呼び出されたときに、レジストリに適切なエントリを配置する以外に何もしないという理論です。残念ながら、それらの多くはそれ以上のことを行うため、自己登録がインストールを機能させる唯一の方法である可能性があります。
それはまた、Windowsインストールシステムがそれらのレジストリキーについて何も知らないこと、そしてそこに何があるべきか、何があるべきでないかを知らないことを意味するので、それも間違っています。つまり、修復が機能せず、アンインストールが適切にクリーンアップされない可能性があります。
heat.exe
それ以外の場合は、DLLをポイントし、その出力を現在のWiXプロジェクトに統合することで、適切なWiXコードを生成できます。さまざまなClass、ProgID、TypeLib、およびRegistryタグを取得します。コンパイルするには、その出力を手動で編集する必要がある場合があります。
それがお役に立てば幸いです。
SelfRegがいかに悪であるかについて怒鳴り、絶賛するのは私だけではありません。MSI SDKは、SelfRegを使用しない7つの理由のリストを提供します。
例:
<Component Id="Component" Guid="*">
<File Source="ComServer.dll">
<Class Id="PUT-CLSID-HERE" Context="InprocServer32" ThreadingModel="apartment" Description="Your server description">
<ProgId Id="Your.Server.1" Description="Your ProgId description">
<ProgId Id="Your.Server" Description="Your ProgId description" />
</ProgId>
</Class>
<Class Id="PUT-PROXY-CLSID-HERE" Context="InprocServer32" ThreadingModel="both" Description="Your server Proxies, assuming you have them">
<Interface Id="PUT-INTERFACEID-HERE" Name="IInterface1" />
<Interface Id="PUT-INTERFACEID-HERE" Name="IInterface2" />
<Interface Id="PUT-INTERFACEID-HERE" Name="IInterface3" />
<Interface Id="PUT-INTERFACEID-HERE" Name="IInterface4" />
</Class>
</File>
</Component>
最終的に、トロイの答えはすべて正しいです。
heat.exeプログラムを使用して、wixコードでフラグメントを参照することができます。
heat.exe file <filename> -out <output wxs file>
のように:
heat.exe file my.dll -out my.wxs