微软真正的麻烦

xug

longhorn难产的原因在哪里？
要不要学习.net编程？
VB的前途是什么？
C#到底是干什么用的？
ASP.net很快又要淘汰？

为什么？

难道微软为了市场利益什么都能干得出来？


那么就读以下专辑吧


------------------------------------------------------------------------------------

xug

.NET专家Richard Grimes的告别书



　　我撰写.NET技术通讯已经有大约三年时间，现在我决定停止这项工作。我认为有必要写一篇总结性的文章，阐述我对.NET当前状况及未来发展的看法。

　　2000年初，当.NET还在Beta版的时候，我就开始使用它了；在那个时候，它的名称是COM+2，主要的语言是Cool。其框架组件被简单地称为下一代Windows服务（NGWS），直到后来才由市场人士提出.NET这个名称，但是.NET这个名字却使互联网搜索引擎产生了混乱。你自问过.NET到底是什么意思吗？抑或它与.COM和.ORG有什么关系吗？当然，Cool的遭遇也好不到那儿去。后来他们有了一些灵感，决定把Cool更名为C#，但是C#好像最初也引起了搜索引擎和用户的混乱。搜索引擎不喜欢使用#字符，而用户则不知道这个字符该怎么读（C磅？还是东方的发音C号？）。我发表在技术新闻组上的第一篇文章是一个简单的Cool控制台应用程序、一个与其功能相当的Java程序，并提出一些问题指出了两者之间的差别。这引起了Visual Studio产品经理的强烈响应，他们没有真正地注意到我所指出的问题。

　　Visual Studio.NET与Visual Studio其它的版本不同，它的第一个beta版是开放的。任何人都可以下载并在beta新闻组中提交bug或问题。老实说，我不喜欢这种方式。我只是在公共新闻组中发表了一些可重复的bug，作为一个缄默的英国人，我不喜欢发表那些不可重复的bug，也不喜欢提出改善建议。我也没有看到关于这个大范围的、开放的beta版是否从发现的大量bug中受益的公开发表的结果；可是，我怀疑查找bug并不是其目的--更可能的情况是beta版的开放是为了使它尽可能的被大家接受。

　　我与其他人一样，开始的时候也被该框架组件的大小吓住了。它太大了！在过去的几年中我得出了一个结论：框架组件的大小是一种障碍。它里面的类太多了，尽管我也认为其中很多类是被良好地设计的，但是我仍然认为有一些是草率地完成的。其中有些类仅仅对Win32的简单包装，还有一些类看起来是从其它的框架组件中导入的。微软在发布.NET之前，已经拥有自己的Java框架组件类库（叫做WFC），还拥有一个传统的Visual Basic运行时部分的受控（managed）类库，如果我知道有多少WFC和VB类迁移到了.NET上就好了。但我能够识别出其中的一个，因为它在.NET和VB上运行的情况一样糟糕，这个类就是EventLog。这个类的行为与它在VB中的行为一样，在按照常规迁移到框架组件1.0版本之前，甚至于没有人关心它的设计。我在beta版中就抱怨过这个类，但是这个类的开发者只给出了一些毫无说服力的理由。最后，这个类在2.0中进行了“修补”，但是错误的方法还是没有被消除，因此我认为它根本就没有被“修补”过。

　　总体来说，我认为这个类库发布得太早了，同时它还太大了。该框架组件的可重新发布的部分（redistributable）有25MB，它比Java的可重新发布部分大很多倍。Visual Basic早期版本得出的经验是共享软件和免费软件市场造就某种语言的流行。尽管有些共享软件是使用.NET编写的，但是我经常听到人们抱怨那个巨大的可重新发布部分。我写过关于类库大小问题方面的文章，并且我始终认为如果微软提供删减过的、只带有微软核心类库和系统部件的框架组件版本是有好处的。

　　说起Visual Basic，我也想提出自己对它的看法，我不得不说传统的Visual Basic太老了。该语言天生就是单线程的，与COM交互（以及建立COM服务器）时会产生很严重的问题。实际上，在我写完一本关于MTS的书（1999年发表）的时候，就得出结论说MTS被设计为允许Visual Basic开发人员编写那些可以从多线程技术（threading）和安全技术（security）中受益的对象，而COM+则使其更进一步了。Visual Basic可以调用Win32函数，但是为了高效率使用这些函数，通常需要利用不太好的黑客技术。但是有了COM和COM安全技术之后，它向前迈进了很大的一步，不过还是不能用少量的几行代码来提供C++能够实现的功能。C++可以用很少的代码就能方便地实现而VB却无法像这样，实现任何功能都使VB非常窘迫。但是这种语言和在运行时（runtime）产生的大多数问题都是与生俱来的，因此，这些问题的解决方案非常激进。这导致了VB.NET的出现。

