vb.net - Windows应用程序的在线注册安装程序

Question

我们使用Visual Studio 2013在vb.net中开发了一个软件。现在，我们要构建具有以下步骤/功能的自定义安装程序:

用户开始安装我们的软件。

在“输入序列号”选项中，用户输入我们提供的16位序列号。

单击“确定”按钮时，我们的软件将连接到我们的IP，并将串行密钥以及其他一些用户的信息保存到我们的数据库中。

确认密钥将返回到我们的软件。

Software写入文件并将其保存到系统文件夹中。

这几乎类似于Adobe或Corel的注册过程。
我们对其他技术也持开放态度，这些技术也必须确保我们的软件只能安装在一台计算机上。
请注意，我们是一群新手程序员(不是那么高级)。如果详细说明该过程，将对我们非常有帮助。

Answer 1

One-Shot Setups: "A setup is run once, an application can be started again - in order to resolve and debug problems interactively - with meaningful error messages show to the user."

Hence: avoid license validation in the setup.

Short version on licensing。

License Key: Preferring to deal with license keys in your application seems logical for several reasons: the one-shot nature of setups yields poor reliability (no interactive debugging - poor ability to resolve problems). The end result is lots of support calls for something very trivial.

Further, the risk of piracy and hacking is a major concern when exposing a license validation DLL in the setup. And finally communication over the Internet is difficult with today's setups (proxies, firewalls, etc...) - which is a modern way to validate license keys (in the future setups might have full Internet access, but be careful assuming too much since corporate users may have lots of restrictions and poor deployment could hurt sales and acceptance of the software for corporate use).

Finally your application must usually support a trial version, and then you need a license dialog in your application anyway. Why complicate your setup too?

CAs: Custom actions are complex and vulnerable to failure in general - due to complex sequencing-, conditioning- and impersonation issues and overall poor debugability. More information: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?

Overall Complexity of Deployment: A short, attempted summary of the overall complexity of deployment: Windows Installer and the creation of WiX (section "The Complexity of Deployment").

我将从设置中删除所有许可功能，并将它们添加到应用程序中。您的安装程序仍可以通过将许可证作为传递给 msiexec.exe 到磁盘或注册表中，来写入许可证-
大写属性(或者您可以通过使用转换来应用串行属性来“隐藏”更多内容-它与在命令行上设置属性的效果完全相同)。 交互式运行时，您也可以从安装程序对话框中设置LICENSE属性，但是我最喜欢的方法是允许在静默部署模式下将未经验证的许可证密钥添加到注册表中，而是直接在交互式部署的应用程序而不是安装程序(上面的描述是静默部署的):

msiexec.exe /I "C:\Install.msi" /QN /L*V "C:\msilog.log" LICENSE="123-456-789"

这将允许将许可证轻松添加到公司部署方案中的每台计算机上。许可证值只是简单地写入磁盘或注册表中，无需验证。应用程序将对其进行验证(比安装程序中的验证dll更安全)。

无需弄乱任何复杂设置对话框，但是您需要在应用程序中创建一个许可证对话框，如下所述。

作为安装程序开发人员，您应该提供帮助在应用程序中而不是安装程序中实现该功能，因此这似乎不是“传递buck ”的情况。所有这些都是为了整体软件的可靠性和万无一失-以下列出了几个原因。

几乎所有大公司都以静默方式部署MSI文件，因此无论如何大多数时候都会忽略设置GUI。如果您在设置中处理许可证，那么您只是在增加风险并浪费资源。

一个缺点:安装后以非管理员用户身份运行的应用程序无法写入 HKLM 以在计算机上的所有用户之间共享序列(可以运行具有提升权限的安装程序)。它必须写入 HKCU ，或者安装程序必须具有对注册表中特定HKLM位置的写访问权限，以便应用程序可以写入。我更喜欢为每个用户写HKCU，因为这样许可证就不那么可供他人复制了，并且被保留为用户特定的数据(允许漫游，尽管这是大多数IT专业人员讨厌的功能)。但是，由应用程序或安装过程中的安装程序编写的HKLM许可证密钥(如上所述，带有公共(public)属性集)允许所有用户在启动应用程序时共享许可证。

