使用Wix Msi安装程序在安装后将CPP dll注册到COM中 [英] Registering a CPP dll into COM after installation using Wix Msi installer
问题描述
我正在尝试在Msi安装过程中将CPP库注册到COM中。
我在这里进行了大量搜索并找到了很多解决方案，但是没有任何解决方案我的代码。我不知道有没有直接的方法。我尝试将Custom Action与直接ExeCommand和批处理脚本一起使用。
这是带有批处理脚本的代码。
< SetProperty Id = Register Value =& quot; [INSTALLDIR] Scripts\Register.bat& quot; After = CostFinalize />
< CustomAction Id = Register BinaryKey = WixCA DllEntry = CAQuietExec Execute = deferred Return = check Impersonate = no />
< SetProperty Id =取消注册 Value =& quot; [INSTALLDIR] Scripts\UnRegister.bat" After = CostFinalize />
< CustomAction Id =取消注册 BinaryKey = WixCA DllEntry = CAQuietExec Execute =递延 Return =检查 Impersonate =否 />
使用此代码，安装不会显示任何错误，但dll未得到注册。安装后，如果我单独运行批处理脚本，则将其注册。
Register.bat
cd C：\Windows\System32
regsvr32 C：\Program Files（x86）\ABC\Abc.dll
ping -n 15 127.0.0.1> nul：
Unregister.bat
cd C：\Windows\System32
regsvr32 / u C：\Program文件（x86）\ABC\Abc.dll
ping -n 15 127.0.0.1> nul：
使用带有ExeCommand的自定义操作，它会显示错误，例如缺少某些dll依赖项。
ExeCommand代码如下。
< CustomAction Id = Register Directory = INSTALLDIR Execute =推迟 Impersonate = no
ExeCommand = [WindowsFolder] System32\regsvr32& quot; [INSTALLDIR] Abc.dll"返回= check />
< CustomAction Id =取消注册目录= INSTALLDIR Execute =递延 Impersonate = no
ExeCommand = [WindowsFolder] System32\regsvr32 / u& quot; [INSTALLDIR] Abc.dll&返回= check />
这两种情况的InstallSequence如下。
< InstallExecuteSequence>
< Custom Action = Register Before = InstallFinalize>未安装< / Custom>
< Custom Action =取消注册 Before = RemoveFiles>已安装且未升级PRODUCTCODE< / Custom>
< / InstallExecuteSequence>
在两种情况下，我都认为它以提升的特权运行。
这是我大部分时间遇到的错误。
编辑
DLL的依赖遍历视图如下所示。
我还要添加我使用的加热命令。我已将此添加到prebuild事件中以生成组件。之后，将此组件添加到产品文件中。
调用 $（WIX）bin\heat.exe文件 dllPath\Abc.dll -dr安装目录 -srd -gg -sfrag -suid -out $（SolutionDir）Installer\ComRegisterComponent.wxs
生成的文件如下所示。
< Fragment>
< DirectoryRef Id = INSTALLDIR>
< Component Id = Abc.dll Guid = *>
< File Id = Abc.dll KeyPath = yes Source = SourceDir\Abc.dll />
< / Component>
< / DirectoryRef>
< / Fragment>
这里的SourceDir路径使我感到困惑。我已经在heat命令中添加了确切的路径，即使它生成
简短摘要答案
您需要停止使用批处理文件和自定义操作进行COM注册（不可靠），而是使用 heat.exe 工具从WiX中提取COM注册信息。在编译时将COM注册添加到MSI数据库的工具包。
64位二进制文件有些复杂，请参见下面的详细信息。幸运的是，您似乎正在根据上面显示的安装目录来处理32位组件。
在这种情况下，它有助于散热。当所有依赖项都就位后，COM文件就可以在COM文件上正常运行。这些答案中有很多调试通讯-我将在未来保留所有这些，但请首先尝试使用此简单的解决方案。也许可以尝试使用下面描述的新依赖工具 Dependencies.exe。
详细的详细回答
在我尝试回答问题之前（这似乎与缺少依赖项或在批处理文件中完成的操作很奇怪有关），关于COM注册的最佳做法，我想为您澄清一些事情。
注意：屏幕快照似乎表明您的批处理文件中发生了一些奇怪的事情，但是缺少依存关系仍然可能是一个问题。
已考虑自我注册有害
不应使用自我注册来注册COM文件。以下是这种情况的说明：
您很可能会在dll（或任何文件类型，例如OCX）中发现类似的错误从安装程序的安装位置运行。 regsvr32.exe无法找到所需的依赖文件，并且注册过程失败。
有些已报告的丢失依赖项并不重要 -我想这与Dependency Walker工具的年代有关-据我所知，它最近还没有更新。查找一个您识别为您自己的依赖文件或核心系统文件的文件，而不是您从未听说过的文件的非常长的dll名称。请记住，某些dll具有加载所需的依赖语言dll。例如，MMUtilities.dll需要MmUtilitiesEnglish.dll或同一文件夹中存在的其他语言dll才能正确加载。
一些样本误报依赖项>： API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL ， API-MS-WIN- CORE-PROCESSTHREADS-L1-1-0.DLL ， API-MS-WIN-CORE-REGISTRY-L1-1-0.DLL ，等等...有很多。我相信，但我不确定，这些误报的根本原因在于与WinSxS文件夹中安装的并行组件有关的问题，但这是另一个完整的讨论-仅提及它。
更新：我再次进行了检查，上面看到的大多数误报依赖项显然是API设置 -Dependency Walker创建后很久才引入的Windows功能，因此该工具无法正确处理
正如链接的答案所指示（请阅读，在上面的链接），现在还用用C＃重写了Dependency Walker， 依赖关系，可在此处找到： https://github.com/lucasg/Dependencies（在撰写本文时未经我的试用，将很快进行测试）。
注意：如果您要检查可执行文件（而不是dll，ocx等），则可以通过 Profile =>启动它。开始分析... 菜单项，然后您还将看到 隐藏的运行时依赖项 未在二进制导入表（指定了依赖项/导入项）中指定。您需要真正使用所有对话框中的所有功能来锻炼应用程序，以确保获得所有此类依赖项。
依赖项浏览器网页将这些隐藏的依赖项称为显式依赖项（动态或运行时依赖项）和系统挂钩依赖项（注入的依赖项）。有关更多详细信息，请参见上面的链接。
Heat.exe提取
一旦确定了哪些文件由于缺少使WiX heat.exe提取工作的功能，您可以将有问题的文件放在COM dll的旁边，以便在加载过程中找到它们。您可以使用regsvr32.exe测试运行，以查看注册是否正确完成。像这样手动运行注册时，应该没有错误消息。 记住要从提升权限的命令提示符下运行注册。
其他一些stackoverflow答案也说明了如何使用heat.exe-我没有使用过长期以来：如何运行热量。 exe并在wix中注册一个dll 。这是WiX员工自己的 heat.exe的官方文档 。它可能是一个有点令人生畏的工具-它具有许多功能。
以其最简单的形式（适用于在路径或路径中具有所有依赖项的普通32位COM文件。本地文件夹），您可以运行heat.exe命令行以生成名为 YourFileName.wxs 的输出WiX源文件，其中包含所有必需的COM注册表数据。
heat.exe文件YourFileName.ocx -o YourFileName.wxs
几年前我写了一个答案，展示了如何将导出的WiX注册表数据合并到您的主要WiX来源中：如何在Wix（命令行）中引用热量输出（wxs）。我相信这是对过程的准确描述，但是由于某些原因，有人拒绝了答案。
重要！：heat.exe不起作用。
仍能正确处理64位COM二进制文件（2017年12月）。
我被告知WiX扩展包（不是免费的）来处理64位二进制文件并提供其他一些功能。
我想可以链接到它（我不隶属于FireGiant）： https://www.firegiant.com/wix/wep-documentation/harvesting/ 。人们需要某种方式来了解这些事情，但是我不确定链接的stackoverflow礼节。
您的二进制文件是64位吗？ >（从您的安装文件夹中看起来不是那样，但是我为可能会发现它的其他人添加了它）。对于64位组件，我想我们已经全面了解了，建议您使用上述扩展包功能，或者只是尝试按照此处所述将文件设置为自注册。我讨厌这种自动注册的解决方案，但目前还没有其他快速解决方案（无论如何我都不会推荐）。我会再检查一次。 在进行此自我注册修复之前，请确保检查最新的WiX版本以查看64位问题是否已解决。至少比尝试使用自定义操作和批处理文件进行注册更好（永远不要尝试-如此之多与MSI复杂的自定义操作排序，模拟/提升，调节，具有静默和交互功能的安装模式有关的潜在问题，而不是提及来自安全软件的潜在干扰，列表还会继续。）
某些链接：
- 如何在WiX 3中注册Win32 COM DLL文件？
- 无法使用WiX注册DLL
- 使用wix执行REGSVR32的功能
- Heat.exe无法从64位COM DLL中获取TypeLib信息
- Heat.exe：64位.dll无法转换为64位.msi
I am trying to register a CPP library into COM during the Msi installation.
I have searched a lot and found many solutions in here, but nothing is working in my code. I don't know is there any direct method for this. I have tried using Custom Action with direct ExeCommand and with a batch script.
Here is the code with batch script.
<SetProperty Id="Register" Value=""[INSTALLDIR]Scripts\Register.bat"" After="CostFinalize"/>
<CustomAction Id="Register" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="no"/>
<SetProperty Id="Unregister" Value=""[INSTALLDIR]Scripts\UnRegister.bat"" After="CostFinalize"/>
<CustomAction Id="Unregister" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="no"/>
Using this code, installation does not show any error, but dll is not getting registered. After installation if I ran the batch script separately then it gets registered.
Register.bat
cd "C:\Windows\System32"
regsvr32 "C:\Program Files (x86)\ABC\Abc.dll"
ping -n 15 127.0.0.1 >nul:
Unregister.bat
cd "C:\Windows\System32"
regsvr32 /u "C:\Program Files (x86)\ABC\Abc.dll"
ping -n 15 127.0.0.1 >nul:
With Custom Action with ExeCommand it shows error like some dll dependency missing. ExeCommand code is given below.
<CustomAction Id="Register" Directory="INSTALLDIR" Execute="deferred" Impersonate="no"
ExeCommand="[WindowsFolder]System32\regsvr32 "[INSTALLDIR]Abc.dll"" Return="check" />
<CustomAction Id="Unregister" Directory="INSTALLDIR" Execute="deferred" Impersonate="no"
ExeCommand="[WindowsFolder]System32\regsvr32 /u "[INSTALLDIR]Abc.dll"" Return="check" />
And InstallSequencefor both the cases is given below.
<InstallExecuteSequence>
<Custom Action="Register" Before="InstallFinalize" >NOT Installed</Custom>
<Custom Action="Unregister" Before="RemoveFiles">Installed AND NOT UPGRADINGPRODUCTCODE</Custom>
</InstallExecuteSequence>
In both the case I think it is running with elevated privileges.
This is the error I get most of the time.
Edit
Dependency walker view of the dll is shown below.
Also I am adding the heat command I used. I have added this to prebuild event to generate the component. After that added this component in product file.
call "$(WIX)bin\heat.exe" file "dllPath\Abc.dll" -dr "INSTALLDIR" -srd -gg -sfrag -suid -out "$(SolutionDir)Installer\ComRegisterComponent.wxs"
And the generated file is look like this.
<Fragment>
<DirectoryRef Id="INSTALLDIR">
<Component Id="Abc.dll" Guid="*">
<File Id="Abc.dll" KeyPath="yes" Source="SourceDir\Abc.dll" />
</Component>
</DirectoryRef>
</Fragment>
Here this SourceDir path is confusing me.I have added the exact path in heat command even then it generates this SourceDir.
Short, Summary Answer
You need to stop using batch files and custom actions for COM registration (unreliable) and rather extract the COM registration information using the heat.exe tool from the WiX toolkit to add the COM registration to your MSI database at compile time.
There are some complications for 64-bit binaries, see details below. Fortunately it looks like you are dealing with a 32-bit component based on your installation directory shown above.
In this particular case it helped to run heat.exe on the COM file after deployment when all dependencies were "in place" for the COM file to load properly. There is a lot of "debugging communication" in these answers - I'll leave it all in place for the future, but try this simple solution first. And perhaps try the new dependency tool "Dependencies.exe" described below.
Long, Detailed Answer
Before I try to answer the question (which seems to revolve around missing dependencies or something weird being done in your batch file), I want to clear up a few things for you with regards to best practice for COM registration.
Note: the screenshot seems to indicate something weird going on in your batch file, but missing dependencies could still be an issue.
Self-registration Considered Harmful
Self-registration should not be used to register COM files. Here is a description of why this is the case: MSI register dll - Self-Registration considered harmful. There is good news, however, doing things as intended via built-in MSI mechanisms will be both easier and more reliable once you set it up properly.
There is a way to self-register files during installation without using custom actions like you are trying to do (the SelfReg table). Custom actions are very hard to get working correctly, but you should not use the built-in mechanism to run self-registration either (as explained in detail in the linked answer above)
Rather than using custom actions or the SelfReg table, COM registration information should be extracted from your COM files at compilation time - in other words when you compile your MSI file from your WiX source files. The extracted registry data should be used to populate the family of MSI data tables designed to reliably register and unregister the COM file during installation and uninstallation respectively.
WiX: The "heat.exe" Command Line Tool
Understanding the intricate details of this process is not necessary - all you need to know is what tools to use. WiX provides the "heat.exe" tool for this purpose. It is essentially a "harvester" tool capable of generating valid WiX XML source files for several purposes - one of which is COM extraction. It also supports traversing directories in general - generating WiX source files which can install the files encountered during traversal. It is essentially a very quick way to make an MSI package once you know how to use it.
Dependency Walker
So we have established that you should take the time to learn how to use heat.exe to generate the WiX source necessary to register the COM file properly. however, there is one more problem: the missing dependencies.
For a COM file to be able to self-register - or for you to be able to successfully extract the COM registry data using heat.exe - the COM file must be able to load correctly. For this to be possible all dll dependencies must be available on the system in question in an accessible location.
Get yourself a copy of Dependency Walker and use it to scan your COM file for what files it depends on. Here is an example of a COM file which fails to load because it cannot find MMUtilities.dll:
You will most likely find something similar wrong with your dll (or whatever file type it is, for example OCX) when it is run from your setup's installation location. The required dependency files can not be found by regsvr32.exe and the registration process fails.
There are some reported missing dependencies that are not important - I guess this has to do with the age of the Dependency Walker tool - it hasn't been updated recently as far as I know. Look for a file you recognize as either your own dependency file or a core system file as opposed to very long dll names of files you have never heard of. Keep in mind that some dlls have dependency language dlls that are required for loading. For example MMUtilities.dll needs MmUtilitiesEnglish.dll or another language dll present in the same folder to be able to load correctly.
Some sample false positive dependencies for the above file: API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL, API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL, API-MS-WIN-CORE-REGISTRY-L1-1-0.DLL, etc... There were many. I believe, but I am not sure, that the root cause of these false positives centers around problems with side-by-side components installed to the WinSxS folder, but that is a whole other discussion - just mentioning it.
UPDATE: I just checked this again and most of the false positive dependencies seen above are apparently API-sets - a Windows feature introduced long after Dependency Walker was created, and hence not handled correctly by the tool.
As the linked answer indicates (do read it, link above), there is now also a rewrite of Dependency Walker in C# called "Dependencies", available here: https://github.com/lucasg/Dependencies (untested by me at time of writing, will test shortly).
Also quick mention: if you have an executable to check (as opposed to a dll, ocx, etc...), you can launch it via the Profile => Start Profiling... menu entry and you will then also see "hidden run-time dependencies" not specified in the binary import table (where dependencies / imports are specified). You need to really exercise the application using all features in all dialogs to be sure to get all such dependencies.
The dependency walker web page calls these hidden dependencies explicit dependencies (a dynamic or run-time dependency) and system hook dependencies (injected dependencies). See the link just above for more details.
Heat.exe Extraction
Once you have determined what files are missing for making your WiX heat.exe extraction work, you can put the files in question "next to" your COM dll so they are found during its loading. You can test run using regsvr32.exe to see if registration completes correctly. There should be no error messages when you run registration manually like this. Remember to run registration from an elevated command prompt.
Several other stackoverflow answers explain how to use heat.exe - I haven't used it in a long time: How to run heat.exe and register a dll in wix. Here is the official documentation for heat.exe from the WiX guys themselves. It can be a somewhat intimidating tool - it has a lot of features.
In its simplest form (for normal 32-bit COM files with all dependencies available in the path or local folder), you can run this heat.exe command line to generate an output WiX source file called YourFileName.wxs with all the required COM registry data.
heat.exe file YourFileName.ocx -o YourFileName.wxs
I wrote an answer several years ago showing how to incorporate the exported WiX registry data into your main WiX source: How to Reference a Heat Output(wxs) in Wix (Command Line). I believe this is an accurate description of the procedure, but for some reason someone down-voted the answer. Please give it a go and see if it works for you.
Important!: heat.exe does not yet correctly process 64-bit COM binaries (December, 2017).
I have been informed that the WiX Expansion Pack (not free) handles 64-bit binaries and provides several other features. I suppose I can link to it (I am not affiliated with FireGiant): https://www.firegiant.com/wix/wep-documentation/harvesting/. Somehow people need to know about these things, but I am not sure about the the stackoverflow etiquette of linking.
Are your binaries 64-bit? (it doesn't look that way from your installation folder, but I add this for others who might find it). For a 64-bit component I guess we have come full circle and have to advise you to either use the above expansion pack feature or just try to set the file to self-register as described here. I hate this self-register "solution", but I can't think of any other quick fixes at the moment (none that I would recommend anyway). I will check again. Make sure to check the latest WiX release to see if the 64-bit problem has been fixed before going for this "self-registration fix". It is at least better than trying to register using custom actions and batch files (which should never be attempted - there are so many potential problems relating to MSI's complex custom action sequencing, impersonation / elevation, conditioning,installation modes with silent and interactive, not to mention the potential interference from security software, and the list goes on).
Some links:
- How do you register a Win32 COM DLL file in WiX 3?
- Cannot register DLL using WiX
- Use wix to perform function of REGSVR32
- Heat.exe Cannot Harvest TypeLib Info from a 64-bit COM DLL
- Heat.exe: 64-bit .dll fails to be converted to a 64-bit .msi
这篇关于使用Wix Msi安装程序在安装后将CPP dll注册到COM中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