　　如果你搜索互联网，就可以找到很多关于VB.NET的发布引发狂热的资料。最好的是Karl E. Peterson的网站（http://www.mvps.org/vb/rants/vfr ... �VB.NET带有一个"迁移"工具，但是我认识的使用过这个工具的大多数人都发现这个工具仅仅简单地标记出了大量的不兼容的代码。我早期的建议是VB开发者不要迁移自己的代码，替代的方法是，把代码转换为VB类，而这些类则可以通过COM交互操作（interop）而被.NET代码调用。采用这种方法，VB代码仍然能被保留在设计环境中。当然，微软继续说VB.NET就是VB的神话，鼓励大家使用这个迁移工具。

　　有些人认为VB.NET是令人叹服的。但是我真的没有察觉设计这种语言的动机。在VB.NET中其它语言所不拥有的特性很少（除了过滤器和接口方法的重命名），但是这对于产生一种新的语言来说理由是不充分的。有些人可能会说VB开发者使用VB.NET更加顺手，但是我前面说过，VB.NET不是VB，由于开发者必须学习OOP和.NET的原理，例如线程技术、异常处理和委托，开发者差不多学习了一门新的语言。C#是一种自然的可以用于.NET的语言，根本就不需要VB.NET。使用分号（;）和括号（{}）没有那么困难！它可以作为VB.NET的代替者，但是并非所有的语言都是这样的。我的看法是，通用语言规范（CLS）仅仅是简单地确保了在其它的语言中可以建立与VB.NET代码一起工作的代码，而不是使所有的语言协同工作。我知道有符号的（signed）整型数据是有用处的，但是无符号的（unsigned）整型数据也有用啊！我就不理解为什么VB.NET不把无符号整型作为语言的一部分。还有一些情况也是幼稚的，我们没有理由使用Option Strict Off（"延迟绑定"也与难以查找运行时bug是同义词），而且如果你没有显式地（explicitly）声明变量，那么很容易失去对这些变量的跟踪。VB.NET带来的少量优势不足以抵消它所拥有的这些严重的缺陷。

　　我曾经写过VB.NET的文章，也在VB.NET讨论会上发言过，因此我很了解这种语言。但是，它并没有使我感到舒适：我发现自己每次使用这种语言的时候，都少不了咒骂。它工作的情况就是与我预期的不一样，而且我也不是唯一的遇到这种情况的人。这是传统的VB迁移到VB.NET的时候我听到的最常见的抱怨，这也支持了Karl E. Peterson的断言--VB.NET不是VB。那么微软为什么创建VB.NET呢？其原因是在2000年的时候，VB开发人员的数量超过了微软的其它语言、超过C++用户数量至少10％（我在微软内部会议上看到过这个图表）。微软高调地宣布C#是 "来自C++家族"的另一种语言，并且市场人士认为他们不可能使所有这些VB程序员都使用类似C++的语言。替代方法是，他们认为如果微软建立一种类似VB的语言，这些VB程序员中相当比例的人更有可能迁移到.NET上。换句话说，VB.NET的出现是市场的原因而不是技术的原因。

　　有必要指出，.NET大体上与传统的VB有很多相似之处。.NET与VB一样可以使用接口（interface），接口是非常精致的（elegant），但是.NET却推荐使用基于类的解决方案，这标志着接口的消亡。

　　我们再来看一看.NET remoting（远程技术）：微软提供.NET remoting用于允许创建于自己的环境中并且运行着的对象被另一个环境调用。这意味着该对象的状态是本地的（local），而它的行为则是远程的（remoted）。因此，remoting是一个基于接口的工具。你可以利用接口来使用.NET remoting，但是如果你阅读文档或者访问Web上的"how－to（操作指南）"，你就根本意识不到这一点。作为代替的是，微软推荐人们使用基于类的方法，这通常会导致一些奇怪的现象出现--人们向客户端部署服务器部件，这样客户端才拥有可用的服务对象的元数据（metadata），或者导致泡沫部件，它使哪些基于类的remoting问题四处散播。

　　.NET非常象VB的另一个地方是微软对它的框架组件的态度。微软把.NET作为扩展自己的产品的一个有用的类库，但是到目前为止，微软却没有显示出对该框架组件的更大的信心。目前只有很少的.NET产品是整个地使用.NET编写的；其中一个是微软的CRM。但是，它们却不是微软主要的收入来源。作为代替，.NET被更新到已有的产品中，并用于扩展这些产品。即使Visual Studio .NET也不是.NET产品。devenv.exe是一个用C++（大概是MFC）编写的非受控（unmanaged）过程。VS.NET寄宿了.NET运行时，这样它就可以使用类似属性表格的.NET对象，并且它可以被写成.NET部件的代码扩展。我认为这是微软未来使用的模型。他们不希望承担为.NET重新编写代码的开销，而且没有谁强迫他们在.NET中提供全新的代码；.NET将会被寄宿，并且在需要的时候，允许通过用户提供的代码来进行扩展。

