每台机器应用程序注册

Question

我正在使用WiX构建一个安装程序来安装程序，每台机器（不是每个用户），并且它为他们提供了注册程序的选项。注册涉及输入用户名和组织（或接受Windows设置的某些默认值），并输入有效的注册密钥。验证注册密钥后，我使用此信息在HKEY_LOCAL_MACHINE区域中编写注册表设置。在Windows下，当运行MSI时，它会自动提示输入管理员密码，以便能够在HKEY_LOCAL_MACHINE中设置注册表值。到目前为止生活还不错......

我在MSI中包含一个选项，让用户可以选择将注册推迟到以后的某个时间点。但是，如果用户是普通用户并且他们正在运行应用程序，如果我在应用程序中有一个提示输入name / org / product-key的对话框，则Windows不会将该信息写入HKEY_LOCAL_MACHINE。因此，用户无法像普通用户一样使用应用程序本身来执行MSI在提示输入管理员凭据后执行的每台计算机注册。

我的想法是，对于安装后注册，要么（a）从应用程序中找到提升权限的方法，并提示管理员凭据，允许它写入HEKY_LOCAL_MACHINE（这可能吗？），（ b）在安装程序中包含一个选项，该选项在运行且应用程序已安装且未注册时，按照正常安装期间的方式完成注册。然后它会提示输入管理员凭据并且生活再次良好。或者，（c）创建一个单独的MSI，只进行注册，将其与程序一起安装，并在用户选择程序中的“Register ...”命令时从程序中调用该MSI。

我之前没有看到过这些方法中的任何一种，所以我不确定这两种方法是不是很好。除此之外，我不确定在安装后，我可以方便地允许用户进行每台机器应用注册。理想情况下，我希望能够从应用程序中的命令执行此操作，但重新运行安装MSI将是最低限度的可接受。

这通常是怎么做的？或者每台机器的安装是否通常伴随着每台机器的注册？

Answer 1

非常好的问题 - 我自己多次处理过这个问题。没有理想的解决方案，但有几种选择（正如您已经发现的那样）。

在回答之前，我想指出，我强烈反对在设置本身中进行过多的注册和配置。它很容易出错，并且在应用程序本身中做得更好，原因很多： Installer with Online Registration for Windows Application （建议快速阅读 - 来自现实生活经验的花絮）。

写信给HKCU

如您所知，一种选择是仅在HKCU中保留许可证密钥和注册。除非您想在盒子上的许多用户之间共享许可证密钥，否则这通常是可以接受的。许可证密钥如果添加到HKCU，通常也会与用户一起漫游到其他计算机 - 这可能是有帮助的或可取的。

就个人而言，这是我更喜欢的选项：不在设置中注册任何内容，而是从应用程序写入HKCU或用户配置文件（如上面链接中所述）。如上所述，唯一的缺点是您无法将共享许可证密钥写入HKLM，因此它适用于所有用户，而不仅仅适用于单个用户。 这似乎是您所描述问题的核心。

写信给HKLM

1. 安装程序写入HKLM ：在设置过程中将HKLM许可证密钥（和注册）写入HKLM，如上所述，使用默认的Windows Installer属性（仅列出此属性）作为一种选择 - 你已经知道了）。在我看来这应该可行 - 但你的问题似乎是允许延期注册＆＃34;。
2. 自定义HKLM ACL权限 ：为了从非提升的应用程序写入HKLM ，一种方法是使用您的设置将自定义ACL permissions应用于您希望从应用程序中编写共享注册表项的HKLM中的位置。然后，您的应用程序可以随时在HKLM中自由更新此特定位置，而无需提升权利。您只需为＆＃34;用户＆＃34;添加ACL写访问权限。
   • WiX支持此功能，但我没有为您提供样本please check the WiX documentation for permissioning。
   • 使用自定义权限通常不受欢迎（我同意这不是理想的设计），但它允许任何用户在安装后没有任何提升的情况下向HKLM添加许可证密钥（并且还允许任何用户删除它 - 可能是个问题）。
   • 有关为何一般不建议使用自定义权限的原因，请参阅此处的第14部分：How do I avoid common design flaws in my WiX / MSI deployment solution?
   • 总之，我一般不建议设置自定义权限，但肯定会有效。当客户要求是他们唯一会接受的时候，我自己做了。它将违反Windows应用程序的徽标要求，但它应该不如下面的选项3导致的安全问题严重。
