COM Interop 的 WiX 注册程序集
我在 WiX 上真的很挣扎。我要安装需要注册 COM Interop 的 .NET 程序集，并且它们必须向另一个框架注册，该框架需要在 GAC 中的 .NET 程序集中调用 Register() 方法。这种注册方法是一个具有隐藏存储机制的“黑匣子”，因此我无法以声明方式执行此操作。
我知道声明式方法最适合 COM 注册，但使用 heat.exe 时遇到两个问题：
RegAsm 可以工作，但 Heat.exe 在我的程序集中阻塞并显示以下消息：
<块引用>heat.exe：警告 HEAT5151：可能 不从文件中获取数据 预计是一个大会： C:[...].dll。 如果该文件不是程序集 可以忽略这个警告。否则， 此错误详细信息可能有帮助 诊断故障：异常有 被目标抛出 调用。
RegAsm我需要执行的辅助注册依赖于 [ComRegisterFunction] 属性，该属性通常会在为 COM Interop 注册程序集时触发进一步的操作。当程序集由 RegAsm.exe 或通过调用 System.Runtime.InteropServices.RegistrationServices 注册时，通常会发生这种情况。因此，我需要程序集中的 ComRegisterFunction 在安装过程中执行。
我不介意采用声明式方法进行 COM 注册（或者我不介意热量对我的程序集起作用），但我需要在安装过程中调用该 ComRegisterFunction。理想情况下，我想查看我正在安装的所有可执行文件，反思它们是否具有 [ComRegisterFunction] 属性的任何方法并调用这些方法，这将在安装所有文件后完成。
我如何在 WiX 中实现这一目标？或者，还有其他方法吗？如果有什么区别的话，我正在使用“Votive”Visual Studio 与项目引用的集成。
I'm really struggling with WiX. I have .NET assemblies to install that require registration for COM Interop, AND they must be registered with another framework that requires calling a Register() method in a .NET assembly that's in the GAC. This registration method is a 'black box' with a hidden storage mechanism so I can't perform this operation declaratively.
I get that the declaritive approach is best for COM registration, but I have two problems with using heat.exe:
RegAsm works, but Heat.exe chokes on my assembly with the message:
heat.exe : warning HEAT5151 : Could
not harvest data from a file that was
expected to be an assembly:
C:[...].dll.
If this file is not an assembly you
can ignore this warning. Otherwise,
this error detail may be helpful to
diagnose the failure: Exception has
been thrown by the t arget of an
invocation.The secondary registration that I need to do relies on the [ComRegisterFunction] attribute, which normally triggers further actions at the time the assembly is registered for COM Interop. This normally happens when the assembly is registered by RegAsm.exe or by calling System.Runtime.InteropServices.RegistrationServices. So, I need that ComRegisterFunction in my assembly to execute during the installation.
I don't mind taking the declarative approach to COM registration (or I wouldn't mind if heat worked on my assembly) but I need to call that ComRegisterFunction as part of the install. Ideally, I'd like to look at all of the executables I'm installing, reflect on them for any methods with the [ComRegisterFunction] attribute and call those methods, this would be done after all files are installed.
How can I achieve this in WiX? Or, is there another approach? If it makes any difference, I am using the 'Votive' Visual Studio integration with project references.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这些是相反的目标。使用声明式方法的要点是不使用Regasm.exe 或Regsvr32.exe 来调用注册函数。换句话说，您的 [ComRegisterFunction] 属性方法将不会被调用。你不能两者兼得。
heat.exe 死掉的异常是不健康的，它表明您的注册函数或类构造函数有问题。通过将 DLL 设置为启动项目来调试此问题。项目 + 属性，调试选项卡并将 heat.exe 设置为启动程序。将命令行设置为您的 DLL。调试+异常并勾选CLR异常的抛出框，抛出异常时调试器将停止。
哦，不要忘记在注册函数中调用 RegistrationServices.RegisterAssembly。由于您使用了该属性，Regasm.exe 将不再自动执行此操作。
These are opposing goals. The point of using the declarative approach is to not use Regasm.exe or Regsvr32.exe to call the registration function. In other words, your [ComRegisterFunction] attributed method won't be called. You can't have both.
The exception that heat.exe dies on isn't healthy, it indicates that there's something wrong with your registration function or class contructor. Debug this by making your DLL the startup project. Project + Properties, Debug tab and make heat.exe the startup program. Set the command line to your DLL. Debug + Exceptions and tick the Thrown box for CLR exceptions, the debugger will stop when the exception is thrown.
Oh, and don't forget to call RegistrationServices.RegisterAssembly in your register function. Regasm.exe won't do it automatically anymore since you used the attribute.
我将通过声明正确的方法来说明我的答案，正如汉斯所说 - 通过加热。
然而，另一种方法是使用 Component 元素下 File 元素的 SelfRegCost 属性。
下面是我们的一个旧设置套件的示例，迄今为止该套件一直运行没有任何问题。
与任何 SO 答案一样，最好检查这是否适合您的情况并进行彻底测试。
I'll caveat my answer by stating that the correct way to do this is as Hans states - via heat.
An alternative however is to use the SelfRegCost attribute of the File element under a Component element.
Below is an example from one of our older setup kits that's thus far been working with no issues.
As with any SO answer, best to check this works in your situation and test thoroughly.