　　微软当前的操作系统XP和Windows 2003并不依赖于.NET；而且XP中.NET是一个可选组件。下一个版Windows（叫做Longhorn）在2003 PDC上作为技术预发布过，看起来.NET贯穿着这个操作系统。但是到发布的时候会发生很多变化的。在过去的一年中，微软发表了很多声明，表现出它更关心原定的发布日期2006年，而不是对新技术的热情。第一个障碍是WinFS，很明显这种技术会使Longhorn更慢，特别是WinFS使Outlook Express根本就无法使用。但是微软的做法并不是使这种技术能够正常工作，而是选择删除了它。在你阅读这几行的时候，我在怀疑这种技术是否能够返回应用。其次，微软宣称Longhorn中的另外两种.NET技术--Indigo和Avalon，将可以在其它版本的Windows中使用。Indigo是一种通讯技术，因此其它版本的Windows使用它是有意义的。但是，我认为使Avalon可用于其它版本的Windows表明微软对Longhorn的销售不太自信。

　　我的看法是Avalon--更具体地说是XAML，将标志着ASP的消亡。其原因在于Avalon是一种客户端技术，而浏览器则是该分布模型的一个重要部分。XAML的功能如此丰富，以至于包含浏览器的XAML应用程序与基于过程的Avalon应用程序看起来没有差别，而且与Web服务或者Indigo（作为访问远程代码的机制）耦合之后，XAML应用程序会使ASP.NET应用程序看起来毫无价值和陈旧不堪。微软为什么想毁掉ASP呢？安装ASP.NET的时候，微软会卖出一套Windows 2003，同时还可能卖出几套Visual Studio.NET。客户端可以不是Windows，因此微软不会有其它的销售收入（无论是产品或许可）。这是一块很大的收入来源，更糟的是，ASP.NET实际上使编写应用程序更加容易了，而且它还可以被IE以外的浏览器使用。但是，使用类似XAML技术的时候，微软对客户端有控制权。因此，除了服务器和开发工具之外，客户端也必须拥有Avalon技术。假如客户被说服了，升级到Longhorn，那么它就可能是微软巨大的收入来源。但是微软宣称Avalon将可以用于其它版本的Windows，向我表明他们对Longhorn的预计也不是那么自信，并且如果开发者不能确定客户端是否会运行Avalon应用程序，那么他们就不会为Avalon编写应用程序。

　　因此，从去年的声明中可以看出，微软认为Longhorn并不是在PDC 2003上取得我们信任的伟大的.NET变革。这表明微软正在逐步失去对.NET的信心。当我看到Longhorn的beta版的时候（应该是今年年末），我会仔细地检查它到底有多少是用.NET实现的。我怀疑只有很少的一部分会用.NET来实现。我们可以找到一些线索：如果Longhorn没有实现命令解释程序（shell），或者不允许你用.NET扩展命令解释程序，那么很明显微软失去了信心。如果Longhorn没有实现.NET中的任何服务，那么就表明.NET并不是在LOCALSYSTEM帐号权限下运行的正确的技术。

　　你读到这儿时候，得到的印象可能是我对.NET的看法是愤世嫉俗的。它的框架组件有很多承诺，但是我认为微软的野心太大，以太快的速度发布了太多的部件。微软为了提供向后的兼容性，不能简单地重新设计整个类库并抛弃旧的类库。因此我们得坚持使用现在所拥有的类库。微软允许市场优先于技术：他们建立并宣传VB.NET仅仅是为了使Windows开发人员使用.NET，而不是因为需要这种语言。它的框架组件变成了Visual Basic--它是供用户开发应用程序的，而不是供微软建立操作系统或建立他们所依赖的带来收入的产品的。

xug

对谁失去了信心？是.NET还是微软



最近可谓是热闹之极，对于.NET的争论再起风波，不过，这一次的争论起源于.NET阵营内部，我认为这是一种好的现象，因为这表明.NET阵营内部在反观自己，或者用中国式的说法就是在自我批评。自我批评是进步的表现。

这一次争论的焦点并不在于技术本身，而在于微软对.NET的发展态度。中国有句俗话，清者自清：无论别人怎么说，我坚持我的想法和做法，总有一天我会用行动证明哪些人说的都是错的。从微软的行动看，微软不知道中国的这句俗话，因为微软开始对这场争论回应。以前也有很多贬低.NET的言论，甚至有不少重量级的人物的言论，但是微软都在用自己的强势的行动做出了回应，而这一次是语言上的。微软为什么这么快的对这场争论做出语言上的而不是行动上的回应？甚至可以从微软的言论中可以看出，微软都没有好好准备就出来回应了。

