安装.exe文件时不要覆盖现有文件 [英] Do not override the existing file when we install the .exe file

问题描述

我已经安装了.exe应用程序(例如，版本1.0).安装应用程序后，我可以在本地路径(C:\ Program Files(x86))中看到几个DLL和几个.XML配置文件.现在，在启动新版本并安装它之后，我不想在本地路径中单独覆盖现有的XML文件.有什么办法吗?

我的EXE是使用WIX安装程序创建的，而该项目是在Visual Studio 2015中构建的.

解决方案

您的应用程序如何工作?它会随着时间的推移将设置写入这些XML文件，因此您想要保留它们吗?如果是这样，它们存储在哪里?在按机器或按用户的位置?

让我尝试为您描述一些您可能会遇到的问题-您可能无法提前预见(未经测试).

有关文件覆盖的一些详细信息

1. 文件版本控制规则 :MSI具有内置支持，不会覆盖自安装以来已修改的非版本化文件(创建和修改日期为不同的).这些是"> 文件版本控制规则> ".它们有些复杂和奇怪-您绝对应该阅读链接的内容-真正的McCoy.因此，修改后的非版本文件不应在更新期间被替换-但存在许多复杂性和 bear-traps -并且大多数人似乎都属于其中之一.

2. 主要升级文件的还原 :也许"意外的文件覆盖"出现的最常见的并发症根本不是覆盖.它与主要升级有关-或根据需要安装您的下一个产品版本.

   • 如果使用重大升级来安装下一个版本，并且在InstallExecuteSequence的早期安排了RemoveExistingProducts，则实际上将卸载所有文件，然后将其重新安装为原始版本.它们似乎已被覆盖，但是已被卸载，然后改为全新"安装.

   • 所有这些都是由于一个非常奇怪的决定，即MSI会很高兴地卸载已修改的文件，即使它们符合被覆盖的条件.您需要的是一种定义根本不卸载的文件的方法.这将我们带到下一点:

3. 永久和永不覆盖标志 :每个组件都有两个与文件覆盖和文件保存相关的重要设置:永不覆盖标志和永久标记.这确实是指示不要替换或卸载文件的好方法.但是...

   • 仅设置永不覆盖"标志将无法解决上述主要升级问题，该文件仍然会被卸载然后重新安装，因此看起来已被覆盖(但已还原).

   • 如果仅设置永久标志，则文件将根据文件版本规则被覆盖-前提是未在命令行中使用诸如REINSTALLMODE之类的功能指定修改(请参见下文).(我将再次对此进行确认，以确保100％保证.有许多因素:组件只能在旧的或较新的设置中永久设置-或在这两种设置中，主要升级都可以早期或晚期卸载，REINSTALLMODE有很多口味等...每个变量都可以更改覆盖行为)

   • 换句话说，建议同时设置永久性标志和永不覆盖标志以保护设置文件.

