如何在 Linux 服务器上构建 MSI 包? [英] How to build MSI package on a linux server?
问题描述
我有一个 Windows 桌面应用程序，目前可以在 Linux 服务器上下载到用户的机器上.我想使用任何 EXE/DLL 在同一台 Linux 服务器上自动执行 MSI 打包过程.
I have a windows desktop application which is currently available on a Linux server for download on user's machine. I want to automate the process of MSI packaging on the same Linux server using any EXE/DLL.
我有一个 App.exe 和 App.txt 文件.在创建 MSI 包之前，应从文本文件中读取一些信息并注入到 exe 中.只有在用户点击下载后，整个过程才必须在 Linux 服务器中动态发生.
I have an App.exe and App.txt file. Some information should be read from text file and injected into exe before creating an MSI package. This entire process has to happen dynamically in the Linux server only after the user clicks on download.
有人能指出我如何实现目标的正确方向吗?我想通过对任何其他/第 3 方工具的依赖最小来实现相同的目标.任何时间和精力的 TIA.
ps - 我对各种安装程序进行了一些研发，但没有一个符合标准，因为它们有太多的依赖项.
p.s - I have done some R&D about various installers but none of them were matching the criteria as they have too many dependencies.
推荐答案
误报风险:为每个用户创建一个新的二进制文件似乎非常不明智，因为恶意软件扫描程序及其识别二进制文件已知"版本的能力(通过哈希).
False Positive Risk: Creating a new binary for every user would seem to be very unwise because of malware scanners and their ability to recognize "known" versions of binaries (by hash).
如果您为每个用户创建一个新的二进制文件，恶意软件套件可能会突然开始隔离您的设置，而没有任何警告或意义.这个问题不再微不足道，因为到处都加强了恶意软件控制，并且以提升的权限运行的设置是风险管理的主要嫌疑人".
If you create a new binary for each user, the malware suite might suddenly start to quarantine your setup without any warning or sense. This problem is not trivial anymore as malware control is hardened everywhere and setups that run with elevated rights are "prime suspects for risk management".
数字签名可以提供帮助，但它们仅能保证您进行了设置，并不能保证设置中不包含任何有害内容.没有什么比签名的恶意软件载体更糟糕的了.事实上，恶意软件来自您的证明是肯定的:-).注意:有些人甚至设法篡改签名的可执行文件.后两个事实结合在一起，非常令人不安.
Digital signatures can help, but they are merely a guarantee that you made the setup, and not a guarantee that the setup doesn't contain anything harmful. Nothing worse than signed malware vectors. In fact it is proof positive that the malware came from you :-). Note: some people even manage to tamper with signed executables. The combination of the latter two fact is very troubling.
应用程序设置:我喜欢从设置中消除此类功能和细节，并让应用程序在安装后首次启动时自行负责配置.我发现这更可靠且更易于调试.
Application Setup: I like to eliminate such features and details from the setup and make the application itself responsible for it own configuration on first launch after installation. I find this more reliable and easier to debug.
自定义配置:您可以在运行时通过各种机制应用自定义配置信息.您应该添加转换，或者您可以在安装程序旁边创建一个批处理文件，其中嵌入了此信息并传递给 MSI 或 setup.exe.
Custom Configuration: You can apply custom configuration information at runtime via various mechanisms. You should add in a transform, or you can create a batch file next to the setup with this information embedded and pass to the MSI or the setup.exe.
批处理文件?:msiexec.exe 命令行支持向 MSI 传递参数.如果您设计的设置支持这些传入"参数，您可以生成一个批处理文件，该文件将使用这些参数运行设置.
Batch File?: The msiexec.exe command line supports passing parameters to the MSI. You can generate a batch file that will run the setup with such parameters if you design your setup to support these "incoming" parameters.
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn
转换:您还可以创建一个转换来包含参数(转换是一个微小的 MSI 片段，其中包含对原始 MSI 的设置和更改):
Transform: You can also create a transform to contain the parameters (a transform is a tiny MSI fragment with settings and changes to the original MSI):
msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn
在 Linux 机器上很难创建转换，因为它们是仅适用于 Windows 的 COM 结构存储文件.我不确定这是否可能，但也许吧.
A transform would be difficult to create on a Linux box, seeing as they are COM-structured storage files native to Windows only. I am not sure if it is even possible, but maybe.
一些链接:
这篇关于如何在 Linux 服务器上构建 MSI 包?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