当然，这其中有一个很重要的因素，那就是这场争论针对的是微软一直没有采取的行动，例如用.NET重写Office。所以，微软就无法用行动来证明了，只能用言论来反驳。但是，我认为微软这次如此之快的做出反应，其实还有另一个因素，那就是微软担心这次争论最终导致开发者对.NET失去信心。

一场战斗中，最重要的是将领，将领都无心作战，那么战士就更不用说了。所以，微软如此之快的出来辟谣，反驳负面的言论是正常的。但是，在微软出面之前，网上的很多言论都表示了对.NET的信心，甚至有人讥笑发起者的对.NET的不了解和想法的幼稚。可以说，争论一开始就是对.NET是正面的，而不是负面的，那么为什么这场争论还可以不断地延续到现在，甚至还有蔓延的趋势？因为更多的争论参与者针对的已经不是.NET，而是微软本身。

换句话说，不是开发者不相信.NET，而是开发者不相信微软。

其实，开发者对.NET是赞同的，是向往的，对于开发者来说，.NET的概念是否模糊并不重要，因为开发者在用.NET实现自己对.NET的理解、希望和梦想。但是，微软却在逐渐的粉碎开发者对.NET的梦想。

从2000年到现在的2005年，微软在2000年用beta版的.NET激起了无数开发人员的激情，2001年用.NET 1.1在这些激情上再点燃了一把烈火，然后再在2002年用.NET 1.1把火烧的更旺。但是从1.1开始，开发者开始发现自己对.NET的梦想被微软粉碎了。

最开始是在开发人员还未对1.1熟悉的情况下，网上就开始出现2.0的身影，然后就是1.1的各种开发资料在微软的网站上开始逐渐的缺失，以致到现在，微软的网站上关于2.0的资料就占了80%以上，开发者开始感觉到自己在被微软抛弃。如果把微软比作一个火车头，开发者是车厢，那么，就是火车头在不断地加速向前开，却从来不顾后面的被它拖着的车厢是否可以在这样的速度下行驶。当然，不断地发展是必须的，其实我没有理由说微软发展的太快，因为发展是必然的，快速发展是必要的，但是我们看到，从2000年到现在，.NET即将进入2.0的时代，而在.NET的框架上仍然没有一个成熟的应用框架，这就意味着，微软要让开发者在一个几乎没有基石的平台上向一个更高的平台跳跃。尽管微软自己推出了Application Block，然而正是这个Application Block彻底将开发者的梦想粉碎了。

当.NET推出时，一场声势浩大的工程也就随之开始，那就是将Java下已经有的成熟的应用移植到.NET上。说声势浩大决不夸张，有的应用是被直接在语言级别上转化而来，而有的应用在移植的同时也在尝试新的技术。无论这些应用如何，它们在极大程度上为.NET的成熟应用打定了基础。例如，log4net，nant，spring.net，nhibernate, castle等等。它们分别在日志，编译工具，O/R Mapping，AOP等等领域丰富了.NET世界。而移植/开发它们的开发者无不是被.NET吸引而来，无不是为这.NET世界的美丽梦想而来。但是这一切正在被微软逐渐击破。例如，微软用自己的日志打击这log4net，用msbuild打击nant，将来的objectspace也许将在AOP、O/R Mapping等多个领域打击现有的成熟应用。微软就像生化危机中的那只初期试验的动物一样，嗜血本性实足，在吃掉对手的同时，会吸收对手的基因，从而迅速进化为更凶猛、更具攻击力的新的生物。

因此，可以说，微软的行为正在导致开发者对微软失去信心，所以，微软这次的行动就是为了保持开发者对微软的信心，避免开发者的流失。然后，梦想破碎了，希望也就消失了，信心自然就灰飞烟灭了。当然，我不希望看到这样的结局，我更希望微软有更好的方式重拾开发者对.NET的梦想、信心和希望。

xug

.NET 想说爱你不容易


微软的.NET框架从诞生至今应该有四年多了吧？这四年是怎样的四年？微软又在多大程度上达到了当初所憧憬的美丽蓝图？我不敢说我对.NET有多么深的了解，但是我似乎越来越发现微软已逐渐背离了最初的美好愿望，或者说，背离了早期力推.NET技术时在广大开发人员中树立的美好图景？

通常，一个好的点子，或者说一套先进的想法，加上微软这样的公司，我们似乎没有必要怀疑它的成功。我们倾向于这样看待微软的产品：成功只是迟早的问题，或者，就算最终计划落空，你也不用太伤心，有那么大一个软件帝国垫背。于是，很多人在左右为难的时候，选择了微软的产品和技术路线。.NET更是被微软戴上了前所未有、鲜艳夺目的光环，我们从各种渠道听到这样的声音：.NET是微软的未来，是微软面向未来至少十年的技术；要跟着微软，就要学习.NET，使用.NET；.NET让你的代码更加安全；未来的微软产品线都会依赖于.NET技术。Bill Gates这次确实是认真的：.NET是微软的远大理想，是微软无论如何都要达到的目标。