4. REINSTALLMODE :REINSTALLMODE是REINSTALLMODE属性在安装过程中等于 amus -将(除其他事项外)强制覆盖安装过程中的所有文件，而与上述文件版本规则无关.

   • amus 的说明 REINSTALLMODE 参数:

     • a -强制重新安装所有文件，而不考虑版本
     • m -重写所有转到HKLM或HKCU的注册表项
     • u -重写所有转到HKCU或HKEY_USERS的注册表项
     • s -重新安装快捷方式和图标

   • 这几天中，我将写下有关REINSTALLMODE及其实现的问题.它是MSI中令人难以置信的破坏性概念，永远不要使用.问题在于，这是一条通用命令行，可以传递给任何MSI软件包并适用于整个设置(为什么至少不能针对每个功能?).如果要指定 amus ，我想使我的软件包中止.让我快速记下一些问题:

     • 降级 :可以在系统范围内降级共享文件.这些文件可以来自合并模块，因此人们可能不会意识到它们以系统文件夹为目标.Windows 10现在可以很好地保护其OS文件，但是在没有OS保护的情况下，仍然可以降级其他文件.
     • 版本不一致 :可能导致版本不一致，因为可以在更新版本之后安装旧软件包并仅降级某些共享文件.
     • 设置擦除 :可以降级或擦除非版本化文件中的设置(和注册表设置).
     • 重新启动提示 :由于尝试不必要地替换相同版本的正在使用的文件，因此可能导致请求的重新启动次数显着增加.有一些功能可以避免这种情况，但是通常无法正确使用它们.重启管理器，有关重启的更多信息经理.
     • 然后还有更多... :还有几个非常具体的问题.有一天我会把它们全部写下来.我认为.也许不会?:-).
       • Windows文件保护(WFP) :也许我可以添加某些旧版合并模块包含受OS保护的文件，然后尝试替换它们用于可能会触发运行时错误.Windows 10现在可以静静地"处理此问题.
       • 注册表 : m 和 u amus 的开关将完全重置由组件(而不是自定义操作代码)写入的注册表数据，而不考虑 a 切换(至少我上次尝试过这种情况).在我的 MSI反模式列表上(请参阅潜在的反模式" 部分).
       • 未知 : GAC ， WinSxS .我什至不知道GAC如何运作?并排是否可以通过设计降级?有人会想.除非您直接在Assembly文件夹内四处戳-否则可能会触发运行时错误-我没有尝试过.实际上，我认为不会.看到此问题，并带有

这是所有稍微疯狂是诚实的，但它是技术如何工作.因此，让我们停止抱怨并尝试解决问题.有什么解决方法?

一些用于处理设置文件保存问题的选项

总而言之，我想您有两种选择:

1. 使用次要升级来升级您的应用程序 .这样一来，您的文件就永远不会被卸载和重新安装，因此像进行重大升级一样可以还原.

   • 次要升级不会卸载现有安装-它会直接对其进行升级.适用常规文件版本控制规则(不会替换已修改的非版本文件)-除非使用REINSTALLMODE修改此逻辑.

   • 但是，很少有人仅通过较小的升级就能成功-他们过于严格和受限.我几乎不会说.

2. 在InstallExecuteSequence的早期阶段对RemoveExistingProducts使用主要升级，并且永久且永远不会覆盖托管设置文件的组件 .使用重大升级时，主要选择是在旧版本的早期卸载之间，还是在后期卸载之间，此选择具有巨大的意义.

   • 本节需要一些清理.即将发生.... 2019年12月 :我们回来了.多年后.今天发生了一些小小的清理-没什么大不了的.我将继续承诺进一步清理.空洞的诺言使世界运转.如果这一切都让人抱怨，请请阅读MSI的主要优点(快速列表).MSI对以前的部署技术进行了至关重要的改进，但是还存在一些重大挑战.

   • 早期卸载意味着任何引用了您所犯错误的组件都不会引起任何问题.如果您愿意，它们更宽容".很多人最终使用这种方法是因为，它是组件引用错误和整体健壮性"的最宽容".

   • 早期卸载还意味着修改后的文件可以在升级过程中被卸载并重新安装，从而使它们看起来被覆盖，但是它们已还原(如上所述).

   • 解决上述问题的一种方法是将文件的托管组件设置为永久，并且永不覆盖.

   • 早期卸载意味着可以破坏复杂的组件创建规则，并且升级仍然可以进行.打破组件创建规则是很常见的.如果使用这种方法，则应将要在升级期间保留的文件设置为永久文件，并且永远不会覆盖.这样可以避免卸载已修改的文件并安装新文件的问题-产生文件已被覆盖的印象.

3. 在InstallExecuteSequence 中对RemoveExistingProducts使用主要升级.

   • 后期卸载主要升级安装不会卸载和重新安装旧设置和新设置中位于同一位置的文件-即使有问题的文件未设置为永久且永远不会覆盖(允许正确的文件)，此方法仍然有效也可以卸载文件-无需添加任何自定义逻辑).

   • 这种升级基本上是作为补丁"安装的-保持版本之间不变的文件不变，然后根据上述文件版本控制规则升级其他文件.

   • 相反，它们将根据常规文件版本控制规则被覆盖(前提是您未将REINSTALLMODE设置为等于amus，在这种情况下，您将所有内容降级并清除设置).

   • 上一个答案:

   • 获得此类自定义操作的排序，模拟(您在其中运行的用户/系统上下文)和调节的权限是一点也不小.

   • 作为涉及到的复杂性的具体示例，这是先前的问题/解答，其中已实现了这样的功能，并且在确定到底发生了什么方面存在问题: VBScript条件测试器 .从本质上讲，它是一种自定义条件的自定义操作的对话框方法-它在现实生活中显示自定义操作运行时没有任何日志记录或复杂的调试.

   • 只需以不同的模式运行安装程序，然后查看是否看到对话框: install ， uninstall ， 修改 ， 修复 ， 修补 ， 主要升级 ， 暂停的简历 ...

