0 windows windows-installer installshield installaware winforms
我以前使用过InstallAware和InstallShield，它们很难使用，当出现问题时很难找到并解决问题。
我的问题是为什么我们不能使用 C# 编写的 Windows 应用程序来执行此操作。我知道 .Net Framework 可能不会安装在目标计算机上，所以我想知道为什么没有人使用过这种架构：我将使用 IntallSiheld（或任何其他类似工具）创建一个简单的安装程序来安装 .Net Framework，然后它提取并运行我自己的 Windows 应用程序，该应用程序是我在提升模式下使用 C# 编写的。我的应用程序将运行一个带有“后退”和“下一步”按钮的向导，我将处理其中的所有内容（复制文件、创建和启动 Windows 服务、添加注册表值、创建防火墙扩展等）。有人曾经这样做过吗？有什么事情吗？阻止人们这样做？
本质上：不要尝试重新发明轮子。使用现有的部署工具并继续您的日常工作:-)。有很多这样的工具可用。请参阅下面的链接。
下面是长时间、重复的沉思：
Redux：恕我直言，恕我直言，如果我可以这么说的话，制作自己的安装程序软件就是重新发明轮子，我担心绝对不会有任何收获。我相信，当您创建自己的安装程序软件时，您会“重新发现”其他走过部署道路的人所发现的复杂性，并发现该软件可以快速制作，但很难完善。在这个过程中，你会花费大量的精力试图把事情包起来——而且“最后一米很长”，因为你咒骂自己处理一些琐事，这些琐事占用了你的时间，而牺牲了本来可以支付账单的费用。解决任何技术功能的工具包中的错误可能需要数年甚至数十年的时间。不，我不会弥补。这是所有部署软件供应商所处理的问题。
许多现有工具：已经有许多现有工具实现了此类部署功能 - 它们不基于 Windows Installer（ Inno Setup、 NSIS、 DeployMaster和其他许多鲜为人知的工作）：
我的 2 美分 - 如果您不喜欢 MSI，请选择一种免费的非 MSI 部署工具。如何创建 Windows 安装程序。
企业部署：（对我来说）真正重要的一点是企业部署依赖于标准化的打包格式（例如 MSI），以允许对软件部署进行可靠的远程管理。制作自己的安装程序不会给任何系统管理员或企业部署专家留下深刻的印象（至少在您解决多年的错误和缺陷之前）。他们想要他们知道如何处理的标准化格式（这并不意味着他们对现有的部署技术印象深刻）。使用标准化部署格式进行部署可以让您的软件得到公司的认可。如果您制作了一种奇怪的部署格式，在安装时执行不寻常的操作，并且无法轻松捕获和大规模部署，那么您的软件将在任何大公司中脱颖而出。没有怜悯——真的。这些都是繁忙的环境，您将很难理解您不寻常的解决方案。
“文件推送者”：我们这些以推送文件为生的人都知道，部署领域充满了愚蠢的问题，这些问题很快就会扼杀您在其他工作中的生产力 - 那些让您在自己的领域中脱颖而出的工作 - 您的日常工作。部署是一项高调、低地位的努力——我们并不抱怨。它就是这样：一种比你想象的更难处理的必需品。我的结论是，更明智地利用你的时间。
复杂性：也许可以浏览一下“部署的复杂性”部分： Windows Installer 和 WiX 的创建。处理部署中发生的所有愚蠢错误是令人惊讶的。它不仅仅是文件副本，尽管您可能很容易认为它是。如果它恰好只是一个文件副本，那么现有的工具可以完成这项工作。也有免费的。请参阅上面的链接。如果您认为部署通常只是文件复制，那么请浏览部署任务应能够支持的任务列表：程序安装的好处和真正目的是什么？
您的自制包装可以处理以下情况吗？（只是一些随意的想法）
对于您的要求来说，这有点过分了，但不要误以为部署是您可以在几个小时内找到解决方案的事情。并且绝对不要接受承诺这样做的工作 - 如果这是你被要求的。只是我的两分钱。
上述问题以及许多其他问题是人们在创建部署软件时必须处理的问题 - 除了最琐碎的部署之外的所有部署。不要浪费时间——使用一些成熟的工具。
事务：如果您在公司工作并且只需要将文件发送给测试人员，则可以使用批处理文件进行部署 - 如果您愿意的话。但你必须支持它，我向你保证这会花费你很多时间。当批处理文件由于网络错误而中途失败，并且您的测试人员正在测试不一致的文件时，您该怎么办？未来的部署技术可能更适合此类轻量级任务。也许部署工具的最大功能是报告部署是否成功完成，并记录错误并在出现故障时将计算机回滚到稳定状态。Windows Installer 会为您完成许多此类工作。
分发：很多人觉得他们可以“将我的构建文件夹复制到用户的计算机上”。这里涉及的复杂性有很多。涉及到网络，并且永远不能假设网络是可靠的，这里需要大量的错误处理。然后是事务的问题：你什么时候知道计算机何时处于稳定状态并且应该停止复制。您多久复制一次（仅按需复制）？您如何处理少数无法复制的计算机。你如何告诉用户？这些都是分配问题。公司拥有 SCCM 等大型工具来处理所有这些错误情况。尝试重新实施所有这些检查、日志记录和功能将需要很长时间。最后您将重新创建一个现有的分发系统。完整的循环。当由于只运行批处理文件或脚本而没有注册为已安装的产品时，您如何清点计算机？如果您开始复制大量包，您需要扫描每个文件多少次以确定它们是否是最新的？您想要创建多少网络流量？它在哪里结束？答案：我猜想事务必须通过完整的日志记录以及错误跟踪和回滚来实现。然后您就完成了我上面提到的分发系统和受支持的包格式的循环。
这个“只是将我的构建文件夹复制给我的用户”的想法在某种程度上让我想起了这个列表： https: //en.wikipedia.org/wiki/Fallacies_of_distributed_computing。虽然不是 100% 匹配，但这些问题令人回想起。当涉及网络时，事情开始变得非常不可预测，您需要日志记录、错误控制、事务、回滚、网络通信等......我们重新发现了大规模部署 - 它就是野兽。
网络：假设您想要将构建文件夹复制到企业中的10000 台桌面计算机。如何开始复制？您是否会立即启动所有复制，并像DDOS 攻击一样，通过文件复制接管整个网络来摧毁银行的交易大厅？抱歉 - 它已经失控 - 请原谅我的疯狂 - 但这种复制方法被认为对于使用当前技术方法进行大规模部署是可行的，这确实令人不安。内置的 Windows 功能可能会有所帮助，但仍需要进行适当的测试。您需要、、、、、、scheduling天知道打包/部署系统还可以为您提供什么。重新实现它将会是一系列需要处理的全新错误的痛苦。queuingcachingregional distribution sharesloggingreporting / inventory
也许有一天我们会看到基于自动包生成的自动输出文件夹复制，它确实通过智能和事务分发系统发挥作用。许多企业团队正在尝试，通过使用现有工具，他们更接近所使用的标准包格式。我想当前的云部署系统正在朝着这个方向发展，提供在线存储库和简单的交互式安装，但我们仍然需要智能地打包我们的软件。看看未来会怎样，以及云时代的打包和分发会出现哪些新问题，将会很有趣。
当我们按需直接从在线存储库中提取文件时，我们会看到一堆新问题吗？恶意软件、欺骗和注入？（已经有问题，但可能会变得更糟）。远程文件在没有警告的情况下被删除（以摆脱不应再使用的易受攻击的版本 - 让用户陷入困境）？证书和签名有问题吗？防火墙和代理问题？自动魔法更新中不幸的错误会立即意外地袭击每个人？以及与上述相关的网络和其他因素的谬误。打败我。我们会看到。
好吧，它像往常一样变成了咆哮——最后一段充满了猜测（其中一些问题已经适用于当前的部署）。对于那个很抱歉。但我唯一的建议是，尝试获得管理层批准以使用现有的打包和部署解决方案。
链接：
Stefan Kruger 的 Installsite.org Twitter 源：https ://twitter.com/installsite
选择部署工具：
| 归档时间： |
|
| 查看次数： |
4342 次 |
| 最近记录： |