平心而论，.NET的核心思想是很不错的，从CLR和IL的设计上就能够看得出来，在吸取了之前诞生的各种不同技术之精髓以后，又大胆的进行创新，实用、易用为先，绝对有实力成为未来大部分计算机应用的统一平台，成为整合企业和个人现有应用的绝佳框架。我相信大部分人在看到这些特点后都对.NET的未来充满希望。

然而最近不知从哪里吹来一股子坏味道：微软自己对.NET的定位发生了变化吗？还是说.NET本来就是个幌子？从微软自己的角度，我们似乎到现在也没有看到微软的哪个重量级产品和产品线是基于.NET的，几乎都还是混血儿或者干脆就是贴牌而已，众所期待的.NET操作系统Longhorn最终也放弃了 WinFS，让人怀疑Longhorn还会不会是当初微软声称的样子；从.NET基础库来看，似乎有相当一部分API只是对原有API的简单包装，原有的优势还在，bug也还在；从我们常见的代码来看，似乎到处都还充斥着[DllImport]这样的标签，是我们的程序员们怀旧吗？我还记得很早以前就有人提出了对.NET的反感，当时我不以为然，现在似乎也有些理解了。其中有一个大家普遍觉得不太满意的地方就是：为什么以前不超过100K的程序为了要用. NET，就必须让客户端下载安装25MB之巨的.NET环境呢？

我本人虽然是做Java出身，对.NET技术本身还是很感兴趣，也是支持的，但是对微软的有些做法有些不解：这是在给开发人员怎样的信息呢？.NET不可靠了吗？也许我们应该这样想：.NET绝对不是微软的全部，也不可能解决所有编程问题。诚然。但是.NET不就是为了解决大部分常见的编程问题吗？既然提供了这种便利和安全性，为什么自己都不广泛采用呢？感觉是：微软有一个很好的起点和一个远大的目标，但是为了照顾到所有Windows平台的既得利益者，或者说保护Windows这一商标的既得利益，.NET变得越来越杂，越来越畸形，大概需要静下来好好整理一下了吧？

在.NET的圈内圈外都有不少观望的人：圈内的人在观望.NET是不是将要沦为一种粘合剂而不是以一代多的统一平台？.NET真的只是吸引开发人员到 Windows平台的幌子吗？圈外的人在观望.NET到底是不是微软未来绝对的主力军？是不是他们应该定下的下一个学习目标去投资呢？其实让这一大群人安心的最佳途径也许是微软出面构建一套完全基于.NET的像模像样的大型软件产品（最好是桌面应用），但是微软准备这样做吗？我不知道，但是很怀疑。对于微软来说，也许他们不言而喻的一个心理底线就是：不论技术如何进步，如何创新，都不能动摇Windows和Office在操作系统市场上现有的地位。

.NET，你可真是让人欢喜让人忧啊。

xug

微软C#产品经理对Richard的回应



　　最近我通读了Richard Grimes在Dr. Dobbs Journal上发表的文章"Grimes的告别.NET书"。我想对该文章中Richard的观点作一些回应。Richard明确地宣称该文章是"自己的观点"，也就是说，他的文章应该被看作是他自己对于.NET当前的情况的看法，而不是讨论我们走了多远、要到哪里去。他提出了三个论点--.NET框架组件太大了以至于妨碍了它的应用，.NET框架组件的设计问题，文章还有大约一半的内容在抨击Visual Basic，最后的结论是微软对.NET框架组件"失去了信心"。在下面的内容中，斜体字是引用他的观点，后面是我的回应。

　　对于.NET框架组件的大小妨碍了它的应用问题

　　· RG：该框架组件的可重新发布部分（redistributable）有25MB，比Java的可重新发布部分大很多倍。Visual Basic早期版本得出的经验是共享软件和免费软件市场造就某种语言的流行。尽管有些共享软件是使用.NET编写的，但是我经常听到人们抱怨那个巨大的可重新发布部分。

　　我的回应：也许是我过于挑剔了，但是它的大小的确是23,698K或23.7MB。尽管Java的运行时相对较小，但是还是有15MB。通观全文，Richard谈到.NET应用程序的时候，他谈到的实际上是客户端或公共客户端（即不在防火墙内）。例如，把.NET框架组件安装在服务器上，或者安装在你可以控制的内部网环境中根本就不会有问题。即使在公共客户端计算机上，也有大量的商业共享软件--从游戏到RSS阅读器--都需要.NET框架组件。我曾经询问过很多共享软件开放人员，他们的确没有使用Java，多数人使用C/C++、Visual Basic或Delphi。在谈".NET的状况"的时候，开发部副主管Soma的关于.NET的能量的文章做了更好的总结。