4. 从部署中删除设置文件 :这是我最喜欢的选项，尽管听起来可能有些奇怪.可以使您的设置笨拙"且不那么复杂的任何事物，都会使其在实际使用中更加可靠.

   • 基本上，在安装后要更改的文件根本不应该安装，而应由应用程序生成或从模板文件复制到要更改的位置.

     • 在这些情况下，没有部署问题将不会干扰您宝贵的设置文件-除非您进行了怪异的自定义操作(您不应该这样做).

     • 您的设置不知道这些设置文件是否存在，因此将始终被保留.通常是您想要的.

     • 您可以创建自己的清理功能，以在卸载时将其删除，尽管我的建议是不理会它们:它们是用户数据.

   • 在此答案中，我将介绍与每个用户和设置文件部署相关的一般问题:

   • 在某些情况下，您可以使用应用程序内部默认值代替设置文件-消除所有部署注意事项.

   • 最后，您可以从网络中检索设置(数据库)，而不使用旧式的设置文件.

实用建议 :如果可以，请使用数据库进行设置或使用某种形式的模糊方法来获取设置文件.部署您的仅二进制文件！以及启动时进行设置文件或注册表设置所需的模板.这将极大地简化您的设置.

---

链接:

• 另一面:文件未正确覆盖

I have installed the .exe application (Say, Version 1.0). After installing the application, I can see several DLL's and few .XML config files in my local path(C:\Program Files (x86)). Now after kicking the new build and installing it I do not want to override the existing XML file alone in my local path. Is there any way to do it?

My EXE is created using WIX installer and the project is built in Visual Studio 2015.

解决方案

How does your application work? Does it write settings to these XML files over time, and you hence want to preserve them? If so, where are they stored? In a per-machine or per-user location?

Let me try to describe some problems for you that you are likely to face - and you could not possibly foresee ahead of time (without testing).

Some details about file overwriting

1. File versioning rules: MSI has built-in support to not overwrite non-versioned files that have been modified since installation (the create and modify dates are different). These are "File Versioning Rules". They are somewhat complicated and strange - you should definitely read the linked content - the real McCoy. So modified non-versioned files should not be replaced during updates - but there are many complications and bear-traps - and most people seem to fall into one of them.

2. Major upgrade file reversion: Perhaps the most common complication seen for "unexpected file overwrite" is not an overwrite at all. It relates to major upgrades - or installing your next product version if you like.

   • If you use a major upgrade to install your next version, and you schedule RemoveExistingProducts early in the InstallExecuteSequence, then all files are actually uninstalled and then reinstalled in their original version. They will appear to have been overwritten, but they have been uninstalled and then installed "fresh" instead.

   • This is all due to the very strange decision that MSI will happily uninstall modified files, even if they qualify to not be overwritten. What you need is a way to define the files to not be uninstalled at all. Which brings us to the next point:

3. Permanent and Never Overwrite Flags: Each component has two important settings relating to file overwrite and file preservation: the never overwrite flag and the permanent flag. This is indeed a good way to indicate that a file should not ever be replaced, nor uninstalled. However...

   • Setting only the never overwrite flag will not help against the major upgrade problem described above, the file is still uninstalled and then reinstalled so it appears overwritten (but is reverted).

   • If you set the permanent flag only, the file will be overwritten according to the File Version Rules - provided no modification is specified at the command line using features such as REINSTALLMODE (see section below). (I will need to verify this again to be 100% sure. There are many factors: component can be set permanent in older or newer setup only - or in both setups, major upgrade can uninstall early or late, REINSTALLMODE has many flavours, etc... Each variable can change the overwrite behavior)

   • In other words setting both the permanent and never overwrite flags is recommended to protect settings files.