有许多更具体的原因可以防止许可证处理和验证不符合您的设置:

总是有大量的支持请求来自于在设置中注册许可证密钥有困难的人。 设置运行一次，如果出现问题，可以再次启动应用程序。这比您对于没有经验的用户所想的更为重要。您还可以使用更好的功能处理异常和错误条件，以及应用程序中可能发生的任何意外问题。

安装程序中的串行验证公开了一个容易被海盗破解的验证dll /方法。您不会通过从设置中删除盗版来防止它，但至少会使它更加困难。如果您隐瞒某些事情(静态链接，加密，混淆，使验证过程联机和/或我不熟悉的安全专业人员所做的任何事情)，则它在应用程序中更安全。

允许应用程序试用版:如果安装程序需要支持应用程序的试用版，则如果用户最终购买了产品，则应允许用户输入许可证密钥-最好不必重新运行安装程序或仅添加许可证密钥即可卸载/重新安装。换句话说，无论如何，您可能需要处理应用程序中的许可，为什么还要使您的设置复杂化？ 风险更大，质量保证更高，潜在的支持请求更多，并且有可能在设置和应用程序中进行多项必需的修复。总费用高吗？

如果您的应用程序与不同版本的一起运行，那么如果用户购买了升级许可证怎么办？他们应该只能够将其输入到许可证对话框中，并在可能的情况下解锁功能，而不是卸载并重新安装所有涉及的旧文件。对于某些升级而言，这很难实现，并且您通常最终会得到针对不同版本的单独设置。

如果网络使用代理服务器进行Internet访问，则在设置过程中(通常由市场要求)在Internet上注册许可证会遇到问题。您可以在应用程序中检查和处理更多功能-它可以重试并等待访问(通常，如果可能的话，您会挂接到IE以进行自动代理配置)。对于公司部署，您还需要一个静默安装选项，该选项不会验证密钥，而只是将其写入注册表。在我看来，尝试通过无提示安装MSI来访问Internet 是一种相当极端的部署反模式。我在安装GUI中也发现了这个问题。在应用程序中进行注册-争议较小，并且您可以设置防火墙规则以允许其访问Internet(由于充分的原因，msiexec.exe可能会被阻止)。如果没有笨拙的管理服务器配置，可能还会有硬件防火墙和/或安全软件要处理，这使Internet访问变得困难甚至无法实现。 :根据我的经验，这可能会导致您的软件无法使用。:“只要摆脱我们的网络和应用程序的限制-必须有更好的选择-太笨拙且容易出错”。

更新:随着部署技术的成熟和变得更加“基于Internet”，这种“真实性”可能会发生变化，例如，我们最终可能会通过专门设计用于通过在线“存储库”运行的部署来进行“在线”所有操作。我们将不得不拭目以待。就目前而言，我认为任何设置Internet访问要求都是错误且不受欢迎的。

与许可证混淆的设置有时会由于安装中的错误而在升级，修补和迁移方案期间删除许可证数据。有时这比您想像的要严重得多-该程序包可能会碰到大型公司中的数千个工作站，并且难以解决。

MSI技术本身存在一个非常糟糕的“反模式”，通过这种方式，自修复或手动触发的修复将重置应用程序已更改的注册表中的值。这样可以清除许可证密钥。我们一直在看到这种情况，这是技术的错。在这方面只是不合逻辑的。

对此有一些修复-或更确切地说是变通办法(使用永久性组件，通过自定义操作而不是从组件中编写许可证，等等)，但是我发现它们很笨重，您必须进行很多操作体验所有陷阱的经验-甚至是经验丰富的用户都将其弄乱了。

许可是公司的头疼问题-公司通常希望将许可集中管理在服务器上，而不是完全基于文本序列号(例如，通过以下方式在应用程序启动时获取并发或 float 许可)网络)。仅提及这一点，尽管超出了该问题的范围。在这些情况下，您在安装过程中指定的通常是指向许可证服务器的IP地址，或者是由 public property 或 WINS 解析的常规主机名。