支持或反对.NET(野兽)

时间:2010-12-17 11:46:34

标签: c# .net

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

使用它的铃声和口哨进入.NET Framework。我跌倒,钩,线和坠子。我说服管理层.NET应该绝对是我们所有新软件开发的新框架,我们应该尽快开始迁移现有的代码行。拥有所有好处并不需要太多说服力。他们像往常一样接受我的建议。

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

这使我们的安装变得如此简单。 .NET Framework没有安装?没问题!我们会为你做的。需要SQL Native客户端吗?精细!

问题在于,现在我们的解决方案的一个组件是用.NET编写的,它使安装过程变得异常复杂。在我甚至可以安装我们的产品之前,我需要执行以下操作:

  • 检测是否已安装先决条件

  • 如果不是

  • ,请安装它
  • 确认已成功安装

  • 下一个先决条件

要安装.NET Framework,我首先需要Windows Installer 4.5。但是对于不同的操作系统有不同的版本,所以我添加操作系统检测并启动正确的EXE。哦,.NET框架已经打包了2k8并且安装程序exe无法在其上运行,你必须运行带参数的OCSetup.exe来安装它。

所以它继续。然后需要安装SQL Express 2005。依赖关系再次增加。

我与管理层争辩说,即使微软也不会让用户轻松这么做。他们的反应是我们没有理由以这种方式比他们更好。我不能与之争论,除非我觉得他们采用他们的方法有很好的理由。

突然间,我们的安装程序非常庞大。 .NET的所有先决条件,甚至没有谈论64位支持,它有一整套独立的EXE要安装。所以现在我们希望用户能够下载“快速”评估。真是笑话。您需要下载500MB才能运行30MB的应用程序。大多数安装包都是先决条件。

管理层认为我们有太多的依赖关系/先决条件。我完全理解。他们建议我们从.NET框架转移回原生土地,在安装方面仍然“容易”。这是我的一部分想要代表.NET解释大局的好处,改进的开发体验,更容易维护和整体代码质量的地方。我的另一部分全心全意地同意了!在.NET中开发只需要安装太多其他先决条件,这会使安装变得复杂。

是的,一些.NET支持者会声称应该在修补和更新的操作系统上安装所有内容。这是事实,但并非所有客户都有这个,只是说“我很抱歉,先更新”只是不会削减它。请记住,我们为整体用户体验感到自豪。

我们现在正在考虑再次编写本机代码,我知道我们在开发速度和.NET的所有好处方面都失败了。但是我们正在这个领域获得成功,如果你看一下大局,我们就会变小。由于我们拥有本机代码开发技能,而.NET实际上是我们的新基础,因此回归也是有意义的。

我的问题是:如果这个问题甚至是一个问题,那么贵公司对这个问题的看法是什么?如果我想继续将所有产品迁移到.NET,我建议管理层提出什么样的商业案例?

7 个答案:

答案 0 :(得分:50)

这就是为什么许多公司已经切换到从主页上即时下载所有先决条件的网络安装程序的原因。因为在大多数情况下,操作系统有99%的需要(如果它们已使用Windows Update更新)。

我不会在同一个安装程序中放置x64和x32的所有内容。创建两个安装程序,每个安装程序一个。

答案 1 :(得分:39)

Paint.NET可以很好地包装先决条件的安装,而无需在默认情况下将.NET框架与其捆绑在一起。最终结果是一个非托管的shim可执行文件,它检查.NET框架和其他一些东西,并在安装时握住你的手;所有这些都是在需要时随时下载的。然后,他们运行一个WinInms应用程序,该应用程序进入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 ++应用程序部署的痛苦,但它现在已经完成并被归类为“简单”。花一些时间来反对部署并将其呈现给管理层,并隐藏痛苦,向他们展示安装是否容易:)

答案 2 :(得分:37)

让我们回过头来为什么要首先从本机代码切换到.NET代码:作为程序员,它对您来说更有效率。 .NET中的许多东西比使用C ++(或者你正在使用的任何本地语言)更容易,因此你可以更快地开发应用程序。

