支持或反对.NET（野兽）的案例

我工作的公司使用C ++ Builder6。我们从概念开始就一直在开发本机代码。我们的旗舰产品完全用本机代码编写。

一触即发，进入.NET Framework。我跌倒，钩，线和坠子。我相信管理层相信.NET应该绝对是我们所有新软件开发的新框架，并且我们应该开始尽快迁移现有的代码行。有了所有的好处，并不需要太多说服力。他们照常接受我的提议。

至此，我开始开发我的第一个.NET应用程序。一切都按计划进行。该项目只是我们产品的一个组成部分。因此，我要为这个新组件创建一个安装程序。作为一家公司，我们为使用户的操作尽可能简单而感到自豪。即使是拥有数千名开发人员的Microsoft，也不会像我们那样创建安装程序。例如，当您安装Microsoft CRM时，您将仅获得需要安装的故障列表和先决条件，然后才能继续。不是我们。决不。如果您需要什么，我们将为您安装。

这使我们的安装非常容易。.NET Framework未安装？没问题！我们会为您服务。需要SQL Native Client吗？精细！

问题是，既然我们的解决方案的一个组件是用.NET编写的，它会使安装过程变得异常复杂。在开始安装我们的产品之前，我需要执行以下操作：

• 检测是否已安装必备软件

• 如果没有安装

• 验证是否已成功安装

• 下一个前提条件

要安装.NET Framework，我首先需要Windows Installer 4.5。但是针对不同的操作系统有不同的版本，因此我添加了操作系统检测并启动正确的EXE。哦，.NET Framework已经与2k8打包在一起，并且安装程序exe无法在其上运行，您必须运行OCSetup.exe，并带有参数进行安装。

如此下去。然后需要安装SQL Express 2005。依赖关系再次增加。

我与管理层争辩说，即使Microsoft也不会让用户这么容易。他们的回答是，我们没有理由以这种方式不比他们更好。除了我认为他们采用其方法的理由很充分之外，我无法与之争论。

突然，我们的安装程序很大。.NET的所有先决条件，甚至都没有涉及64位支持，因为它具有要安装的EXE的单独范围。因此，现在我们希望用户能够下载“快速”评估。真是笑话。您需要下载500MB才能运行30MB的应用程序。大多数安装软件包是先决条件。

管理层认为我们有太多的依赖项/先决条件。我完全理解。他们建议我们从.NET框架转移到本机，在安装方面仍然“轻松”。这就是我一个人要支持.NET的地方，它从总体上解释了好处，改进的开发体验，更容易的维护和整体代码质量。我的另一部分完全同意他们的意见！在.NET中进行开发仅需要您安装太多其他先决条件，这会使安装复杂化。

是的，一些.NET倡导者将宣称所有内容都应安装在已修补和更新的操作系统上。的确如此，但并非所有客户都拥有此功能，只是说“对不起，先更新”就不会削减成本。请记住，我们为整体用户体验感到自豪。

现在，我们正在考虑再次编写本机代码，我知道我们在开发速度和.NET的所有优点方面正在遭受损失。但是我们正在这方面取得进展，无论您看与否，无论规模如何，我们都会有所作为。由于我们拥有本机代码开发技能，而.NET实际上是我们的新天地，因此退后甚至是有意义的。

我的问题是：如果我想继续将所有产品迁移到.NET，贵公司对这个问题的看法是什至根本没有问题，我向管理层建议的业务案例是什么样的？

这就是为什么许多公司转而使用Web安装程序从您的主页即时下载所有必备软件的原因。由于在大多数情况下，操作系统满足了99％的需求（如果已使用Windows Update进行了更新）。

我不会将x64和x32的所有内容都放在同一安装程序中。创建两个安装程序，每个体系结构一个。

Paint.NET很好地包装了必备组件的安装，而不会默认将.NET框架与其捆绑在一起。最终结果是一个不受管理的Shim可执行文件，它检查.NET框架和其他内容，并在安装时握住您的手。所有文件都可以根据需要即时下载。然后，他们运行WinForms应用程序，将其调用到MSI中，以进一步将安装包装在棉绒中。

值得谷歌。

许多客户端计算机已经安装了某些版本的.NET Framework，因为它是Microsoft Update的一部分，这也很可能是事实，这使它在商业环境中更易于使用。

