部署是大多数开发的关键部分.请给这个内容一个机会.我坚信,通过应用程序设计的微小变化可以大大提高软件质量,使部署更加合理,更可靠 – 这就是“答案”的全部 – 软件开发.
这是一个Q / A风格的问题,从一个过长的答案中分离出来：How do I avoid common design flaws in my WiX / MSI deployment solution?.
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配置他们自己的公司范围的云,他们可以完全控制所有设置,还可以强制执行软件操作的强制性策略和限制.更不用说适用于所有用户设置的正确备份.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。