那么,您开发应用程序所花费的时间与开发安装程序所花费的时间相比如何?即使您不得不花费几周的时间来确定安装程序(特别是框架设置部分),这应该或多或少是唯一的时间。

对于所有未来的应用程序,您将使用几乎相同的安装程序;您仍然会执行所有先决条件检查,但不是将文件复制到C:\ Foo,而是将一些不同的文件复制到C:\ bar。

在我看来,这是一个简单的经济学问题。是的,为.NET应用程序开发(良好/完整)安装程序的成本更高,但如果这是您需要一次以显着缩短开发时间的步骤,那么这是一个明智的选择。您的投资回报可能是几周。

答案 3 :(得分:18)

我觉得我需要回应这句话:

是的,一些.NET支持者会声称应该在修补和更新的操作系统上安装所有内容。这是事实,但并非所有客户都有这个,只是说“我很抱歉,先更新”只是不会削减它。请记住,我们为整体用户体验感到自豪。

如果您的用户坚持通过操作供应商告知他们不再符合目的的系统来强行自拍,那么您无能为力“帮助”他们。我知道这让我看起来像一个讨厌的活动家,但我看的方式与手工商人的方式相同 - 由客户来确保他们希望我工作的环境是声音适合产品。如果不是,我会接受进一步的重新计划来完成这项工作,但它可能仍然会导致他们额外的工作,因为他们没有先见之明,以确保他们明白他们正在购买什么。

我认为软件客户被允许长时间保持无知状态,现在他们应该被要求了解他们正在购买什么。操作未经适当修补的公司IT环境与继续运行受制造商召回的车辆相同 - Windows服务包相当于在许多方面进行召回。您在法律上没有义务接受召回,但这符合您作为企业的最大利益,并且您可能要对您因推卸责任而造成的损失负责。

答案 4 :(得分:7)

任何Visual C ++应用程序都具有先决条件/外部依赖性:运行时6.0,2003,2005,2008或2010?没有SP,SP1或SP2? x86还是x64? 2005 SP2需要什么版本的Windows Installer?什么是2008 SP1?等等,等等。

因此,这是一个牵强附会的论点!像Joel的关于.NET的grumblings。看看now

答案 5 :(得分:3)

我没有看到.net相对于C ++ Builder有更多的先决条件。您抱怨SQL Server,但您忽略了必须使用C ++构建器安装某些数据库这一事实。你抱怨x64 vs x32,但.NET不需要任何改变..同一个exe在两者上运行(并为两种环境最佳地编译)。关于C ++ Builder也是如此。您可能需要单独版本的SQL Server,但这又适用于C ++构建器(除非您只是在所有内容上安装x32)。

是的,有新的安装程序版本问题,但这些组件不是很大。而且你真的可以让安装人员下载并安装必要的aprts。

C ++ builder对您来说可能更容易,因为您已经投入时间来创建一个好的安装程序。你需要为.NET做同样的事情,然后你可以根据实际问题进行选择..而不是这个。

顺便说一句,微软选择按照他们的方式做事的原因是许多用户,尤其是企业用户,不喜欢自动为他们安装内容(可能是因为他们的应用程序依赖于特定版本的一个图书馆,你出来并用一个他们无法轻易卸载的新版本擦除它。

对于知之甚少的人来说,你认为“让事情变得更容易”实际上让那些了解他们所做事情的人变得更加困难。

这是一个很好的例子。我绝对鄙视的一件事是当我安装一个需要SQL Server的应用程序时,它会安装自己的SQL Server实例,即使我已经有几个实例已经可以使用了。对于初学者来说很容易,对于我来说,尝试让你的应用程序与我的单个实例一起工作是一种痛苦。

答案 6 :(得分:1)

如果你的应用程序在Mono下运行,那么使用Mono运行时运送你的应用程序可能会少一些痛苦。