为什么在使用 MSI 时将文件部署限制到用户配置文件或 HKCU 是个好主意? [英] Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?
问题描述
为什么将文件从我的 MSI 或设置文件部署到用户配置文件或 HKCU 是个好主意?
<小时>部署是大多数开发的关键部分.请给这个内容一个机会.我坚信，软件质量可以通过应用程序设计中的微小变化来显着提高，从而使部署更合乎逻辑和更可靠 - 这就是这个答案"的全部内容 - 软件开发..p><小时>
这是一个问答式的问题，从一个太长的答案中分离出来:如何避免我的 WiX/MSI 部署解决方案中的常见设计缺陷?.
如上所述本部分是从现有答案中拆分出来的，范围更广:如何避免我的 WiX 中的常见设计缺陷/MSI 部署解决方案?(旨在帮助开发人员做出更好部署决策的答案).
<小时>9.过度使用每用户文件和注册表部署.
某些应用程序无法为计算机上的所有用户正确运行，因为安装期间添加的用户特定数据未正确添加到其他用户的配置文件和注册表中.换句话说，该应用程序仅适用于安装该软件的用户.这显然是一个严重的设计错误.
有几种方法可以解决"这个问题，但为每个用户部署文件和设置的整个问题有点混乱，原因有几个:
- 如何引用多次安装的计数组件?(针对机器上的每个用户)
- 卸载时如何处理已安装的数据和设置?
- 您如何处理要安装的新文件和设置，这些文件和设置与磁盘和注册表中的文件和设置不同，并且用户进行了更改?确定不会自动覆盖?
没有真正明确的答案，但有几种替代方法来处理问题".我的首选选项是 2 &3 因为我认为 Windows 安装程序不应该部署、跟踪或尝试修改或更糟的是，完全卸载用户数据和设置 - 这是不应该干预的用户数据:
9.1 使用 Windows Installer 自我修复或类似方法
第一个选项是通过设置本身或类似设置的功能来正确部署设置和文件以及 HKCU 注册表项.有两种主要方法可以做到这一点:依靠通常由广告快捷方式触发的 Windows Installer自我修复"，或使用 Microsoft Active Setup.
当您启动一个快捷方式来启动您的应用程序时会发生自我修复，Windows Installer 会启动，并且您会在安装某些东西"时看到一个进度条.通常添加的是 HKCU 注册表项和用户配置文件.
还有另一种方法可以实现这一点，它被称为 Active Setup 也是 Microsoft 的一项功能.它实质上注册了可运行的东西"，以便每个用户在登录时运行一次.这可用于设置每个用户的数据.Active Setup 允许执行任何可运行的" - 对于例如文件副本到用户配置文件..
这两个选项都意味着用户数据和设置被复制一次 - 从那时起它们通常不会被触及，但在自我修复"的情况下，任何用户可能会被卸载实际运行应用程序的卸载(除非设置不这样做).
虽然使用自我修复和 Active Setup 设置用户数据是让应用程序正常运行的既定"方法，但使用 Windows Installer 组件跟踪用户数据似乎是错误的.为什么?因为它是真正的用户数据，一旦初始化就不应被干预.
因此，我对整个问题的诚实看法是尽量避免完全部署用户特定数据或注册表项和值，这就是接下来描述的另外两个用户数据部署方法.
9.2 用户数据的应用初始化
第二种选择，也是我觉得更简洁的一种选择是更改您的应用程序可执行文件，以便能够根据从每台计算机位置复制的默认设置和模板或基于应用程序来初始化所有每用户设置和文件内部默认值(来自源代码)，而不是通过您的设置编写它们.
在这种情况下，Windows Installer 不会跟踪复制给每个用户的文件或设置.它被视为根本不应受到干扰的用户数据.这可以避免在升级和自我修复(以及手动卸载和重新安装)期间重置或覆盖用户数据等所有干扰.
如果在某些情况下必须对应用程序设置进行修复"，这可以通过让应用程序可执行文件在启动时更新每个用户的设置来实现，然后在注册表中标记更新已完成.
总体结论"是您的设置应该为首次启动准备应用程序，它不应该设置用户数据和设置环境.所有用户配置文件和 HKCU 设置都应该由应用程序默认，以防它们在启动时丢失 - 这会产生更强大的应用程序，也更容易为 QA 人员测试.这对于根本不允许运行自我修复的终端服务器尤其重要.在这种情况下，如果您依靠自我修复来放置用户数据，应用程序数据将会丢失.
9.3 用户设置的云"或数据库存储
在当今的云环境"中更进一步 - 我认为这是首选方案.为什么您的应用程序应仅限于文件和注册表项和值?为什么不将所有用户特定设置存储在解决方案的数据库中?
所有设置的完全访问、控制和持久性，完全没有任何部署问题.
不过，您确实会遇到新的管理问题，并且必须在开发人员、系统管理员和数据库管理员之间共享它们.但是，云现在还不是行业标准吗?
我们已经在漫游配置文件、损坏的用户注册表、错误处理的用户配置文件数据文件等问题上苦苦挣扎.......开发人员，为自己省去很多麻烦，为自己创建一些新的数据库管理问题而不是部署问题 - 开始对一群全新的人大喊大叫！:-).
数据库中的设置是:
没有遭受双源问题"的困扰.有一个实例，它是实时更新的.不像用户配置文件和漫游"中看到的同步问题.
可检查、可管理和可修补
可修改(版本控制 - 可以恢复旧设置)
您甚至可以通过在部署过程中运行数据库脚本来调整"您的设置中的所有用户设置，但如果您在公司环境中 - 不仅仅是提出票证然后让您的数据库管理员运行具有适当事务支持和回滚的维护脚本更有吸引力吗?
即使您正在交付一个大型、胖客户端供应商应用程序以供一般分发和第三方使用(换句话说，不是一个定制的企业客户端/服务器解决方案，保证您拥有一个后端数据库)，应该考虑通过让用户使用他们的电子邮件或类似方式登录到云，然后实时同步设置来考虑用户设置的云存储.
如此大的应用程序通常总是需要在计算机和 HKCU 中缓存"一些设置文件，但似乎越来越有可能将所有设置保存在用户配置文件区域中的单个临时文件中，这完全是牺牲"，甚至可以在损坏时删除，然后下载上次保存的设置.
显然可以使用公司 DBO 配置他们自己的公司范围的云，而不是自己托管云，他们可以完全控制所有设置，并且还可以强制执行软件操作的策略和限制.更不用说所有用户设置都可以正确备份.
Why is it a good idea to limit deployment of files to the user-profile or HKCU from my MSI or setup file?
Deployment is a crucial part of most development. Please give this content a chance. It is my firm belief that software quality can be dramatically improved by small changes in application design to make deployment more logical and more reliable - that is what this "answer" is all about - software development.
This is a Q/A-style question split from an answer that became too long: How do I avoid common design flaws in my WiX / MSI deployment solution?.
As stated above this section was split from an existing answer with broader scope: How do I avoid common design flaws in my WiX / MSI deployment solution? (an answer intended to help developers make better deployment decisions).
9. Overuse of per-user file and registry deployment.
Some applications won't run correctly for all users on a machine, because the user-specific data added during installation isn't correctly added to other user's profiles and registry. In other words the application just works for the user who installed the software. This is obviously a serious design error.
There are several ways to "fix" this, but the whole issue of deployment of per-user files and settings is somewhat messy for a few fundamental reasons:
- How do you reference count components installed multiple times? (for each user on the machine)
- What do you do with the installed data and settings on uninstall?
- How do you deal with new files and settings to install that differ from the ones that are on disk and in the registry and have user-made changes? Surely you don't overwrite automatically?
There are no real clear cut answers, but there are several alternative ways to deal with the "problems". My preferred options are 2 & 3 since I don't think Windows installer should deploy, track or attempt to modify or worse yet, uninstall user data and settings at all - it is user data that shouldn't be meddled with:
9.1 Using Windows Installer Self-Repair or similar
The first option is to get settings and files and HKCU registry keys deployed properly via the setup itself or setup-like features. There are two major ways to do this: relying on Windows Installer "self-repair" generally triggered by an advertised shortcut, or using Microsoft Active Setup.
Self-repair is what happens when you launch a shortcut to start your application, and Windows Installer kicks in and you see a progress bar whilst "something" is being installed. What is typically added are HKCU registry entries and user-profile files.
There is also another alternative to achieve this, it is called Active Setup and is also a Microsoft feature. It essentially registers "something runnable" to run once per user on logon. This can be used to set up per-user data. Active Setup allows "anything runnable" to be executed - for example a copy of files to the user-profile. .
Both of these options mean that the user data and settings are copied in place once - and from then on they are not generally touched, but in the case of "self-repair" might get uninstalled for any user who actually runs the uninstall of the application (unless the setup is designed not to do so).
Although setting up user data with self-repair and Active Setup are "established" methods to get applications running properly, it seems wrong to track user data with Windows Installer components. Why? Because it is really user data that shouldn't be meddled with once initialized.
Accordingly my honest take on the whole issue is to try to avoid deploying user specific data or registry keys and values altogether, and this is what is described next as two other user-data deployment methods.
9.2 Application Initialization of User Data
The second alternative, and one that I find much cleaner, is to change your application executable to be able to initialize all per-user settings and files based on default setting and templates copied from a per-machine location or based on application internal defaults (from the source code) instead of writing them via your setup.
In this scenario Windows Installer will not track the files or settings that are copied to each user. It is treated as user data that should not be interfered with at all. This avoids all interference such as reset or overwritten user data during upgrades and self-repair (and manual uninstall and reinstall).
If there are cases where "fixes" must be made to application settings, this can be achieved by having the application executable update the settings for each users on launch, and then tag the registry that the update has been completed.
The overall "conclusion" is that your setup should prepare your application for first launch, it should not set up the user data and settings environment. All user-profile files and HKCU settings should be defaulted by the application in case they are missing on launch - this yields a much more robust application that is easier to test for QA personnel as well. This is particularly important for Terminal Servers where self-repair is not allowed to run at all. In such cases the application data will be missing if you rely on self-repair to put user data in place.
9.3 "Cloud" or Database Storage of User Settings
To take things a step further in today's "cloud environment" - and this is in my opinion the preferred option. Why should your application be restricted to files and registry keys and values? Why not store all user specific settings in the solution's database?
Full access, control and persistence for all settings without any deployment issues at all.
You do get new management issues though, and they must be shared between developers, system administrators and database administrators. But isn't the cloud pretty much the industry standard by now?
We have been struggling long enough with roaming profiles, corrupted user registry, mishandled user-profile data files, etc.... Developers, save yourself a lot of trouble, and create yourself some new database management issues instead of deployment issues - and start yelling at a whole new bunch of people! :-).
Settings in databases are:
Not suffering from "dual source problems". There is one instance, and it is updated in real time. Not like the synchronization problems seen with user-profile and "roaming".
Inspectable, manageable and patchable
Revisable (version control - can revert older settings)
You could even "tweak" all the user settings from your setup still by running database scripts as part of deployment, but if you are in a corporate environment - isn't the thought of just raising a ticket and then have your database administrator run the maintenance scripts with proper transaction support and rollback much more appealing?
Even if you are delivering a large, fat-client vendor application for general distribution and third party use (in other words not a tailored, corporate client/server solution where you are guaranteed to have a back end database), one should consider cloud storage of user settings by having users log on to a cloud using their email or similar and then synchronize settings in real time.
Such large applications generally always need to "cache" some settings files on the computer and in HKCU, but it seems more and more possible to save all settings in a single temporary file in the user profile area which is entirely "sacrificial" and even possible to delete if it is corrupted and then download the last saved settings.
Instead of hosting the cloud yourself, it is obviously possible to use company DBOs to configure their own company-wide cloud where they have full control of all settings, and can also enforce mandatory policies and restrictions for your software's operation. Not to mention the proper backup that is possible for all user settings.
这篇关于为什么在使用 MSI 时将文件部署限制到用户配置文件或 HKCU 是个好主意?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
