Windows Installer - 安装包时避免 FileinUse 对话框 [英] Windows Installer-Avoid FileinUse dialog box when Installing a package
问题描述
当有文件的更新补丁必须用现有文件替换时,如果其中一个文件正在被任何进程使用,则会弹出一个正在使用的文件对话框.我想避免该对话框并让该文件排队等待安装,以便在系统重新启动时安装它.我已经读到在重新启动时排队更新文件是 Windows 安装程序的内置功能.有人可以建议我删除那个 FileInUse 对话框的方法.我尝试将MsiRMFilesInUse"属性设置为0",但没有奏效.
"Short";回答
<块引用>本质上:您可以1)
完全静默运行(抑制使用中的文件对话框), 2)
关闭锁定应用程序正常(应用程序更新以允许正常关闭 - 有或没有重启管理器支持),3)
确保适当的服务控制(如果处理服务),4)
force-kill正在运行的进程(大锤方法"),5)
如果检测到锁则中止设置,6)
部署前需要注销,7)
安装到每个新文件夹版本(并行安装)等...
下面是使用中的文件问题和重启管理器 - 旨在快速查看使用中的文件和重启问题.
就您的实际问题而言.我不会弄乱 FileInUse 对话框
.它不会真正解决你的问题.也许考虑这些指针:
- 服务:如果您正在安装服务并且它们触发了文件使用中的问题,请参阅底部的服务部分以确定您是否可以改进您的设置逻辑.
- 静默模式:在静默模式下运行设置将是抑制此类正在使用的文件对话框的明显方法,但是您必须抑制自动重启,否则系统会在没有警告的情况下自发重启.详情如下.
- 政策:请检查 DisableAutomaticApplicationShutdown 策略已在您的机器/标准 PC 配置上启用.请参阅下面的详细信息.
- 注册表位置为:
HKLM\Software\Policies\Microsoft\Windows\Installer
. - 我不确定启用此策略是否会使使用中的文件对话框消失.
- 重新启动管理器合规性:也许检查您是否应该更新您的应用程序以注意 重启管理器功能 - 允许应用程序自行关闭进行自动魔法和无问题升级优雅地向下(假设您正在处理可以实际更改自己的二进制文件 - 换句话说:您拥有源代码).下面有很多详细信息.
- Setup Overkill":如果您认为在升级过程中毫不留情地终止应用程序是安全的,请参阅下面的部分.
- Graceful Shutdown Custom Action:如果你让你的应用程序能够正常关闭(重启管理器风格),那么你也可以自己触发这样的关闭(最简单的用于用户上下文进程)通过即时模式自定义操作(如果重启管理器被策略禁用 - 但要注意计时和超时问题 - 特别是对于静默运行 - 死锁").
- 并排安装:以下是一些详细信息.一些公司决定真正并行安装应用程序,这样他们的新部署就不会出现文件覆盖问题(尽管卸载旧版本可能仍会触发所需的重启).
我想如果检测到锁定的文件,您也可以中止安装,或者您可以要求用户在运行安装之前注销 - 如果您有发行版系统.
请至少略读答案的其余部分以获取更多详细信息和上下文.
重启管理器
您的应用程序和服务应该准备好被 重启管理器并保存干净重启所需的用户数据和状态信息.这需要对应用程序/服务进行更新和更改,以符合关闭和重新启动应用程序的标准.
重启管理器:是一个新的 C 风格的 API,从 Windows Vista 和 Windows Server 2008 开始可用.重启管理器由一个 DLL 组成强> 应用程序可以加载以访问 重新启动管理器 API.想法是重启管理器将在安装/更新期间自动关闭和重启您的应用程序,让应用程序/服务遵循一组准则:
<块引用>本质:整个想法基本上是更喜欢重新启动应用程序而不是重新启动操作系统 - 并且通常还避免重新启动.
.为此:1)
您的应用程序使用命令调用 RegisterApplicationRestart()
为其最终重启指定的行 - 它注册"重启管理.2)
您的应用程序监视 WM_QUERYENDSESSION
消息并关闭以适当的方式优雅地保存数据当被告知这样做时.3)
然后 重启管理器 可以重启安装完成后的应用程序(可以禁用重新启动).
更多技术内容:
重启管理器配置:有许多属性会影响重启管理器与 Windows Installer 的运行方式:
- MSIRESTARTMANAGERCONTROL - 使用重启管理器或 FileInUse 对话框
- MSIDISABLERMRESTART - 重启或不重启关闭的应用程序
- MSIRMSHUTDOWN - 关机,强制关机或不强制关机
当使用 Restart Manager 时,MsiRMFilesInUse 对话框是用于代替 FileInUse 对话框 显示已锁定文件的应用程序列表.
注意!整个重启管理器功能也可以通过策略禁用:
- DisableAutomaticApplicationShutdown政策.
- 签入
HKLM\Software\Policies\Microsoft\Windows\Installer
. - 使用 Windows 安装程序重新启动管理器行为
文件使用中
如果您没有时间或资源来实现与 重启管理器(坦率地说,这是目前在 Windows 开发中花费资源的唯一明智之举),然后有一些事情可能对知道:
- 静默安装:首先要指出的是,如果您在 中安装设置,则不会有
FileInUse
对话框>静音模式.但是,除非您指定REBOOT=ReallySuppress 属性
,否则这可能会触发系统重新启动. - 服务:您是否安装了在升级过程中没有正确关闭的服务?有
内置 MSI 结构
用于在升级过程中关闭服务
- 服务控制表. - 如果使用得当,此 ServiceControl 功能意味着您不会再遇到任何触发重新启动以被替换的服务可执行文件的问题(除非服务本身出现关闭问题).
- 这是一个内置的 MSI 结构,如果使用得当,效果很好.人们不应诉诸自定义操作来安装服务.
- 应用程序支持:超越与 重启管理器,有些应用程序 - 有文件正在使用 - 可以在被告知关闭时正常关闭.
- 某些应用程序在发送命令行时会正常关闭,例如
App.exe -shutdown
,尽管没有被编写为与 重启管理器.也许系统托盘应用程序不为用户保存数据? - 这显然必须专门针对相关应用程序实施 - 如果您这样做,您应该使用 此时重新启动管理器(或者,您可以同时调用相同的实际关闭实现).
- Setup Overkill":某些设置旨在仅终止安装时打开的应用程序进程.
- 不理想,但它适用于在后台运行的某些类型的应用程序(好吧,这很疯狂,但它是定期执行的).
- 使用自定义操作或部署工具中可用的任何内置结构.
WiX
:在 WIX 中强行杀死 windows 服务.VBScript
:使用 VBScript 关闭应用程序.高级安装程序
:如何检测或停止进程.Installshield
:杀死进程.杀死进程文档.立>
- REINSTALLMODE:您是否可能在安装过程中使用
REINSTALLMODE=amus"
来强制覆盖文件? - 这会显着增加正在使用的文件数量和重新启动提示,因为 所有 文件都被尝试替换 - 通常是不必要的 - 特别是在
repair
和修改
场景. - 对于安装不使用 ServiceControl table 以在尝试覆盖其二进制文件之前正确关闭服务.
- 并行安装(
SO):添加此供参考,超出了通常相关"的范围.这种方法需要大量的技术更改和适当的分发流程才能取得成功 - 在我看来,它主要用于内部核心企业应用程序(可以完全控制应用程序). - 针对新安装文件夹的新版本(将版本号添加到安装文件夹?),通常可以安装而不会出现任何文件覆盖问题(除非更新了任何系统共享文件 - 在这种情况下,您应该将它们拆分为单独的预必要的 MSI - 有自己的分发逻辑 - 在需要时 - 这应该很少).
- 旧版本的卸载仍会触发重新启动要求,因为文件可能正在使用中且尚未准备好卸载.很明显.
- 您可以为设置组件使用自动 GUID - 因此 MSI 可以以正确的方式单独跟踪它们.您通常必须消除设置静态组件的所有需要(或者它们必须安装到共享位置并保持静态 - 或者在需要时通过单独的先决条件 MSI 进行更新).
- 整个应用程序必须表现良好";用于并排使用和安装.换句话说,不要争夺文件关联并正确加载所有资源并管理可以在实例之间共享的数据库连接等...
- 您将版本号添加到开始菜单快捷方式了吗?不知何故,您必须能够区分安装并启动所需的版本 - 显然.应用程序应该知道它的分身吗?
- 我可能会考虑为每个版本设置一个新的升级代码,以便将产品彼此分离,然后使用分发系统卸载旧的旧版本(作为周末或每月的批处理作业?).这不是 100% 必要的,这完全取决于您的情况.很明显,如果计划得连贯,很多事情都可以奏效.
- 有时可能会使用 App-V(虚拟包)对不适合正常并行操作的应用程序进行虚拟化和沙盒化处理,以允许不同版本在同一个设备上共存.新的挑战.
一些进一步的链接:
- FileInUse 或 FilesInUse(赛门铁克员工提供的大量内幕信息)
- 在 CustomAction 中终止进程
- 使用 Windows 安装程序重新启动管理器行为
- 我该怎么办在 wix 中停止修复、更新和删除 .exe?
- RmGetList() API 在使用 Ez 文件锁定器锁定文件但与另一个文件锁定实用程序一起使用时失败
- 抑制 MSI 错误代码
- Wix卸载/升级时停止服务:防止重新启动弹出窗口";(文件使用情况)
When ever there is an update patch of files that have to be replaced with the existing files and if one of the files is being used by any of the processes, then a file in use dialog box pops-up.I wanna avoid that dialog box and get that file queued up for installation so that it can be installed at the time of system reboot. I have read that the queuing the files for update at the time of reboot is the inbuilt functionality of windows installer. Can someone suggest me the way to remove that FileInUse Dialog box. I tried setting up the "MsiRMFilesInUse" property to "0" but it didn't work.
"Short" Answer
Essentially: you could
1)
run completely silently (suppresses the files-in-use dialog),2)
shut down locking applications gracefully (application update to allow graceful shutdown - with or without restart manager support),3)
ensure proper service control (if dealing with services),4)
force-kill running processes (the "sledgehammer-approach"),5)
abort setup if locks are detected,6)
require logoff before deployment,7)
install to a new folder for each version (side-by-side install), etc...
Below is a little drill-down of files-in-use issues and the Restart Manager - intended as a quick review for files-in-use and reboot issues.
In terms of your actual problem. I wouldn't mess with the FileInUse dialog(s)
. It won't really solve your problem. Maybe consider these pointers:
- Services: If you are installing services and they trigger files-in-use issues, please see section on services towards the bottom to determine if you can improve your setup's logic.
- Silent Mode: Running your setup in silent mode would be an obvious way to suppress such files-in-use dialogs, but then you have to suppress automatic reboot, or the system will spontaneously reboot without warning. Details below.
- Policy: Please check if the DisableAutomaticApplicationShutdown policy is enabled on your box / standard PC configuration. See details below.
- Registry location is:
HKLM\Software\Policies\Microsoft\Windows\Installer
. - I am not sure if enabling this policy will make the files-in-use dialogs disappear.
- Restart Manager Compliance: Maybe check if you should update your application to heed the design of the Restart Manager feature - to allow for auto-magic and problem free upgrades by applications shutting themselves down gracefully (provided you are dealing with binaries that you can actually change yourself - in other words: you have the source code). Lots of details below.
- "Setup Overkill": If you deem it safe to kill your application without mercy during upgrades, see section on this below.
- Graceful Shutdown Custom Action: If you make your application capable of graceful shutdown (restart manager-style), then you can trigger such a shutdown yourself as well (easiest for user context processes) via an immediate mode custom action (in case Restart Manager is disabled by policy - look out for timing and timeout issues though - especially for silent running - "deadlock").
- Side-By-Side Installation: some details below. Some companies decide to install applications truly side-by-side so there are no file overwrite issues with their new deployments (old versions uninstall may still trigger required reboots though).
I suppose you could also abort the install if locked files are detected, or you could require users to log off before the installation is run - if you have a distribution system.
Please at least skim the rest of the answer for more details and context.
Restart Manager
Your applications and services should be prepared to be shut down by the Restart Manager and save user data and state information that are needed for a clean restart. This requires updates and changes to the application / service to adhere to standards for shutdown and restart of the application.
The Restart Manager: is a new C-style API available beginning with Windows Vista and Windows Server 2008. Restart Manager consists of a single DLL that applications can load to access the Restart Manager API. The idea is that the Restart Manager will auto-magically shut down and restart your applications during installations / updates, by having the application / service follow a set of guidelines:
- Guidelines for Applications - (
the crucial tech-read
) - Guidelines for Services
In essence:
The whole idea is basically to prefer restarting applications rather than restarting the OS - and also to avoid reboots in general.
. To that end:1)
Your application callsRegisterApplicationRestart()
with a command line specified for its eventual restart - it "signs up" for restart management.2)
Your application watches forWM_QUERYENDSESSION
messages and shuts down gracefully saving data in an appropriate way when told to do so.3)
Then Restart Manager can restart the application when finished installing (restart can be disabled).
More Technical stuff:
- Here is a nice Symantec article on "Files In Use & The Restart Manager".
- How do I add support for Windows Restart Manager to my application? (Advanced Installer)
Restart Manager Configuration: There are a number of properties that will affect how the Restart Manager will operate with Windows Installer:
- MSIRESTARTMANAGERCONTROL - use the Restart Manager or FileInUse Dialog
- MSIDISABLERMRESTART - restart or don't restart shut down applications
- MSIRMSHUTDOWN - shutdown, force shutdown or do not force shutdown
When Restart Manager is used, the MsiRMFilesInUse dialog is used instead of the FileInUse dialog to show a list of applications that have locked files.
N.B! The whole Restart Manager feature can also be disabled by policy:
- DisableAutomaticApplicationShutdown policy.
- Check in
HKLM\Software\Policies\Microsoft\Windows\Installer
. - Restart Manager behavior with windows installer
FileInUse
If you don't have the time or resources to implement proper interoperability with the Restart Manager (which is frankly the only sane thing to spend your resources on at this point in Windows's development), then there are a few things that might be good to know:
- Silent Install: The first obvious thing to point out is that there will be no
FileInUse
dialog if you install the setup in silent mode. However, this could trigger a system reboot unless you specify theREBOOT=ReallySuppress property
. - Services: Do you install services that you do not properly shut down during upgrade? There are
built-in MSI constructs
toshut down services
during upgrades - the Service Control table. - Used properly, this ServiceControl feature means you no longer have any problems with service executables triggering a reboot to be replaced (barring shutdown problems in the service itself).
- This is a built-in MSI constructs and works well when used right. People should not resort to custom actions to install services.
- Application Support: Beyond interoperability with the Restart Manager, some application - that have files in use - can shut down gracefully when told to do so.
- Some applications shut down properly when sent a command line, for example
App.exe -shutdown
, despite not having been written to be interoperable with the Restart Manager. Maybe system tray applications that save no data for the user? - This obviously has to be implemented specifically for the application in question - and if you do that, you should use the Restart Manager instead at this point (or additionally, you could have both call the same actual shutdown implementation).
- "Setup Overkill": some setups are designed to just kill application processes that are open at the time of installation.
- Not ideal, but it can work for certain types of applications that run in the background (OK, it is nuts, but it is done regularly).
- Use a custom action or whatever built-in constructs are available in your deployment tool.
WiX
: Kill windows service forcefully in WIX.VBScript
: Close an application using VBScript.Advanced Installer
: How to detect or stop a process.Installshield
: Kill process. Kill process documentation.
- REINSTALLMODE: Do you perhaps use
REINSTALLMODE="amus"
to force overwrite files during installation? - This can dramatically increase the amount of files in-use and reboot prompts since all files are attempted replaced - and generally unnecessarily so - especially in
repair
andmodify
scenarios. - This is particularly true for setups that install services that do not use the ServiceControl table properly to shut down the service before trying to overwrite its binary.
- Side-By-Side Installations (SO): adding this for reference, it is beyond the scope of what is "normally relevant". This approach requires quite a bit of technical changes and proper distribution processes to be successful - it is primarily for in-house, core corporate applications (full app control possible) - in my opinion.
- New versions, targeting new installation folders (add version number to installation folder?), can generally install without any file overwrite issues (unless any system-shared files are updated - in which case you should split them to a separate pre-requisite MSI - with its own distribution logic - when required - which should be rarely).
- Older version uninstall can still trigger reboot requirements as the files can be in-use and not ready to be uninstalled. Obviously.
- You can use automatic GUIDs for the setup components - so MSI can keep them tracked separately in a correct fashion. You must generally eliminate all need to set static components (or they must be installed to shared locations and kept static - or updated via a separate pre-requisite MSI when required).
- The whole application must be "well behaved" for side-by-side use and installation. In other words not fight over file associations and load all resources properly and manage database connections that could be shared between instances, etc...
- You add the version number to the start menu shortcut? Somehow you must be able to differentiate installations and launch the desired version - obviously. The application should be aware of its doppelgängers?
- I might consider setting a new upgrade code for each release, in order to decouple the products from one another, and then use the distribution system to uninstall older, legacy versions (as a weekend or monthly batch job?). This is not 100% necessary, it all depends on your scenario. Lots of things can work when planned coherently - obviously.
- Applications not suitable for normal side-by-side operation may sometimes be virtualized and sandboxed using App-V (virtual packages) to allow different versions to co-exist on the same box. New challenges.
Some Further Links:
- FileInUse or FilesInUse (lots of inside information from a Symantec employee towards bottom)
- Terminating process in CustomAction
- Restart Manager behavior with windows installer
- How can I stop an .exe on repair, update and delete in wix?
- RmGetList() API fails when file is locked using Ez file locker but works with another file locking utility
- Suppress an MSI error code
- Wix stop service on uninstall/upgrade: prevent "restart popup" (file-in-use situation)
这篇关于Windows Installer - 安装包时避免 FileinUse 对话框的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!