每台机器的应用程序注册 [英] Per Machine App Registration
问题描述
我正在用WiX构建一个安装程序，以便按机器(而不是按用户)安装程序，它为他们提供了注册程序的选项.注册涉及输入用户名和组织(或接受Windows设置的某些默认设置)，以及输入有效的注册密钥.验证注册密钥后，我将使用此信息在HKEY_LOCAL_MACHINE区域中写入注册表设置.在Windows下，当运行MSI时，它会自动提示输入管理员密码，以便能够在HKEY_LOCAL_MACHINE中设置注册表值.到目前为止，生活还不错...
I'm building an installer with WiX to install a program, per machine (not per user), and it gives them the option to register the program. Registration involves entering user name and organization (or accepting some defaults from Windows settings), and entering a valid registration key. When the registration key is validated, I write registry settings in the HKEY_LOCAL_MACHINE area with this information. Under Windows, when one runs the MSI, it prompts automatically for an admin password to be able to set registry values in HKEY_LOCAL_MACHINE. So far life is good...
我在MSI中包含一个选项，使用户可以选择将注册推迟到以后的某个时间点.但是，如果用户是普通用户并且正在运行该应用程序，则如果我在应用程序中有一个对话框提示输入名称/org/product-key，则Windows不会将该应用程序将信息写入HKEY_LOCAL_MACHINE.因此，用户无法像普通用户一样使用应用程序本身(以普通用户身份运行)来执行每台计算机的注册，就像在提示输入管理员凭据后MSI所做的那样.
I am including an option in the MSI to give the user the option to defer registration until a later point in time. However, if the user is a normal user and they are running the application, if I have a dialog in the app which prompts for name/org/product-key, Windows doesn't the app to write the information to HKEY_LOCAL_MACHINE. So a user cannot use the application itself, running as a normal user, to perform a registration per-machine as the MSI does after prompting for admin credentials.
当时我的想法是，为了进行安装后注册，可以(a)在应用程序内找到一种方法来提升特权，并提示输入管理员凭据，从而允许其写入HEKY_LOCAL_MACHINE(这可能吗?)，( b)在安装程序中包含一个选项，该选项在运行且应用已安装且未注册时，将像在正常安装过程中那样逐步进行注册.然后，它将提示您提供管理员凭据，并且生活再次愉快.或者，(c)创建一个仅进行注册的单独的MSI，将其安装在程序中，并在用户在程序中选择"Register ..."命令时从程序中调用此MSI.
My thought then was, for post-installation registration, to either (a) find a way from within the application to elevate privileges, with a prompt for admin credentials, allowing it to write HEKY_LOCAL_MACHINE (is this possible?), (b) include an option in the installer that, when run and the app is already installed and not registered, walks through the registration as it would during a normal install. It would then prompt for the admin credentials and life is good again. Alternatively, (c) create a separate MSI that just does registration, install this with the program, and call this MSI from the program when the user selects the "Register..." command in the program.
我以前从未见过任何应用程序完成过这两种方法中的任何一种，因此我不确定这两种方法是否是一种好方法.但是除此之外，我不确定安装后如何，我可以方便地允许用户进行每台计算机的应用程序注册.理想情况下，我希望能够从应用程序内的命令执行此操作，但是重新运行安装MSI几乎是可以接受的.
I've not seen either of these approaches done by any applications before, so I'm not sure either is a good approach. Other than that, however, I'm not sure how, post-installation, I can conveniently allow the user to do a per-machine app registration. Ideally, I'd like to be able to do it from a command within the app, but re-running the installation MSI would be minimally acceptable.
通常如何完成?还是每台机器的安装甚至通常都伴随着每台机器的注册?
How is this normally done? Or are per-machine installations even normally accompanied by per-machine registrations?
推荐答案
很好的问题-我本人已多次处理此问题.没有理想的解决方案，但是有几种选择(如您所知).
Very good question - I have dealt with this issue many times myself. No ideal solutions, but several options (as you have already discovered).
在回答之前，我想指出，我强烈反对在安装程序本身中进行过多的注册和配置.它易于出错，由于多种原因，它在应用程序本身中要好得多:
Before answering, I want to point out that I have a strong aversion against doing too much registration and configuration in the setup itself. It is error prone, and much better done in the application itself for a plethora of reasons: Installer with Online Registration for Windows Application (recommended quick read - tidbits from real life experience).
您已经知道，一种选择是仅将许可证密钥和注册保留在HKCU中.除非您希望在包装盒上的多个用户之间共享许可证密钥，否则这通常是可以接受的.如果将许可证密钥添加到HKCU，通常也会与用户一起漫游到其他计算机上，这可能会有所帮助或期望.
As you already know, one option is to keep the license key and registration in HKCU only. This is often acceptable unless you want to share a license key between many users on the box. The license key, if added to HKCU, will also generally roam with the user to other computers - which can be helpful or desirable.
我个人更喜欢这种选择:不在安装程序中注册任何东西，而是从应用程序写入HKCU或用户配置文件(同样在上面的链接中进行了说明).如前所述，唯一的缺点是您不能向HKLM写一个共享许可证密钥，因此它适用于所有用户，而不仅是单个用户. 这似乎是您要描述的问题的核心.
Personally, this is the option I prefer: not registering anything in the setup, but writing to HKCU or the user-profile from the application (as explained in the link above as well). As stated, the only drawback is that you can't write a shared license key to HKLM so it applies to all users and not just a single user. This appears to be the core of the problem you are describing.
- 安装程序写入HKLM :如上面Phil所述，使用默认的Windows Installer属性将安装过程中的HKLM许可证密钥(和注册)写入HKLM.作为一种选择-您已经知道).我认为这应该可以正常工作-但您的问题似乎是允许推迟注册".
- 自定义HKLM ACL权限 :要从非高架应用程序写入HKLM ，一种方法是使用您的设置应用自定义 ACL权限到HKLM中您要从应用程序写入共享注册表项的位置.然后，您的应用程序可以随时在没有提升权限的情况下自由更新HKLM中的此特定位置.您只需添加 ACL 为用户"写访问权限.
- WiX支持此功能，但没有可供您使用的示例，如何避免WiX/MSI部署解决方案中常见的设计缺陷?
- 总而言之，我一般不建议设置自定义权限，但是肯定可以.当客户需求如此之高时，我本人亲自完成了这项工作，这是他们唯一会接受的事情.它会违反Windows应用程序的徽标要求，但它的严重性应低于以下选项3引起的安全性问题.
- Setup writes HKLM: Write the HKLM license key (and registration) during the setup to HKLM as Phil has described above using the default Windows Installer properties (just listing this as an option - which you already know about). This should work OK in my opinion - but your issue seemed to be to allow the "deferred registration".
- Custom HKLM ACL permissioning: In order to write to HKLM from your non-elevated application, one way to do it is to use your setup to apply custom ACL permissions to the location in HKLM where you want to write the shared registry key from your application. Your application can then freely update this specific location in HKLM at any time without elevated rights. You simply add ACL write access for "Users".
- WiX supports this, but I don't have a sample for you available, please check the WiX documentation for permissioning.
- Using custom permissioning is generally frowned upon (and I agree it is not ideal design), but it allows any user to add a license key to HKLM without any elevation after the install (and also allows any users to delete it - which can be a problem).
- See section 14 here for a quick description of why custom permissioning is not generally recommended: How do I avoid common design flaws in my WiX / MSI deployment solution?
- In summary, I don't generally suggest setting custom permissions, but it will definitely work. I have done it myself when client requirements are such that this is the only thing they will accept. It will violate logo requirements for Windows applications, but it should be less serious than the security issues that result from option 3 below.
- 绝对不推荐这样做(但我们也想向人们展示一切皆有可能).您的整个应用程序将始终具有管理员权限，这根本不是一个好主意.
- 这样做将违反Windows应用程序徽标要求的关键部分，并且您还将打开应用程序以遭受恶意软件的攻击.</li>
- 绝对要使您的用户理解此轻松修复"的后果.如果他们选择此选项，我将确保对客户承担全部责任-他们必须了解自己在做什么.
- 请注意，您应该能够使用此清单方法启动具有提升权限的单独EXE，以仅执行注册.请参阅下一个要点.
- This is most definitely not recommended (but we want to show people what is possible too). Your whole application will run with admin rights all the time, which is not a good idea at all.
- Doing this will violate a key part of logo requirements for Windows applications and you will also open your application up to attack from malware.
- Definitely try to make your users understand the consequences of this "easy fix". I would make sure to put all responsibility on the client if they go for this option - they must understand what they are doing.
- Note that you should be able to use this manifest approach to launch a separate EXE with elevated rights to do only the registration. See next bullet point.
- 在运行时升高(来自Code Project)
- 如何仅在需要时提升特权?(阅读全文)
- 跳过上面的链接内容，看来您可以启动具有提升权限的单独EXE进行注册-我认为这是您已知的选择.
- 如果您决定尝试这种方法，我们很乐意回覆.对我们所有人都可能有用.
- Elevating during runtime (from Code Project)
- How to elevate privileges only when required? (good read)
- Skimming the linked content above, it seems like you can launch a separate EXE with elevated rights to do your registration - a known option for you I assume.
- Would love to hear back if this is something you decide to try. Could be useful for all of us.
- 我从设置中写入许可证密钥，并在针对Internet上的服务器启动应用程序时对它进行验证.然后，您的应用程序或设置中无需验证代码即可破解.
- 您需要Internet握手"，并且可以为每个用户重复此过程-从而可以严格控制谁在使用许可证密钥.
- 没有什么比这容易的了，代理服务器问题可能会引起问题.企业部署还意味着这种在线激活"是不受欢迎的.他们希望在部署后完全安装应用程序.
这篇关于每台机器的应用程序注册的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
