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