对于.NET的情况（兽）
我是一个.NET开发人员，我没有头皮屑。 我工作的公司使用C ++ Builder 6.自从构思以来，我们一直在开发本地代码。 我们的旗舰产品完全用本地代码编写。
用可爱的铃声，口哨，蓬松的兔子和可爱的小猫进入.NET框架。 我跌倒，勾线，坠子。 我相信pipe理层认为.NET绝对是我们所有新软件开发的新框架，我们应该尽快开始迁移现有的代码。 有了所有的好处，它并不需要太多的说服力。 他们像往常一样接受我的build议。
在这一点上，我开始开发我的第一个.NET应用程序。 这一切都按计划进行。 该项目只是我们产品的一个组成部分。 所以我开始为这个新组件创build一个安装程序。 作为一家公司，我们非常自豪能够为用户提供尽可能简单的服务。 即使是微软，数千名开发人员也不会像我们那样创build安装程序。 例如，当您安装Microsoft CRM时，您将只能获得需要安装的故障和先决条件列表，然后才能继续。 不是我们。 决不。 如果你需要的东西，我们会为你安装。 想象一下。
我们，启动EXE，为你…
这使得我们的装置感觉如此简单。 .NET Framework未安装？ 没问题！ 我们会为你做的。 需要SQL Native客户端？ 精细！
现在的问题是，现在我们的解决scheme的一个组件是用.NET编写的，它使安装过程变得非常复杂。 在我甚至可以安装我们的产品之前，我需要执行以下操作：
-
检测是否安装了必备软件
-
如果不是，请安装它
-
确认它已成功安装
-
下一个先决条件
要安装.NET Framework，我首先需要Windows Installer 4.5。 但是对于不同的操作系统有不同的版本，所以我添加操作系统检测并启动正确的EXE。 哦，.NET框架已经封装了2K8，安装程序EXE不能运行，你必须运行OCSetup.exe参数来安装它。 叹。
所以它继续。 然后需要安装SQL Express 2005。 依赖性再次增加。
我认为pipe理层即使是微软也不会让用户这么容易。 他们的回答是，我们没有理由不这样做比他们更好。 我不能和这个争论，只不过我认为他们的方法有很好的理由。
突然，我们的安装程序是巨大的。 所有的.NET的先决条件，甚至没有谈到64位的支持，有一个完整的EXE范围的安装。 所以现在，我们希望用户能够下载“快速”评估。 真是笑话。 您需要下载500MB才能运行30MB的应用程序。 安装包的主要内容是先决条件。
pipe理层觉得我们有太多的依赖/先决条件。 我完全理解。 他们build议我们离开.NET框架，回到本地，在安装方面仍然“容易”。 这就是我的一部分想要站在.NET的angular度解释大局的好处，改进的开发经验，更容易的维护和整体的代码质量。 我的其他部分全心全意同意他们！ 在.NET中开发只需要安装太多的其他先决条件，这使安装变得复杂。
是的，一些.NET的倡导者会声称，一切应该安装在修补和更新的操作系统上。 这是真的，但不是所有的客户都有这个，只是简单地说：“对不起，先更新”就是不行。 请记住，我们为整体用户体验感到自豪。
我们现在正在考虑再次编写本地代码，我知道我们正在失去.NET的开发速度和所有好处。 但是，我们正在这个领域取得进展，如果你看大局的话，这个数字还是很小的。 由于我们有本地代码开发技能，而.NET对我们来说实际上是新的基础，所以甚至有理由退后一步。
我的问题最终是这样的，如果这个问题甚至是一个问题，那么贵公司对这个问题的看法是什么？如果我想继续把我们所有的产品迁移到.NET，我会build议pipe理层做什么？
这就是为什么许多公司已经切换到从您的主页上下载所有先决条件的网页安装程序的原因。 由于在大多数情况下，操作系统有99％的需要（如果他们已经使用Windows更新更新）。
我不会把所有的x64和x32放在同一个安装程序中。 创build两个安装程序，每个体系结构一个。
Paint.NET默认封装了必要条件的安装，没有捆绑.NET框架。 最终的结果是一个非托pipe的Shim可执行文件，用于检查.NET框架和其他一些东西，并在安装时握住你的手; 所有这些都是在需要时随时下载的。 然后，他们运行一个WinForms应用程序，将其插入MSI，以便将安装进一步包装在棉花中。
值得一Google。
也可能是因为它是Microsoft Update的一部分，许多客户机已经安装了某些版本的.NET Framework，因此在商业世界中更易于使用。
Paint.NET博客文章关于安装：
http://blog.getpaint.net/2008/08/24/the-paintnet-install-experience-part-1-version-3xx/
http://blog.getpaint.net/2008/08/25/the-paintnet-install-experience-part-2-version-40/ （谢谢Rup！）
再读一遍这个故事，可能pipe理层必须至less经历一次C ++应用程序部署的痛苦，但现在已经完成并被归类为“简单”。 把一些时间反对部署，并呈现给pipe理层，并隐藏痛苦，告诉他们是多么容易安装:)
让我们回到为什么要从本地代码切换到.NET代码：作为一名程序员，对于您来说更高效。 .NET中的许多事情比C ++（或者您使用的任何本地语言）更容易，所以您可以更快地开发您的应用程序。
那么，您开发应用程序的时间与开发安装程序的时间相比如何呢？ 即使您必须花费几个星期的时间来确定安装程序（特别是框架安装部分），那么您应该或多或less地通过这个程序。
对于所有未来的应用程序，您将使用几乎相同的安装程序; 您仍然可以执行所有先决条件检查，但不是将文件复制到C：\ Foo，而是将一些不同的文件复制到C：\ bar。
在我看来，这是一个简单的经济问题。 是的，为.NET应用程序开发一个（好的/完整的）安装程序会更加昂贵，但是如果这是您需要花费一次来大幅缩短开发时间的步骤，那么这是一个不容忽视的步骤。 您的投资回报可能会在几周内。
我觉得我需要回应这个声明：
是的，一些.NET的倡导者会声称，一切应该安装在修补和更新的操作系统上。 这是真的，但不是所有的客户都有这个，只是简单地说：“对不起，先更新”就是不行。 请记住，我们为整体用户体验感到自豪。
如果您的用户坚持通过操作供应商通知他们的系统不再适合自己的脚步，那么您就无法“帮助”他们。 我知道，这让我看起来像一个讨厌的活动家，但我看起来像一个手动的商人可能 – 这是由客户来确保他们希望我的工作环境是声音和适当的产品。 如果不是这样，我也会接受进一步的调查来做这个工作，但是可能还会带来额外的工作，因为他们没有足够的远见来确保他们明白自己在买什么。
我相信软件客户已经被允许长时间保持无知，现在他们应该被要求了解他们在购买什么。 运行未正确修补的公司IT环境与继续运行已经受制造商召回的车辆相同 – Windows服务包相当于在许多方面的召回。 您在法律上没有义务提交召回通知书，但作为一个企业来说，这是符合您的最佳利益的，您可能需要对责任推卸所造成的损失负责。
任何Visual C ++应用程序也具有先决条件/外部依赖性：运行时6.0,2003,2005,2008或2010？ 没有SP，SP1或SP2？ x86或x64？ 2005 SP2需要什么版本的Windows Installer？ 什么2008 SP1？ 等等，等等。
因此这是牵强的论据！ 就像Joel对.NET的抱怨一样。 看看现在是什么！
我没有看到如何有更多的先决条件。NET通过C + + Builder的。 你抱怨SQL Server，但是你忽略了你必须用C ++ builder安装一些数据库的事实。 你抱怨x64 vs x32，但是.NET不需要任何改变。同一个exe在两者上运行（并且为任一环境编译自己）。 关于C ++ Builder也不能这么说。 您可能需要单独的SQL服务器版本，但是这又适用于C ++构build器（除非您只安装了x32）。
是的，有新的安装程序版本问题，但这些组件不是很大。 你真的可以让安装程序只下载和安装必要的aprts。
C ++ builder对你来说可能更容易，因为你已经投入了时间来创build一个好的安装程序。 你需要为.NET做同样的事情，然后你可以根据真实的问题来select..而不是这个。
顺便说一下，微软select按照自己的方式来做事情的原因是许多用户，特别是公司用户，不喜欢为他们自动安装东西（可能是因为他们有一个依赖于特定版本的库的应用程序，而且你用一个新的版本来清除它们，不能轻易卸载）。
对于知识less的人来说，“让事情变得容易”的观点实际上让那些知道自己在做什么的事情变得更加困难。
这是一个很好的例子。 有一件事我绝对鄙视的是，当我安装需要SQL Server的应用程序时，它安装了自己的SQL Server实例，尽pipe我已经有好几个实例可以使用了。 对于新手来说很容易，对我来说，让我尝试让你的应用程序与我的单一实例一起工作的痛苦。
如果您的应用程序在Mono下运行，那么使用Mono运行环境运送您的应用程序可能不那么痛苦。