3. 以管理员身份运行应用 ：如果您不想应用ACL权限，我相信您可以提示用户获取您的管理员权限这里描述的申请（我相信如果我理解正确，这就是菲尔在评论中提到的）： How do I force my .NET application to run as administrator?（传奇的Hans Passant - one more answer）。
   • 绝对不推荐（但我们希望向人们展示可能的内容）。您的整个应用程序将始终以管理员权限运行，这根本不是一个好主意。
   • 执行此操作将违反Windows应用程序徽标要求的关键部分，您还将打开应用程序，直至攻击恶意软件。
   • 绝对尽量让用户了解这个＆＃34;轻松修复的后果＆＃34;。如果他们选择这个选项，我会确保将所有责任都放在客户身上 - 他们必须明白他们在做什么。
   • 请注意，您应该能够使用此清单方法启动具有提升权限的单独EXE，以仅进行注册。见下一个要点。
4. 按需提升应用 ：我不熟悉在应用程序运行时按需提升应用程序的技术细节 - 当您调用需要的对话框或功能时HKLM访问。 也许菲尔知道实现这个目标的方法吗？我发现了一些链接：
   • Elevating during runtime（来自Code Project）
   • How to elevate privileges only when required?（好读）
   • 略过上面的链接内容，您似乎可以启动一个具有提升权限的单独EXE来进行注册 - 我认为这是一个众所周知的选项。
   • 如果这是您决定尝试的事情，我很乐意回复。对我们所有人都有用。
5. 互联网验证 ：只是抛出一个选项：我经常要做的是将整个注册许可证密钥验证放在应用程序内（从不，从设置中尝试这个，只是提到了 - 试图访问互联网的设置可能是最大的部署反模式 - 至少现在是这样。
   • 我从设置中编写许可证密钥，并在对Internet上的服务器启动应用程序时进行验证。然后，您的应用程序或设置中没有验证代码可以破解。
   • 你需要互联网＆＃34;握手＆＃34;并且您可以为每个用户重复此过程 - 允许您严格控制谁在使用您的许可证密钥。
   • 没有什么比这更容易了，代理服务器问题可能会导致问题。企业部署也意味着这样的＆＃34;在线激活＆＃34;不满意。他们希望在部署后完全安装应用程序。
6. 单独注册MSI ：我不想像您在问题中提到的那样仅为注册过程创建单独的MSI。这似乎是不必要的复杂性，可以轻松破解。首先，你得到一个必须永久维护的双源问题。我猜这可能会成为一个经典的支持问题。
7. 重新运行原始MSI ：老实说，我不确定重新运行您的原始设置进行注册是否会提升或不提升。我认为它会被提升（应该是，不能看到为什么它不应该 - MSI数据库存储一个标志来确定是否需要提升＆＃34; Word Count＆＃34 ;），然后您应该能够添加您的注册详细信息，前提是您从设置＆＃34; 修改＆＃34;访问注册对话框。或＆＃34; 修复＆＃34;模式。

Answer 2

这种注册通常使用标准的Windows Installer属性来完成，因此它可以正常工作。

如果您有验证密钥，则它通常与标准PIDKEY属性关联（在对话框中），然后在验证后成为ProductId属性。

https://msdn.microsoft.com/en-us/library/windows/desktop/aa370826(v=vs.85).aspx

同样，用户名和公司名称在对话框中与USERNAME和COMPANYNAME属性相关联。

在此之后，他们可以通过（Win32）MsiGetProductInfo（）通过询问RegOwner等来获取它们：

https://msdn.microsoft.com/en-us/library/windows/desktop/aa370130(v=vs.85).aspx

或类似的API（WMI执行其中一些操作）。

一般来说，您只需从对话框中设置属性即可，只需将其写入注册表即可。