记住，这是1.0版本，这不是Visual Studio 7.0；这不是COM++++；这不是Visual Basic 7.0。十分确切的说，这是全新的。它和大量的新代码一起引进。你要特别仔细考虑如何计划.net的采用。特别是在以后的24个月里。<P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" one做地更好。<>然而，它里面包括许多很酷的东西。它弥补了和Java之间的巨大差距，在许多情况下，被证明比Java>你对企业什么时候或者是否转向.net有什么建议？
这是一个什么时候将他们拖、拉、或者尖叫着穿过.net的悬崖的问题，而不是是否需要穿过.net悬崖的问题，不管他们是否愿意。然而，我不希望看见许多人试图一次重写他们的所有的Visual Basic代码或者Visual C++代码。我们应该逐步的开展。.net将很快被引用到新的开发中。在Visual Studio .net出现的头一两年，你将会看到一个混合模型，新开发的代码中30％的将是ASP.net代码（我预见ASP.net的扩展将会非常非常之快），但是70％将仍然是COM，COM+代码。商业应用
Javascript:openWindowRes('DotNetMagazine/2001_12/WhereItIs/BusinessCase.htm')">计划向新技术转移
由于.net的许多优势和微软的强大的市场努力，.net技术在应用程序开发中最终将被广泛采用几乎是可以肯定的，特别是对于中小型企业....
</TABLE>我对严谨的客户的一般建议是，不要把有紧急任务的应用程序在很大程度上依赖于.net，至少在.net发布后六到九个月不要这样做，即2002年8月之前。<P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" >然而，为了实践的目的，你可以用.net做一些小的原型，一些没有紧急任务要求的程序。这取决于beta代码，第一个产品版本，或者第一个服务包能为你带来些什么。尽管如此，我们推荐你采取保守的方法。假设一个糟糕的情况：你的30%-40%代码将迁移，你将不得不重写或者重设计剩下的代码。别指望微软会提供自动工具来迁移你的代码。<>对早期的采用者也有一些好的原因。首先是显示公司在Web Services策略方面的竞争力，你正在寻找在接下来的12个月里支持Web Services最好的平台。<P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" >ASP.net是另一个原因。太多的程序员从事ASP的开发，如果你正在ASP执行或者安全方面苦苦挣扎，或者受够了整个ASP的生存空间。ASP.net是一个更强大的环境。实际上，微软已经有了大量的早期采用者，他们已经在ASP.net系统的测试版下开发。<><P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" >还有，最重要的是，如果你有一个真正的商业原因，你就应该早点采用。例如，如果你正在开发一个无线的应用程序，ASP.net有一些重要的新特征正好可以帮你实现，在许多情况下，冒险早期迁往.net是因为它在移动和无线设备方面做得更好。<>如果你不关心Web Services，这里没有一个无可抵抗的和强制性的原因，让你去很快地采用它。实际上，这就是我们说为什么大多数公司将采用一个相当渐进的曲线来采用它。有许多因素要考虑。要看多少人采用这种主流技术。要参考专家的建议。要看第三方的支持、前景市场的支持。要看本地的.net服务的组件提供者。要看所有的测试公司。要看源代码管理公司的提供。Visual Studio .net发布的第一年，早期的采用者将会把他们的代码按70/30的比例划分在旧平台和新平台上。在大约一年半后，我们期待比率会变成30/70。你将看到70％的本地.net代码将出现在基于微软的解决方案中。传统的公司将在Visual Studio .net发布后的24到36个月开始迁移。大约2005年，我们将期待95％的本地.net开发。让我们来讨论.net语言和在迁移应用程序到.net的过程中起作用的部分，从Visual Basic .net开始。
这是一个好消息，Visual Basic 变成了一种成熟的语言。它开始面向对象设计，使用类框架和.net中的其它零碎，VB.net已经变成了一个更强大的工具集。事实上，还没有哪些商业应用程序不能用VB来实现。<P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" Basic开发者将有一个艰难的学习过程才能最后完成迁移。<>不利的是VB.net有了许多新的语法和设计问题。这意味着对Visual>我认为在接下来的48个月中，60％或者更多的C++开发者将转向C#.C++将仍然会使用。它将会使用在COM和COM+领域，甚至在.net中它将仍然会被使用，但是它将仍是系统层的编程语言。C#的快速开发应用程序的能力和C#和.net组件模型集成工作的能力将会起到一个大的作用。这是我从用户那儿听到的最多的问题。我可能今年与八九百人讨论过，几乎一半的问题都是直接地或间接地关于.net与Java相比较的问题。我告诉他们我认为Microsoft和Java将支配电子商务应用程序开发，也就是说，大多数新的项目将会基于这两个平台之一。他们到2005年将占有80%的市场。谁也不会。大多数大公司将会两者都使用。现在，Java基于它的跨平台的能力，在大公司中还有很强的实力。小公司不能负担得起使用两者，他们将会转向其中之一。微软因为它的成本低和众多的开发者，对中小型组织还是很有吸引力的。为了完成.net难题还需要做什么？
中间件架构应该被拿走。我们需要MTS的替代品。我们需要一个与本地.net同步的messaging broker。更有效的是，我们需要作为本地.net服务的COM+的替代品。当然。你已经有了数据库APIs和类似的功能。但是我们需要的是Java 2平台、J2EE在.net上的替代品。现在，如果你仔细看那些零碎功能的话，我们已经有了一半了。有一个清晰的Java 2平台、标准编辑器(J2SE)的替代品，不久我们就会有Java 2平台、J2ME的替代品—J2ME与.net Framework紧密相关。但是，微软还没有建立一个真正的J2EE的替代品。我们需要看到.net技术注入SQL Server，这在SQL server的下一个主流产品Yukon中将会看到。我们需要看到各种.net技术，像BizTalk，具有讽刺意味的是，它现在还什么都不能做。微软的门户网站，电子商务软件，所有的零碎东西都需要在.net上执行。他们需要整合将被淘汰的技术。你提到了Web Services的重要性，那我们将会先看到哪种类型的Web Services呢？
我前面提到大多数公司将会同时使用Java和微软的技术。Web Services是一个很好的方法来整合它们并使他们可以交互操作。我们认为Web Services在移动基于所有权信息方面起着相当重要的作用。<P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" Services的问题，就象其它问题一样，还很不成熟。实际上，现在整个XML消息的概念还极不成熟。我们现在只有所有的5%或者10％，我们最终需要全部的XML基础。<>Web><P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" Services将是一个文化问题。企业将不得不适应系统开放的思想和实时工作的思想。好消息就是有了许多用B2B的基础。一些特别纵向联合的企业已经大规模地采用这种方式。<>我认为抑制在公共的互联网上使用Web>我认为在使用这项技术时仍然缺少技巧。许多开发者将把Web Services当作分布式对象模型一样执行。他们将说“好的，Web Services仅仅是包装了DCOM或者COM组件和Enterprise Java Beans组件，”，这是不对的。Web Services是松耦合的、异步消息协议，而不是锁定的、同步机制。人们第一次将不可避免的犯错误。<P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" Services将不会变成主流。<Services会有很好的前途，它会是无处不在的相当廉价的服务通讯机制。不管这些服务是在一个子系统，一个企业、跨越一个行业内，或者甚至跨越不同的行业。你可以减少进入这个商业领域的障碍。但是这些好处将不得不和组织结构带来的新问题相比较。这样，我们认为2003年之前的这段时间，Web >你可以相信Web>这是现在Web Services的一个大黑洞。我们还没有看到任何好的定价模式。我认为我们将会看到，在某种程度上，小的付款模式将会一点点出来。但是还没有回答大的付款模式的例子。你知道，我把HailStorm看作是一个大的、具体化的Web Services的例子。然而现在我听到大量的反对声，因为它是微软的。人们认为这是微软控制互联网的“Phase II”。我相信如果它不是从微软而是其他的公司，HailStorm将会直接受到大家的欢迎。让我惊讶的是，如果AOL或者和它的合作伙伴不提出和HailStorm长期竞争力的产品。我相信它会成功。我认为人们非常关注的电子商务将会有同样纵向联系的市场。已经转向电子商务的行业将会是第一个使用Web Services的行业。它是下一个逻辑革命。</A>
托管代码 (managed code)由公共语言运行库环境（而不是直接由操作系统）执行的代码。托管代码应用程序可以获得公共语言运行库服务，例如自动垃圾回收、运行库类型检查和安全支持等。这些服务帮助提供独立于平台和语言的、统一的托管代码应用程序行为。
托管代码是可以使用20多种支持Microsoft .NET Framework的高级语言编写的代码，它们包括：C#, J#, Microsoft Visual Basic .NET, Microsoft JScript .NET, 以及C++。所有的语言共享统一的类库集合，并能被编码成为中间语言(IL)。运行库编译器（runtime-aware compiler）在托管执行环境下编译中间语言（IL）使之成为本地可执行的代码，并使用数组边界和索引检查，异常处理，垃圾回收等手段确保类型的安全。
在托管执行环境中使用托管代码及其编译，可以避免许多典型的导致安全黑洞和不稳定程序的编程错误。同样，许多不可靠的设计也自动的被增强了安全性，例如 类型安全检查，内存管理和释放无效对象。程序员可以花更多的精力关注程序的应用逻辑设计并可以减少代码的编写量。这就意味着更短的开发时间和更健壮的程序。
简单点说，托管代码是一microsoft的中间语言，他主要的作用是在.NET FRAMEWORK的CLR执行代码前去编译源代码，也就是说托管代码充当着翻译的作用，源代码在运行时分为两个阶段：
1.源代码编译为托管代码；（所以源代码可以有很多种，如VB,C#,J#)
2.托管代码编译为microsoft系统的.net平台专用文件(如类库、可执行文件等)。
.NET开发框架的几个主要组成部分：首先是整个开发框架的基础，即通用语言运行时以及它所提供的一组基础类库；在开发技术方面，.NET提供了全新的数据库访问技术ADO .NET，以及网络应用开发技术ASP .NET和Windows编程技术Win Forms；在开发语言方面，.NET提供了VB,VC++,C#, Jscript等多种语言支持；而Visual Studio .NET则是全面支持.NET的开发工具。下面就让我们来一步步的来了解它们：
通用语言运行时，即Common Language Runtime 。Microsoft .NET 给开发人员带来了一种全新的开发框架，而通用语言运行时则处于这个框架的最低层，是这个框架的基础。开发人员对于所谓的C运行时、VB运行时、Jave虚拟机这些概念已经非常熟悉了，而通用语言运行时则为多种语言提供了一种统一的运行环境。另外它还提供了更多的功能和特性，比如统一和简化的编程模型，用户不必迷惑于Win32 API和COM；避免了DLL的版本和更新问题（常称为DLL地狱），从而大大简化了应用程序的发布和升级；多种语言之间的交互，例如我们甚至可以在VB中使用C++编写的类；自动的内存和资源管理等等。Microsoft .NET正是基于通用语言运行时，实现了这些开发人员梦寐以求的功能。
基于通用语言运行时开发的代码称为受控代码，它的运行步骤大体如下：首先使用一种通用语言运行时支持的编程语言编写源代码，然后使用针对通用语言运行时的编译器生成独立于机器的微软中间语言（Microsoft Intermediate Language），同时产生运行所需的元数据，在代码运行时再使用即时编译器（Just In Time Compiler）生成相应的机器代码来执行。
当然对于开发者而言，他们除了关心通用语言运行时提供那么多新特性外，它究竟给开发者提供了什么样的编程接口，这就是基础类库（Base Class Library）。这组基础类库包括了从输入输出到数据访问等各方面，提供了一个统一的面向对象的、层次化的、可扩展的编程接口。它使用一种点号分隔的方法，使得查找和使用类库非常容易。例如基础类库中的根，它的命名空间是System，提供数据访问的类库的命名空间是System.Data。在使用时，开发者只需在自己的应用中添加所需的基础类库的引用，然后就可以使用这个类库中的所有方法、属性等等。跟传统的Windows编程相比，使用和扩展基础类库都非常容易，这使得开发者能够高效、快速的构建基于下一代互联网的网络应用。
几乎所有的应用程序都需要访问从简单的文本文件到大型的关系型数据库等各种不同类型的数据 。在Microsoft .NET中访问数据库的技术是ADO .NET。ADO .NET提供了一组用来连接到数据库，运行命令，返回记录集的类库，与从前的ADO(ActiveX Data Object)相比，Connection和Command对象很类似，而ADO .NET的革新主要体现在如下几个方面：
首先，ADO .NET提供了对XML的强大支持，这也是ADO .NET的一个主要设计目标。在ADO .NET中通过XMLReader，XMLWriter， XMLNavigator， XMLDocument等可以方便的创建和使用XML数据，并且支持W3C 的 XSLT、DTD、XDR等标准。ADO .NET对XML的支持也为XML成为Microsoft .NET中数据交换的统一格式提供了基础。
其次，ADO .NET引入了DataSet的概念，这是一个驻于内存的数据缓冲区，它提供了数据的关系型视图。不管数据来源于一个关系型的数据库，还是来源于一个XML文档，我们都可以用一个统一的编程模型来创建和使用它。它替代了原有的Recordset的对象，提高了程序的交互性和可扩展性，尤其适合于分布式的应用场合。
另外，ADO .NET中还引入了一些新的对象，例如DataReader可以用来高效率的读取数据，产生一个只读的记录集等等。简而言之，ADO .NET通过一系列新的对象和编程模型，并与XML紧密结合，使得在Microsoft .NET中的数据操作十分方便和高效。 ASP .NET是Microsoft .NET中的网络编程结构，它使得建造、运行和发布网络应用非常方便和高效 。我们可以从以下几个方面来了解ASP .NET：
1. ASP .NET网络表单
ASP .NET网络表单的设计目的就是使得开发者能够非常容易的创建网络表单，它把VB中的快速开发模型引入到网络开发中来，从而大大简化了网络应用的开发。具体的说：在ASP .NET中可以支持多种语言，不仅仅支持脚本语言，通用语言运行时支持的所有语言在ASP .NET中都可以使用；代码和内容分开，在现在的ASP(Active Server Pages)开发中，内容和脚本交错，维护和升级很困难，将他们分开可以使得开发人员和设计人员能够更好的分工合作，提高开发效率；另外在ASP .NET中通过引入服务器端控件，将类似VB的快速开发应用到了网络开发中来，这样大大提高了构建网络表单效率，并且服务器端控件是可扩展的，开发者可以建造自己需要的的服务器端控件。
2. ASP .NET网络服务
网络服务（Web Service）是下一代可编程网络的核心，它实际上就是一个可命名的网络资源，可用来在Internet 范围内方便的表现和使用对象，就像使用今天的 COM对象一样，不同的是使用和表现网络服务是通过SOAP（简单对象访问协议）甚至HTTP来实现的。在ASP .NET中，建造和使用网络服务都非常方便：
在ASP .NET中建造网络服务就是编写一个后缀为.ASMX的文件，在这个文件中加入想要表现出来的方法就可以了，网络服务的建造者不需要了解SOAP，XML的细节，只需要把精力集中在自己的服务本身，这也为独立软件服务开发商提供了很好的机会；使用网络服务最简单的方式就是使用HTTP协议（HTTP GET 或HTTP POST），用户只需要直接访问网络服务（.ASMX文件）的URL即可；当然用户还可以通过SOAP在自己的应用中更灵活的使用网络服务。
3. ASP .NET应用框架
ASP .NET应用不再是解释脚本，而是编译运行，再加上灵活的缓冲技术，从根本上提高了性能；由于ASP .NET的应用框架基于通用语言运行时，发布一个网络应用，仅仅是一个拷贝文件的过程，即使是组件的发布也是如此，更新和删除网络应用，可以直接替换/删除文件；开发者可以将应用的配置信息存放XML格式的文件中，管理员和开发者对应用程序的管理可以分开进行；提供了更多样的认证和安全管理方式；在可靠性等多方面都有很大提高。
传统的基于Windows的应用（Win Forms），它仍然是Microsoft .NET战略中不可或缺的一部分。在Microsoft .NET中开发传统的基于Windows的应用程序时，除了可以利用现有的技术例如ActiveX控件以及丰富的Windows接口外，还可以基于通用语言运行时开发，可以使用ADO .NET、网络服务等，这样也可以实现诸如避免DLL地狱、多语言支持等.NET的新特性。从上面的介绍中我们已经知道Microsoft .NET开发框架支持多种语言，在目前的测试版中已经支持 VB,C++，C#和Jscript四种语言以及它们之间的深层次交互
。而且微软支持第三方生产针对Microsoft .NET的编译器和开发工具，这也就是说几乎所有市场上的编程语言都有可能应用于Microsoft .NET开发框架。这样开发者可以任意选择自己喜爱的语言，这种开放和交互的特性正是开发者所热爱的。
需要特别指出的是，微软在Microsoft .NET中推出了全新的C#语言，这种全新的面向对象的语言使得开发者可以快速的构建从底层系统级到高层商业组件的不同应用。C#在保证了强大的功能和灵活性的同时，给C和C++带来了类似于VB的快速开发，并且它还针对.NET作了特别设计，比如C#允许XML数据直接映射为它的数据类型等等，这些特性结合起来使得C#成为优秀的下一代网络编程语言。
与此同时Microsoft .NET对原有的VB和C++也做了很大的改进，使得它们更加适应Microsoft .NET开发框架的需求。例如在Visual Basic .NET中增加了继承等面向对象的特性，结构化的出错处理等等；可管理的C++扩展，大大提高了利用C++来开发Microsoft .NET应用的效率等。
Visual Studio .NET作为微软的下一代开发工具，它和.NET 开发框架紧密结合，是构建下一代互联网应用的优秀工具，目前已经有Beta测试版面世。Visual Studio .NET通过提供一个统一的集成开发环境及工具，大大提高了开发者的效率；集成了多种语言支持；简化了服务器端的开发；提供了高效地创建和使用网络服务的方法等等。 .NET框架的一个主要目的是使COM开发变得更加容易
。COM开发过程中最难的一件事是处理COM基本结构。因此，为了简化COM开发，.NET框架实际上已自动处理了所有在开发人员看来是与“COM”紧密相关的任务，包括引用计算、接口描述以及注册。 必须认识到，这并不意味着.NET框架组件不是COM组件。事实上，使用Visual Studio 6.0的COM开发人员可以调用.NET框架组件，并且在他们看来，后者更像是拥有iUnknown数据的COM组件。相反，使用Visual Studio.NET的.NET框架开发人员则将COM组件视作.NET框架组件。
为了避免引起误解，这里需对这种关系加以特别说明：COM开发人员必须手动去做大多数.NET框架开发人员可以在运行时自动执行的事情。例如，必须手写COM组件的安全性模块，且无法自动管理模块占用的内存，而在安装COM组件时，注册条目必须放进Windows注册表中。对.NET框架而言，运行时实现了这些功能的自动化。例如，组件本身是自我描述型的，因而无需注册到Windows注册表中便能安装。
当把COM与Microsoft事务服务器(MTS)和分布式COM(DCOM)结合在一起时，就变成了COM+。COM+提供了一组面向中间层的服务。特别是COM+提供了进程管理功能和数据库与对象连接池处理功能。在将来的版本中，它还将提供一种称为分区的功能——专门为应用程序服务提供商设计的更强大的进程隔离功能。
COM+服务主要面向中间层应用程序开发，并主要为大型分布式应用程序提供可靠性和可扩展性。这些服务是对.NET框架所提供服务的补充；通过.NET框架类，可以直接访问这些服务。 .NET框架有几个要素值得一提
。首先是它的安全系统和配置系统。这两个系统协同工作，有力地遏止了运行不安全代码的可能性，并大幅度减少了号称“DLL Hell”的对应用程序进行配置时所面临的挑战。
安全系统是一个高度细化、基于事实的系统，它赋予开发人员和管理员多种代码处理权限（而不仅仅是“on”或“off”）。将来，还会根据代码本身的核心要素来决定如何实施上述权限。
例如，当.NET框架应用程序被下载到某一系统中时，它会申请一组权限（诸如对临时目录的写入权限）。运行时将收集有关应用程序的事实信息（诸如：它是从何处下载的、是否用了有效签名、甚至它访问系统的准确程度），并按管理策略决定是否允许应用程序运行。运行时甚至还可告之应用程序它无法授权申请的所有权限，并允许应用程序自行决定是否继续运行。
有这种安全系统作保障，许多应用程序配置问题便会迎刃而解。开发人员和管理员（最终是用户）所面临的最大挑战之一是版本的管理问题。如果在您新装了某个应用程序之后，一切都限于瘫痪状态，而在这之前系统一直运行得非常良好，那么最大的可能是新安装的应用程序重写了一些共享库，并极有可能修正了现有应用程序正使用的程序错误。这种情况出现的频率很高，以致人们将它称为：“DLL Hell”。
.NET框架拥有的几项高级功能可以彻底消除“DLL Hell”现象。首先，它有一个非常强大的内部命名系统，能够有效地防止两个库因互相重名而被错当为对方的情况发生。除此之外，它还提供一项被称作“并行”配置的新功能。如果前例中新安装的应用程序确实重写了共享库，现有应用程序可对该库进行修复。等现有应用程序再次启动时，它会检查所有的共享文件。如果发现文件被更改，同时这些更改又是不兼容的，则它可以请求运行时提取一个它可以使用的版本。得益于强大的安全系统，运行时可以安全地执行该操作，这样应用程序就完成了本身的修复工作。
总之，Microsoft .NET开发框架在通用语言运行时的基础上，给开发者提供了完善的基础类库、下一代的数据库访问技术ADO .NET、网络开发技术ASP .NET，开发者可以使用多种语言及Visual Studio .NET来快速构建下一代的网络应用。随着相关的互联网标准及技术的普及，可以预言将会有越来越多的开发者采用这种开发结构，开发出丰富多样的下一代互联网应用来。
