然后出现了具有各种特色的.NET框架,我迅速被吸引住了,并说服管理层,让.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,我向管理层提出的业务案例会是怎么样的呢?