您可能知道,msiexec是一个命令行应用程序,可用于安装MSI文件.您可能知道,您可以在静默或不可见模式下运行它.
如果安装程序要求用户回答有关要安装的部件的具体问题,是否有一些方法可以在msiexec命令行中添加一系列选项来执行此操作？
我认为必须有某种方法来设置MSI文件的默认设置才能实现这一点.MSI文件是如何制作的？它们是通过微软的工具开发的吗？他们可以打开和编辑吗？
将MSI的用户界面视为可选.这意味着,没有答案应要求为开发商已制定合理的默认值,这样的事情不破.
我们以MSI格式向公司客户分发我们的软件,我还向他们提供有关Orca基础知识的文档(orca.msi随Windows Installer SDK一起分发)以及如何自定义我们在Property表中列出的安装的某些字段.如序列号,注册详情和其他一些设置.
在回答有关msiexec命令行选项的原始问题时,只需运行命令行MSIEXEC /?设置属性即可
MSIEXEC /I test.msi SOMEPROPERTY="Some value" PROP2="something else"
MSI files are designed specifically to support silent installation as a built-in feature - you can always skip the GUI. However, some MSI files have design flaws that render the install incomplete in silent mode - which is a serious design error. This problem is described here: Uninstall from Control Panel is different from Remove from .msi.
When it comes to installing an MSI silently, what you need to do is to configure the setup either from the msiexec.exe command line, or by applying what is referred to as a transform to the original MSI file. Both these options are described below in separate sections.
If the MSI file is well-designed you will be able to set PUBLIC PROPERTIES (they are always UPPERCASE) from the msiexec.exe command line or by using a transform file to modify the original MSI. These operations are described below. Public properties are easiest to find in the MSI file's "Property table". Use the MSI tool of your choice to open the*.msi file and navigate to the Property table. There are also some free MSI tools you can use to generate transforms and view (and edit) MSI files: How can I compare the content of two (or more) MSI files? (links towards bottom).
精心设计的MSI设置可通过这些公共属性完全配置.设计糟糕的MSI文件不是.设计糟糕的MSI文件最好使用转换文件进行调整(这可以对整个MSI文件进行重大更改,以便在安装时应用).设置公共属性只能更改公共属性可配置的任何内容 - 由安装程序创建者设计.转换几乎可以改变整个MSI文件中的任何内容.
通常,所有公司的静默部署都是使用转换来"将MSI文件打成形状"来实现企业标准.它是企业部署的一种非常有效的工具,并得到广泛使用.
MSI通常是违反直觉的,并且在引擎盖下有些复杂.但是,过度简化MSI文件包含一个或多个" 功能 " - 这些功能共同构成了" 应用程序的位 ".反过来,功能包括" 组件 " - 这是整个软件安装的原子单元 - 但这是一个非常技术性的细节 - 这个答案是关于用户暴露的MSI位 - 功能.
您通常可以通过交互式运行安装程序找到这些功能的列表,然后导航到自定义安装对话框(并不总是存在).此处显示的功能是应用程序的" 用户可配置 "部分,可以选择排除或包含(某些是必需的).您还可以通过使用上面提到的功能强大的工具打开MSI来找到这些功能(您还可以在下面的第2部分中看到链接).
Typical features are: Core or Program, Dictionaries, Samples, Plug-Ins, Spell Checker, SDK & Developer Tools (for dev tools), etc... Some features are mandatory (must be installed) - examples above would be Core and Program, others are optional and are not needed for the application to launch (like the dev tools features above). It is possible to make the application install features "on demand" - for example spell checkers when the user initiates a spell check.
根据我的经验,大多数用户都希望安装整个应用程 如果Windows Installer意外弹出并开始安装拼写检查程序组件,许多用户都非常恼火.坦率地说非常容易理解.但是,很少使用的模块化组件只对少数用户有用,可以制成可选组件 - 特别是如果系统管理员可能不希望网络上有该功能.对于开发人员工具来说肯定是这种情况- 普通用户不应该使用这些工具.它们往往是人们需要在脚下射击的所有绳索.
如上所述,通常有两种自定义MSI安装的方法:(1)使用msiexec.exe自定义命令行,或使用(2)转换文件.
控制安装期间安装的功能的最简单和轻量级方法是使用msiexec.exe命令行指定功能选择.有一整套属性用于功能配置.但是,在大多数情况下,指定ADDLOCAL:
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" /qn
上面的命令行指定应在本地安装" 程序 "和" 词典 " 功能(功能名称区分大小写!).这通常就足够了,但您也可以使用REMOVE属性以类似的方式指定要删除的任何功能.一个特殊的开关ADDLOCAL=ALL将在本地磁盘上安装MSI中的所有功能(前提是MSI中没有其他逻辑来覆盖它).MSDN上的ADDLOCAL属性.
公共属性定义的一个非常常见的事情是应用程序的许可证密钥.以下命令行指定安装" 程序 "和" 词典 "功能并应用序列密钥"1234-1234":
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn
如上面的描述所暗示的,每个设置的可自定义属性列表总是不同的.您可以找到MSI文件的Property表中列出的大多数属性,但也可以设置一些未在Property表中定义的属性.在大多数情况下,这涉及仅从设置GUI设置的属性(在大多数情况下表示设置设计错误).应在正确创作的包中的属性表中定义所有属性.
在供应商的下载页面上查找文档,并询问他们是否支持与静默安装或大规模部署相关的任何文档.这样做很快,如果他们有标准的答案模板,答案可以很快.控制其部署的公司将始终能够提供此服务.在我看来,理想的方法是一页PDF描述不同的部署设置.坦率地说,如果他们不能提供这个,给他们一些热量;-).
MSI文件本质上是包含在COM结构化存储文件(文件中的文件系统)中的SQL数据库.转换文件是通过安装工具(如Orca(SDK链接),Installshield或)构建的"部分数据库"明智的, Advanced Installer, etc... (link to descriptions of the different tools). These transforms can customize or override almost all settings or database fields in an MSI - including what "parts of the application" (features) are installed. After creating a transform you specify its application to the MSI at the msiexec.exe command line:
msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn
Windows Installer will then merge the MSI and the transform before installation starts. This is the approach used by large organizations who want full control of how the MSI gets installed. TRANSFORMS property on MSDN.
As mentioned above this is the option that allows all settings in an MSI to be modified. Substantial fixes can be applied to badly designed MSI files to allow reliable deployment. This is done by "application packagers". Their job is to tune all setups to work within the corporate standard. They can be among the most knowledgeable MSI specialists around - they see a lot of weird stuff in MSI files.
Many tools can be used to create a transform, here is a description of such tools inside the more technical context of comparing MSI files. Just jump straight to the list of free tools at the bottom: How can I compare the content of two (or more) MSI files?
Windows Installer has many design quirks and may be particularly annoying for developers. Admittedly there are some issues that border on anti-patterns.
counter-intuitive file overwrite rules (symantec)
strange rules, especially for non-versioned files
an insane feature to force overwrite all files (REINSTALLMODE = amus)
can downgrade shared files system-wide
can cause inconsistent version estate since an old package can be installed after a newer one and downgrade only some of the shared files
can downgrade or wipe-out settings in non-versioned files (and registry settings)
can cause a significant increase in the number of requested reboots due to attempts to needlessly replace in-use files of the same version.
there are several further issues that are quite specific. One day I will write them all up
unexpected reset user data in the registry after upgrades
This is extremely problematic. If you experience this it is not you, it is the technology
Often seen with service credentials logins and serial keys
Some techniques to avoid this problem
avoid writing ANY HKCU registry keys from your setup, write them from your application instead. Your setup will now never interfere with them - it has no knowledge of the values at all.
putting registry data in a feature of its own (should prevent problems on self-repair)
install registry data via a component with empty component GUID (will then not ever be rewritten during repair or self-repair)
set component flag to never overwrite if key-path exists.
write HKLM data (such as license keys) to the registry using a custom action instead (this has other problems, but will give you complete control of when data is written - in what installation mode)
make darn sure you keep a stable registry key path. Set a flag value KeyPath = 1 and never change it - and crucially - don't change the component GUID either
never set REINSTALLMODE to "amus" - certainly not hard code that value in the property table.
there are further tricks and rules of thumb, if only I could remember them all off the top of my head :-).
complex upgrade mechanism
minor upgrades has a lot of limitations and restrictions
major upgrades have other challenges (reset registry data, missing files after install, self-repair for COM files after install, etc...)
lackluster GUI features
not rocket science, but somewhat complex
lacking events and features to implement a properly smooth GUI
shockingly complicated patching
extremely difficult to use effectively
not recommended for use except as a "hotfix" - i.e updating a couple of files or fixing a specific MSI file error in the installed setup's uninstall sequence.
Some patching comments:
Windows Installer "Error 1308. Source file not found" when uninstalling patch in sequence scenario
MSP vs. MSI packaging. Which to use for patches?
extremely complicated implementation of custom actions
complex sequencing
complex conditioning
complex impersonation/partial running with elevated rights
overall extremely error prone.
the lackluster implementation of per-user setups
conceptually dubious (folder redirects, unpredictability, impossibility of making setups in the real world support both per-user and per-machine installs)
complex to upgrade, uninstall and patch. Allows products to be installed multiple times for different users AND also per-machine
I have to admit - on a subjective note - that I deem the current implementation of per-user setup a full on deployment anti-pattern. I never use it and insist not to unless forced to.
unexpected self-repair
1) Self-repair - explained.
2) Self-repair - finding real-world solutions.
3) Self-repair - how to avoid it in your own package.
the lack of built-in features to write to XML files
poor features for IIS installs
part of the issue is the file overwrite rules for unversioned files (unpredictable results possible).
IIS may need a brand new deployment technology altogether to be honest - a way to define handling of non-versioned files in a totally predictable fashion - with sensible, real-world options. Perhaps auto-backup of force-replaced non-versioned files, enforcing of groups of consistent text files ("assemblies") that have to be correct version all of them, etc...
also several other issues with the complex configuration of IIS and virtual folders and sites
sloppy enabling of "check exit code" on custom actions can cause packages that are not possible to upgrade or uninstall (without serious tweaking)
major upgrades may fail and trigger rollback for something insignificant
a minor upgrade can be used to fix the uninstall sequence or the faulty conditioning
there are a few more...
In fact I wrote up a sprawling summary of commonly seen anti-patterns often seen in real-world MSI packages themselves (erroneous use of the technology): How do I avoid common design flaws in my WiX/MSI deployment solution?
I can stand by all the content, but the format is not great - it is a messy brain dump, but sometimes that seems to be the only way to get things done. Take it for what it is.
Overuse of custom actions is another MSI problem. There is a core of complexity behind this, but overall the problem is that people don't use fully functional pre-existing solutions in MSI or via extensions such as WiX (or commercial tools such as Installshield or Advanced Installer). Here is a summary: Why is it a good idea to limit the use of custom actions in my WiX/MSI setups?
The issue of high complexity of implementing custom actions (custom installation logic), could be argued to be unavoidable and the act of writing a custom action should be powerful and capable once needed - and hence complicated. Rarely should custom actions be needed if the technology itself offers what is commonly used for deployment. In other words you should use built-in MSI features rather than custom actions if they are available, or WiX or third party deployment software extension when available.
The WiX framework (open source) and commercial tools alike (Installshield, Advanced Installer, etc...) have implemented features to extend Windows Installer to deal with missing features such as the lack of an upgrade mechanism for XML files, share creation and management, creation of users and groups, advanced IIS configuration, COM+ installations, changing ACL permissions, setting firewall rules, persisting installation properties, etc... There should be less and less need to implement your own custom actions. Always use the features that are already tested by thousands of other users if you can (millions of users even - and these extensions have been written by the best deployment experts available - do you think you can do it better on your own?).
It requires a specific mindset to approach Windows Installer. However, it provides a number of crucial corporate benefits that were almost entirely lacking in previous installation technologies. The corporate benefits of using MSI files is recommended reading. Particularly for those who think Windows Installer is more trouble than it is worth.
To summarize the linked article in brief, the core corporate benefits of MSI over previous deployment technologies are (in my opinion):
the reliable silent running (with standardized, completely suppressible GUI)
the implicitly available uninstall (a nightmare with older deployment tecnologies)
the verbose logging (can be helpful, though really verbose indeed)
the reliable remote management (in effect the overall benefit altogether - the combined effect of all other listed benefits of sorts)
the elevated install rights (no messy temporary admin rights)
the standardized command line (a hugely beneficial feature - no more chasing hidden command line options)
the installer's semi-transparent nature (open format, except compiled CAs which are black box)
the rollback support (computer state management, prevent partial deployments, fail and roll back changes)
the admin install (essential for corporate repackaging, extracts all files in a standard way)
the standard package customization approach (transforms) (basically allows complete customization for corporate deployment)
That's just to cherry pick the most important ones (after many years doing corporate deployment). In all honesty these features make all the difference in the world (for corporate deployment) and truly makes MSI great to use despite all its flaws.
As Windows Installer hits its twilight years, we can only hope that the deployment technologies of the future will preserve these great corporate deployment benefits and deal with the mentioned anti-patterns in a way that benefits everyone, and developers in particular.
Deployment is a crucial part of development. Failing to get your great software successfully installed for your potential end users may be the most expensive mistake to make in software development overall. How can you succeed if the user never sees your software fully functional?
Windows Installer's complexity must be handled better (reduced), and its crucial benefits must be preserved properly in whatever paradigm comes next.
A reasonably good: summary of Windows Installer.
With all this said; as computing in general moves to cloud-platforms, the world of deployment is likely to change considerable in unpredictable ways. However, as the famous saying goes: the more things change, the more they stay the same. Deployment needs to deal with all legacy technology that will be in use in companies for decades to come. Here is a piece on why deployment seems to get more complicated and not less complicated - despite all the marketing: What is the benefit and real purpose of program installation?.
It will be interesting to see what the future of deplo
京公网安备 11010802040832号 | 京ICP备19059560号-6 