4. REINSTALLMODE: REINSTALLMODE is a "modifier" or disabler of the File Overwrite / Versioning Rules (symantec). It is possible to set the REINSTALLMODE property during installation equal to amus - which will (among other things) force overwrite all files during installation regardless of the above mentioned file version rules.

   • Explanation of the amus REINSTALLMODE parameters:

     • a - Force all files to be reinstalled, regardless of version
     • m - Rewrite all registry keys that go to HKLM or HKCU
     • u - Rewrite all registry keys that go to HKCU or HKEY_USERS
     • s - Reinstall shortcuts and icons

   • One of these days I will write up issues with REINSTALLMODE and its implementation. It is an incredibly destructive concept in MSI, and it should never, ever be used. The problem is that this is a generic command line that can be passed to any MSI package and applies for the whole setup (why couldn't it at least be per feature?). I want to make my packages abort if amus is specified. Let me jot down quickly a few of the issues:

     • Downgrade: Can downgrade shared files system-wide. The files can come from merge-modules so people might not realize they target system folders. Windows 10 protects its OS-files pretty well now, but there are other files that can still be downgraded without OS-protection.
     • Inconsistent Versions: Can cause inconsistent version estate since an old package can be installed after a newer one and downgrade only some of the shared files.
     • Settings Wipe-out: Can downgrade or wipe-out settings in non-versioned files (and registry settings).
     • Reboot Prompts: 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 features to avoid this, but they are often not used correctly. Restart Manager, more on restart manager.
     • And then there was more...: There are several further issues that are quite specific. One day I will write them all up. I think. Maybe not? :-).
       • Windows File Protection (WFP): Maybe I can add that certain legacy merge modules contain files that are now protected by the OS, and trying to replace them used to potentially trigger a runtime error. This is now handled by Windows 10 "silently".
       • Registry: The m and u switches of amus will reset registry data written by components (and not custom action code) outright irrespective of the a switch (At least this was the case last time I tried). High on my MSI anti-pattern list (see section "Potential Anti-Patterns").
       • Unknowns : GAC, WinSxS. I don't even known how things work with the GAC? Side-by-side is un-downgradable by design? One would think. Unless you poke around inside the assembly folder directly - which hopefully will trigger a runtime error - which I have not tried. In fact I don't think it will. See this issue with publisher configuration files (see all tweets in "thread").

This is all slightly mad to be honest, but it is how the technology works. So, let us stop complaining and try to deal with the problem. What are the options to deal with this?

Some options to deal with settings file-preservation issues

In summary I suppose you have a couple of options:

1. Use minor upgrades to upgrade your application. Then your files are never prone to be uninstalled and reinstalled and hence be reverted like they are for major upgrades.

   • A minor upgrade does not uninstall the existing installation - it upgrades it directly. Regular file versioning rules apply (modified non-versioned files are not replaced) - unless REINSTALLMODE is used to modify this logic.

   • However, few people succeed with minor upgrades only - they are too restrictive and limited. Close to none I would say.

2. Use a major upgrade with RemoveExistingProducts early in the InstallExecuteSequence and permanent and never overwrite enabled for the components hosting your settings files. When using a major upgrade the main choice is between early and late uninstall of the old version, and this choice has huge implications.

   • This section needs some cleanup. Will happen soon.... December 2019: and we are back. Years later. Some minor cleanup happened today - not much else. I shall keep promising to clean this up more. Empty promises makes the world go round and round. If this all seems like complaining, please read the major benefits of MSI (quick list). MSI delivered crucially important improvements to previous deployment technologies, but has a few big challenges left.

   • Early uninstall means that any component referencing errors you have made shouldn't cause any problems. They are more "forgiving" if you like. A lot of people end up using this approach specifically because is the most "forgiving" of component referencing errors and overall "robustness".

   • Early uninstall also means that modified files can be uninstalled and reinstalled during the upgrade, causing them to appear overwritten, but they are reverted (described above).

   • A remedy for the above problem is to set the hosting components for files to be permanent and never overwrite.

   • Early uninstall means that the complex component creation rules can be broken and your upgrade will still work. It is very common to break the component creation rules. If you use this approach you should set the files you want to preserve during upgrades to permanent and throw in never overwrite too. This should prevent the problem where modified files get uninstalled and fresh files are installed - yielding the impression that the files have been overwritten.