　　Soma：到目前为止，我看到人们从Windows更新和微软下载中心下载了7000万次.NET框架组件。简单的计算一下，这个数据可以转换为每个月下载550万次。另一个有趣的数据是，在2004年，我们预计约有5400万台新PC中会安装/预装.NET框架组件。我们还拥有大约250万受控代码开发者。

　　关于.NET框架组件的设计的问题

　　· RG：我发表在技术预览新闻组上的第一篇文章是一个简单的Cool控制台应用程序、一个与其功能相当的Java程序，并用一些巧妙问题指出了两者之间的差别。

　　· RG：其中有些类仅仅是Win32的包装，还有一些类看起来是从其它的框架组件中导入的。微软在发布.NET之前，它已经拥有自己的Java框架组件类库（叫做WFC），还拥有一个作为传统的Visual Basic运行时部分的受控（managed）类库。如果我能知道有多少WFC和VB的类迁移到了.NET就好了。

　　我的回应：这两个观点是矛盾的。在第一个观点中他暗示.NET框架组件是Java的复制品，但是在后面一个观点中，他声明.NET框架组件简单地迁移自Win32类、Windows基类（WFC）和VB运行时类。他的观点到底是哪一个呢？如果他的观点是可以编写一个简单的应用程序，该程序在C#、Java或C++看起来一样，那么我认为这根本就不能证明什么。看看下面的一个for循环：

for (int i = 0; i < x; i++) {...}

　　猜猜它是用哪种语言编写的？如果你的回答是C、C++、C#和Java，那么就答对了。我看不出他到底想证明什么。如果他试图建立一个比"Hello World"更加强大的应用程序，那么就应该在框架组件或类库的具体特性（ATL不是，MFC也不是EJB等等）下运行。

　　关于基于接口的编程和Remoting技术的问题

　　· RG：接口是非常精致的（elegant），但是.NET却推荐使用基于类的解决方案，这标志着接口的消亡。我们来看一看.NET remoting（远程技术）：微软提供.NET remoting用于允许在创建自己的环境中运行的对象被另一个环境访问。这意味着该对象的状态是本地的（local），而它的行为则是远程的（remoted）。因此，remoting是一个基于接口的工具。你可以利用接口来使用.NET remoting，但是如果你阅读文档或者访问Web上的"how－to（操作指南）"，你就根本意识不到这一点。

　　第一点--接口消亡了

　　我的回应：.NET框架组件中到处都用到了接口，接口在类似VB或C#的特定的单层继承语言中特别有价值。即使最简单的String类也有IComparable、ICloneable、IConvertible和IEnumerable接口。再向前看，.NET框架组件2.0的关键的新特性--泛型（generics）--也用接口来约束数据类型。

　　第二点--缺少在.NET Remoting中使用接口的文档

　　我的回应：我决不说我们的文档是没有瑕疵的，我可以提供一个链接关于Remoting的.NET框架组件SDK示例。请注意下载的第五个示例就是在remoting中使用接口。

　　· RG：.NET可以使用接口（interface），但是推荐的方法是使用类。

　　· RG：微软的替代作法是推荐人们使用基于类的方法，这通常会导致一些奇怪的现象出现--人们向客户端部署服务器部件，这样客户端才拥有可用的服务对象的元数据（metadata），或者导致泡沫部件，它使哪些基于类的remoting问题四处散播。

　　我的回应：我们本身没有"推荐"任何机制。尽管我们可能提供了指导，但是开发者可以选择自己认为合适的方法开发应用程序。我们的模式和实践小组的确提供了这些方面的指导和最佳经验，并在如何设计远程接口中包含了向导。我看不出来我们偏好于基于类的方式，实际上，使用面向消息和服务的比使用面向对象的要增长得快一些。我承认需要把服务器部件部署到客户端上，但是不好的设计就是不好的设计，别无其它。把服务器部件部署到客户端上，使服务器对象的元数据可用，可以让人们容易地使用接口或大纲（schema）。这就是说，存在一些希望每个客户端拥有服务器代码的情形，例如对等（peer-to-peer）聊天就要求客户端同时承担客户端和服务器的角色。

　　关于微软在产品中使用.NET框架组件的问题

　　· RG：微软把.NET作为扩展自己的产品的一个有用的类库，但是到目前为止，微软却没有显示出对框架组件的更大的信心。目前只有很少的.NET产品是整个使用.NET编写的；其中一个是微软的CRM……他们不希望承担为.NET重新编写代码的开销，而且没有谁强迫他们在.NET中提供全新的代码；.NET将会被寄宿，并且在需要的时候，允许通过用户提供的代码来进行扩展。

　　我的回应：我们需要把Richard的话进行分解。他说微软正在使用.NET扩展已有的产品，并且微软不希望承担重新编写.NET代码的开销。为什么我们需要重新编写完美的代码呢？.NET代码可以与已有的代码交互操作，而且你也打赌说我们将利用交互操作能力层添加那些最好的受控代码提供的新特性。我前面曾经指出过，微软在所有的软件中使用了.NET，从操作系统到开发工具再到Office。

