我找到了一个有关注册DLL的示例,使用Windows Installer XML工具集在MSI文件中为COM互操作注册程序集。,但WiX却抱怨“AssemblyRegisterComInterop”属性。
我删除了该属性并将“Assembly”属性更改为win32,然后它说我需要指定“AssemblyManifest”属性,但我应该在那里放什么?
我找到了一个有关注册DLL的示例,使用Windows Installer XML工具集在MSI文件中为COM互操作注册程序集。,但WiX却抱怨“AssemblyRegisterComInterop”属性。
我删除了该属性并将“Assembly”属性更改为win32,然后它说我需要指定“AssemblyManifest”属性,但我应该在那里放什么?
最简单的方法(Rob M会大声抱怨这是错误的)就是在DLL文件标签上使用SelfRegCost=1
。
这是错误的,因为我们应该明确地控制DLL的注册,而不是允许其通过DllRegisterServer运行任意代码。理论上,当调用DllRegisterServer时,DLL除了将适当的条目放入注册表之外不应该做任何事情。不幸的是,许多DLL不仅仅如此,因此自注册可能是使您的安装程序工作的唯一方法。
这也是错误的,因为这意味着Windows安装系统不知道那些注册表键,以及哪些应该和不应该在那里。这意味着修复操作可能无法正常工作,卸载操作也可能无法正确清理等等。
否则,您可以通过将heat.exe
指向您的DLL来生成适当的WiX代码,并将其输出集成到当前的WiX项目中。您将获得各种Class、ProgID、TypeLib和Registry标记。您可能需要手动编辑该输出以使其编译。
希望这有所帮助。
不仅我会对SelfReg进行抨击和批评,MSI SDK还列出了七个理由告诉你为什么不要使用SelfReg。
例如:
<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>
最终,Troy的回答是完全正确的。
heat.exe file <filename> -out <output wxs file>
eg.
heat.exe file my.dll -out my.wxs
将新的wxs文件中<Component>
标签的内容复制并粘贴到现有的wxs文件中,该文件使用<File>
标签引用您的dll的<Component>
中。删除您粘贴的<File>
标签,并用已经存在的文件Id替换对该文件Id的所有引用;如果现有的文件没有Id属性,请添加它并设置为任何您想要的值。
SelfRegCost=1
的含义没有改变为“通过heat.exe提取内容,然后包含创建的片段”?本质上使其成为几乎是预处理步骤。 - 0xC0000022L