有关安装的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！）

多读一些故事，大概管理人员至少要经历一次使用C ++应用程序进行部署的痛苦，但是现在已经完成并归类为“简单”。花费一些时间进行部署，并将其呈现给管理人员，并隐藏其烦恼，向他们展示安装过程的简易性:)

让我们回到为什么首先要从本机代码转换为.NET代码的地方：作为程序员，它对您来说效率更高。.NET中的许多事情比C ++（或您使用的任何本地语言）中的事情容易，因此您可以更快地开发应用程序。

然后，您花费在开发应用程序上的时间与您花费在开发安装程序上的时间相比如何？即使您必须花几个星期确定安装程序（特别是框架设置部分），也应该是您唯一必须经历的时间。

对于将来的所有应用程序，您将使用几乎完全相同的安装程序。您仍然会进行所有先决条件检查，但不是将文件复制到C：\ Foo，而是将一些其他文件复制到C：\ bar。

我认为，这是一个简单的经济学问题。是的，为.NET应用程序开发（良好/完整）安装程序会更加昂贵，但是如果您需要一次大幅提高开发时间的步骤，那就太简单了。您的投资回报可能会在数周左右。

我觉得我需要回应以下声明：

是的，一些.NET倡导者将宣称所有内容都应安装在已修补和更新的操作系统上。的确如此，但并非所有客户都拥有此功能，只是说“对不起，先更新”就不会削减成本。请记住，我们为整体用户体验感到自豪。

如果您的用户坚持通过操作系统来解决问题，而卖方却告知他们已不再适合他们，那么您就无能为力。我知道这使我看起来像个令人讨厌的维权人士，但我以一种手动商人的方式看待它-客户要确保他们希望我在其中工作的环境是健全且适合该产品。如果不是这样，我也将接受进一步的重新列举以完成该工作，但是由于他们没有远见卓识来确保他们了解自己所购买的商品，因此这可能还会使他们付出额外的工作。

我相信软件客户已经被允许长时间保持无知，并且现在应该要求他们了解他们所购买的产品。运行未正确打补丁的公司IT环境与继续运行受到制造商召回的车辆相同-Windows Service Pack在许多方面等效于召回。您没有法律义务提起召回，但这符合您的最佳利益，并且可能因您逃避责任而蒙受损失。

任何Visual C ++应用程序也都具有先决条件/外部依赖项：运行时6.0、2003、2005、2008或2010？没有SP，SP1或SP2？x86或x64？2005 SP2需要什么版本的Windows Installer？以及什么是2008 SP1？依此类推。

因此，这是牵强的论点！就像Joel 对.NET 的抱怨一样。看看现在是什么！

我看不出在C ++ Builder上.net会有明显更多的前提条件。您抱怨SQL Server，但忽略了必须同时使用C ++构建器安装某些数据库这一事实。您抱怨x64 vs x32，但是.NET不需要任何更改。.相同的exe可以在两者上运行（并且可以针对任一环境进行最佳编译）。关于C ++ Builder不能这么说。您可能需要单独版本的SQL Server，但同样适用于C ++构建器（除非您仅在所有内容上安装x32）。

是的，存在新的安装程序版本问题，但是这些组件不是很大。而且您确实可以让安装程序下载并安装必要的apts。

C ++构建器可能对您来说更容易，因为您已经花了时间创建一个好的安装程序。您需要对.NET执行相同的操作，然后才可以根据实际问题进行选择。

顺便说一句，Microsoft选择以这种方式进行操作的原因是，许多用户（尤其是公司用户）不喜欢自动为他们安装东西（可能是因为他们的应用程序依赖于特定版本的库，然后您就可以使用他们无法轻松卸载的新版本清除它）。

对于那些不太了解知识的人，您认为“使它更容易”实际上是使那些知道他们在做什么的人更加困难。

这是一个很好的例子。我绝对不屑一顾的是，当我安装需要SQL Server的应用程序并且安装了自己的SQL Server实例时，即使我可能已经有几个可以使用的实例。对于新手而言，这很容易，但是让我很难尝试让您的应用程序与我的单个实例一起使用。

如果您的应用程序在Mono下运行，那么在Mono运行时附带的应用程序可能会减轻痛苦。