　　· RG：微软当前的操作系统XP和Windows 2003并不依赖于.NET；而且XP中.NET是一个可选组件。

　　我的回应：上述观点最多只有一半是事实。Windows XP专业版没有使用.NET框架组件，那是因为.NET框架组件是在Windows XP专业版之后发布的。下面是.NET框架组件发布之后发布的操作系统：

　　· Windows XP多媒体中心版要求.NET框架组件支持特定的MCE应用程序。

　　· Windows XP专业平板PC版要求用.NET框架组件处理识别程序（它是一个受控应用程序）。

　　· Windows Server 200需要.NET框架组件来使用ASP.NET、UDDI服务或Sharepoint小组服务。

　　· Windows小型业务服务器2003需要.NET框架组件来使用ASP.NET、执行SBS特殊的应用程序，例如远程Web工作室和Backup Snap-in。

　　关于Longhorn和浏览器应用程序消亡的问题

　　· RG：我的看法是Avalon--更具体地说是XAML，将标志着ASP的消亡。其原因在于Avalon是一种客户端技术，而浏览器则是该分布模型的一个重要部分。XAML功能是如此丰富，以至于包含浏览器的XAML应用程序与基于过程的Avalon应用程序看起来没有差别，而且与Web服务或者Indigo（访问远程代码的机制）耦合之后，XAML应用程序会使ASP.NET应用程序看起来没有价值并且陈旧。微软为什么想毁掉ASP呢？安装ASP.NET的时候，微软会卖出一套Windows 2003，同时还可能卖出几套Visual Studio.NET。客户端可以不是Windows，因此微软不会有其它的销售（无论是产品或许可）。这是一块很大的收入来源，更糟的是，ASP.NET实际上使编写应用程序更加容易了，因此它可以被IE以外的浏览器使用。

　　我的回应：XAML将提供丰富的界面，但是ASP.NET和HTML不会离我们而去。它的价值在于，我们可以同时在两个世界中取得最佳效果，为XAML浏览器提供最佳的体验，同时保留与老式计算机的兼容。我们必须注意到，客户端应用程序与服务器应用程序之间是有差别的。服务器市场本身完全不同于客户端/消费者市场。尽管人们在谈论到微软公司垄断了90%的客户端操作系统，但是在服务器市场我们没有达到这个数字。

　　我们需要与IBM WebSphere、成百上千个的中间件产品、Oracle数据库等等产品和公司进行竞争。如果我们希望取得服务器市场的胜利，我们就必须为建立Web应用程序提供速度最快的、最可靠的、最安全的、效率最高的、客户承担得起的解决方案。谈到浏览器应用程序威胁到微软的时间大约是1996年。Web不是威胁。如果它是威胁，那为什么微软使Web变得难以置信的成功和流行呢？Richard接着说微软这样做的目的是为了客户端的收入。客户端操作系统市场，微软拥有超过90％的占有率，几乎是饱和的。服务器市场才是真正的收入增长点。在收入的问题上，典型的服务器交易需要数千美元，用于支付下面一些部分：

　　· 操作系统

　　· 事务引擎

　　· 中间件

　　· 数据库

　　根据解决方案的复杂程度，其价格可能从几千美元到几百万美元。服务器产品非常昂贵。如果你查看Web内容管理解决方案，就会发现每个处理器企业级许可的平均价格是50,000美元。我的意思是说，在服务器市场存在大量的收入来源，也受到类似IBM和其它公司的激烈竞争。你知道数据库软件市场的收入是多少吗？你相信有数十亿美元吗？你知道Oracle是排名第二的软件公司，他们的主要收入都来自数据库吗？这只是服务器软件市场中的一个机会而已。回到我的观点，我们完全忠诚于自己的服务器产品，并且要把Windows服务器和ASP.NET变成建立Web应用程序的最好的平台。

　　关于Longhorn的问题

　　· RG：我认为使Avalon可用于其它版本的Windows表明微软对Longhorn的销售缺少信心。

　　· RG：但是微软宣称Avalon将可以用于其它版本的Windows，向我表明他们对Longhorn的升级也不是那么自信，而且如果开发者不能确定客户端是否会运行Avalon应用程序，那么他们就不会为Avalon编写应用程序。

　　我的回应：形成Avalon可用于其它版本Windows的决定是由一个原因--用户需要--所驱动的。所有基本的Web研究都发现顾客抱怨下层操作系统中没有这种功能。

　　关于在产品中使用.NET框架组件的问题

　　· RG：因此，从去年的声明中可以看出，微软认为Longhorn并不是在PDC 2003上取得我们信任的伟大的.NET变革。这表明微软正在逐步对.NET失去信心。