3. Use a major upgrade with RemoveExistingProducts late in the InstallExecuteSequence.

   • Late uninstall major upgrade installations do not uninstall and reinstall files that exist in the same location in the old and the new setups - and this works even when the files in question are not set permanent and never overwrite (allowing proper uninstall of the files as well - without any added, custom logic).

   • This kind of upgrade basically install as a "patch" - leaving files that are unchanged between releases untouched, and then upgrading other files according to the File Versioning Rules described above.

   • Rather they will be overwritten based on the normal file versioning rules (provided you did not set the REINSTALLMODE equal to amus - in which case you downgrade everything and wipe out settings).

   • Previous answer: How to keep a config file when major upgrade in wix v3.8?.

4. Custom backup mechanisms for settings files: many end up implementing complex custom actions that back up settings files and put them back in place after the installation has run.

   • I don't like this approach due to its potential for custom action failures, but many use this option. Often this is a feature added in version 2 of an application since the files in question were not set permanent and "never overwrite" in the setup for version 1.

   • Getting the sequencing, impersonation (user / system context you run in) and conditioning right for such custom actions is not at all trivial.

   • As a concrete example of the complexities involved, here is a previous question / answer where such a feature has been implemented and there are problems determining exactly what is going on: Wix Tools update uses old custom actions.

     • Complexity: Very complex conditioning is going on to make the backup and restore operations happen at the right time in different installation modes (fresh install, upgrade, repair, modify, etc...)

     • Condition Debugger Light (practical tip!): To work out the complicated conditions I like to go very concrete with real-world testing of the conditions instead of too much analysis (yes, you will fail anyway - somehow).

       • Here is the overall approach I use: VBScript condition tester. It is in essence a dialog box approach from a custom action that is conditioned - it shows in real life WHEN the custom action runs without any logging or complex debugging.

       • Just run the setup in different modes and see if you see the dialog: install, uninstall, modify, repair, patching, major upgrade, suspended-resume...

5. Eliminate settings files from deployment: this is my favorite option, although it may sound a bit strange. Anything that can make your setup "dumber" and less complex will make it more reliable in actual use.

   • Essentially files that are to be changed after installation should not be installed at all, but generated by the application or copied from template files to the location where they are to be changed.

     • In these scenarios no deployment issues will ever interfere with your precious settings files - unless you make a weird custom action to do so (which you shouldn't).

     • Your setup has no knowledge that these settings files exist, and they will hence always be left alone. Which is very often what you want.

     • You can make your own cleanup feature to delete them on uninstall, although my advice would be to leave them alone: they are user data.

   • I write about the general problems related to per-user and settings file deployment in this answer: Create folder and file on Current user profile, from Admin Profile. Please have a quick skim at least, to see if you can improve your deployment by killing complexity rather than embracing it.

     • Essentially there are various ways to deploy settings and user files in a setup (Active Setup, self-repair, etc...).

     • Then there are template files that you can "instantiate" and keep out of your setups (no interference as described above).

     • You can use application internal defaults instead of settings files in some cases - eliminating all deployment considerations.

     • And finally you can retrieve settings from the network (database) instead of using old-style settings files.

Practical Advice: If you can, do use a database for your settings or some form of clouded approach to get settings files OUT of your setup. Deploy your binaries only! And the templates needed to make settings files or registry settings on launch. That will help tremendously to simplify your setup.

---

Links:

• The other side of it: files not overwriting properly

这篇关于安装.exe文件时不要覆盖现有文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！