DLLの登録の例を見つけました、WindowsインストーラーXMLツールセットを使用したMSIファイルでのCOM相互運用機能のアセンブリの登録 、およびWiXは「AssemblyRegisterComInterop」属性について不満を述べています。
それを削除して、「Assembly」属性をwin32に変更しました。AssemblyManifest属性を指定する必要があると表示されていますが、何をそこに置く必要がありますか?
最も簡単な方法(そしてRob Mはこれが間違っているであることについて怒鳴り狂うでしょう)は、DLLのFileタグでSelfRegCost=1
を使用することです。
DLLの登録を明示的に制御する必要があり、DllRegisterServerを介して任意のコードを実行するだけでは許可されないため、これは誤りです。 DLLは、DllRegisterServerが呼び出されたときにレジストリに適切なエントリを置く以外に何もすべきではないという理論です。残念ながら、それらの多くはそれ以上のことを行うので、自己登録はインストールを機能させる唯一の方法。
また、これは間違っています。これは、Windowsインストールシステムがこれらのレジストリキーについて何も認識しておらず、そこにあるべきものとないべきものを認識していないためです。つまり、修復が機能せず、アンインストールが正しくクリーンアップされない可能性があります。
それ以外の場合は、DLLでheat.exe
をポイントし、その出力を現在のWiXプロジェクトに統合することで、適切なWiXコードを生成できます。さまざまなClass、ProgID、TypeLib、およびRegistryタグを取得します。コンパイルするには、その出力を手動で編集する必要がある場合があります。
お役に立てば幸いです。
SelfRegがいかに悪であるかについて怒鳴り、絶賛するのは私だけではありません。 MSI SDKは SelfRegを使用しない理由sevenの理由のリスト を提供します。
例:
<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