　　我的回应：Richard，你在的文章中提到的Longhorn的关键部分--Avalon和Indigo--都是用受控代码编写的。当我们决定把赌注押在建立在.NET框架组件之上的下一代操作系统的成功的时候，怎么会表明我们对.NET失去了信心呢？你可能会争论说并非整个操作系统都是用受控代码编写的，这就是我们已经"失去了信心"。但是这是你的观点，我不认为受控代码适合于所有情形，而且微软也从来没有这样说过。微软仍然完全支持C/C++，我们拥有非常大的C/C++代码基础和大批C++顾客。我们只在适当的时候使用受控代码。

　　· RG：它的框架组件变成了Visual Basic--它是供用户开发应用程序的，而不是供微软建立操作系统或建立他们所依赖的带来收入的产品的。

　　我的回应：我避免回复那些对VB的抨击，因为有些人已经这样做了。我要指出两点，第一是使用.NET框架组件建立操作系统的问题，第二是微软的收入问题。在用.NET框架组件建立操作系统的问题上，我从来都没有说过你应该在单独的受控代码上建立操作系统。事实上，我们大量的客户不会建立操作系统。对于那些需要建立操作系统的或者需要那个层次的控制和性能的客户来说，我们拥有C/C++，而且我们绝对没有抛弃它。至于收入来源的问题，我已经列举了几个使用.NET框架组件带来收入的应用程序。微软被分成了如下所示的几个业务部门，让我们来看看哪一些在使用受控代码：

　　· Client （客户）- 使用了

　　· Information Worker （信息工人）- 使用了

　　· Server & Tools （服务器和工具）- 使用了

　　· Home and Entertainment （家庭和娱乐）- 使用了

　　· MSN - 使用了

　　· MBS - 使用了

　　· Mobile and Embedded Devices （移动和嵌入设备）- 使用了

　　我希望这些内容可以消除那些对受控代码的半真半假的报道和误解。如果有什么不对，请告诉我！

xug

MVP观点：我相信.NET


最近Richard Grimes的一篇文章，把.Net社区搅弄了一番，Visual C#的产品经理Dan Fernandez则在他的Blog上发表了一篇文章，逐条的反驳了Richard Grimes的观点。那么我也凑凑热闹，来讲一讲自己的观点，为什么Microsoft不做某些看起来“理所当然”的事情。

一、Microsoft对.Net没有信心吗？

恰恰相反，Microsoft相对IBM、SUN最大的不同就是，如果Microsoft认准的方向，会将整个Microsoft全部“押”上去，投入所有的力量，尽最大的努力做到最好。从DOS到Windows，从Win32到.Net，无不是如此。不管是IBM，还是SUN，在推广某项技术的同时，总会“留上一手”，以免“万一不利”的时候，还有备选方案，或者能够避免让整个公司受损。看起来似乎很“安全”，但是，如果连公司自己都没有“决一死战”的信心和勇气，还能指望消费者能相信自己吗？

当Lotus、WordStar领先于办公套件市场时，当几乎所有上网的人都使用Netscape时，当OS/2号称将取代DOS和Windows时，当Java似乎要将所有程序员吸引过去时，如果没有“决一死战”的信心，没有将整个公司“押”上去的勇气，你认为，Microsoft能走到今天吗？

二、为什么Microsoft自己不将所有现有产品都彻底用.Net改写掉？

一家软件公司最愚蠢的事情之一，就是公司的管理层听信了开发人员的下面这句话：“天哪，旧版本的代码简直就是垃圾，我们唯一的选择就是重头设计一个全新的系统，用最棒的技术来构建！”无数软件公司都是死在了这句话之下。

Netscape的管理层就曾经听信过开发人员的话，用全新的代码去构建Netscape的下一个版本，而不是基于旧版本进行逐步的升级。最后，似乎永远无法Release的全新版本，把Netscape彻底拖死了...

三、但是，“纯粹”的.Net，多激动人心呀！

有个专门的术语，叫做“The Myth of .NET Purity”（纯血统.Net神话），请先阅读这篇文章。我们生活在一个真实的世界，在这个世界中，已经有大量的使用Win32 API、COM等“过时”的技术构建起来的系统，而且这些系统可能还需要维护和升级。如果我们生活在一个完美的世界，那么，我们倒的确可以尝试用最新的技术去构建和升级一切系统！

顺便一提的是，Longhorn本身不是托管的（Longhorn is NOT managed），而且从一开始就没打算将其设计成一个纯.Net的OS。Longhorn仍然是以现有的Windows代码为基础，经过许多的改进而成的。重要的是，Longhorn的开发接口WinFX是托管的。

Error

众说纷纭，其实不知道怎么说，在我看来如果一个语言能够给与客户满意的软件产品就足够了。

qmsrobin

相信.net是肯定的。