我以前使用过 InstallAware 和 InstallShield，它们很难使用，当出现问题时，很难找到并解决问题。
我的问题是为什么我们不能使用使用 C# 编写的 Windows 应用程序来执行此操作。我知道 .Net 框架可能没有安装在目标计算机上，所以我想知道为什么没有人使用过这种架构：我将使用 IntallSiheld（或任何其他类似工具）创建一个简单的安装程序来安装 .Net 框架和之后它提取并运行我自己的 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,queuing,caching,regional distribution shares,logging,reporting / inventory，天知道打包/部署系统已经为您提供了什么。并且重新实现它将是一系列全新的错误要处理的痛苦列车。
也许有一天我们会看到基于自动包生成的自动输出文件夹复制，它真正通过智能和事务处理的分发系统工作。许多公司团队都在尝试，通过使用现有工具，他们更接近于使用的标准包格式。我想当前的云部署系统正朝着这个方向发展，在线存储库和简单的交互式安装，但我们仍然需要智能地打包我们的软件。看看未来会怎样，以及在云时代打包和分发会带来哪些新问题，这将是一件很有趣的事情。
当我们直接从在线存储库中按需提取文件时，我们会看到一堆新问题吗？恶意软件、欺骗和注入？（已经有问题，但可能会变得更糟）。远程文件在没有警告的情况下被删除（以摆脱不应再使用的易受攻击的版本 - 让用户陷入困境）？证书和签名问题？防火墙和代理问题？带有不幸错误的自动魔法更新会立即意外地袭击所有人？以及与上述相关的网络谬误和其他因素。打败我。我们会看到。
好的，它像往常一样变成了咆哮 - 最后一段正在猜测（并且一些问题已经适用于当前部署）。对于那个很抱歉。但是，尝试获得管理层的批准以使用现有的打包和部署解决方案是我唯一的建议。
链接：
Stefan Kruger 的 Installsite.org 推特：https ://twitter.com/installsite
选择部署工具：