一直以来，我都是使用同一台机器上运行VS.NET 2003 beta版和最初版本的VS.NET。每个版本用的都是Framework 1.1的框架，这样大大的提升了框架的匹配需求，只安装了Framework 1.1的机器上运行全套的测试套件。
这一点非常棒，但仍会有一些版本问题。例如，假设你的用户没有很快地升级框架来匹配需求。只要你避免在框架中运用1.1版本的任何新功能，你就可以针对1.0框架来构建你的程序集。VS.NET可以让你在创建应用程序时，针对Framework 1.1、Framework 1.0或两者兼顾。注意，这些设置不会改变程序的可执行性，而是会改变你的应用程序的配置文件。配置文件指定了要加载的每个.NET Framework程序集的版本。#t#
遗憾的是，如果你创建的应用程序同时兼顾了Framework 1.0和Framework 1.1版本，那么你就需要做更多的测试。如果应用程序两者兼顾，那么在设计时，VS.NET用Framework 1.1构建应用程序。在运行时，如果VS.NET用Framework 1.0配置应用程序，就会出错。如果应用程序在Framework 1.0上运行时运用了1.1的功能，那么就会出现一个运行错误。几个月来，我一直运用该功能创建目的框架为Framework 1.0的应用程序。的确很有用，只要你确保程序只用Framework 1.0。测试应该会发现任何问题，但在发布任何软件前，你应该在只安装了Framework 1.0的机器上运行全套的测试套件。
VS.NET 2003延续了Microsoft对推动企业开发所做的努力。它的一个副作用就是程序变得越来越大了。例如，我有一个解决方案，它包含了40多个不同的项目。在处理这种类型的解决方案时，最初版本的VS.NET有时侯会有问题。VS.NET 2003解决了该问题，现在，当你处理一个特定的解决方案时，可以更容易在项目之间进行切换。VS.NET 2003也可以记录你现在正编辑的是哪个项目。这就意味着，Framework 1.1运用当前项目的任何命令（如Find in Files）都只对当前项目起作用。如果你想自己设置当前项目，可以关闭该功能。只需要导航到Tools|Options，然后在Envrironment | Projects and Solutions中清除“Track Active Items in Solution Explorer”项就可以了。
另外一个很酷的功能是引用Web命名。假设你在开发机器上构建了一个Web service和一个Web service客户端，目的是可以在其它地方部署该Web service。最初的VS.NET版本会为这些Web services创建一个名为“localhost”的名字空间。VS.NET 2003可以让你给这个Web service引用一个更有意义的名字。
的确，移动性、安全性以及对框架的其它改进都很好。但我最喜欢的新功能是接口的代码生成功能。在你使用C#或VB.NET时，如果声明了对某个函数的支持，IDE就会为它添加stubs。在C#中，你需要按Tab键。然后VS.NET会添加stubs并将它们放在一个区域中。在VB.NET中，当你编写了Implements语句后按Enter时，VS.NET 2003就添加了方法。当你在编写大的接口或来源于其它接口的接口时，跟踪遗漏了哪些函数或输错了哪些函数时，该功能就可以节省许多编译周期。
当然，最终的问题是：你需要VS.NET 2003吗？该版本不像最初版本那样很具创新性，但Framework 1.1中引进的许多功能可以让你节省很多时间和精力，可以让你将更多的精力集中在你想创建的解决方案上，而不是你用来创建该解决方案的代码和环境上。例如，与事件处理程序结合在一起的接口自动生成代码功能和C#中的覆盖功能每天就可以节省我几个小时的代码输入时间。另外，Framework 1.1增强的安全性能对客户来说也是个很好的功能，如今，没有人愿意带来任何病毒危险。即使你不会立即运用移动性功能，但在不久的将来你一定会需要该功能的。
