发现一个分阶段的移植策略如何能够避免移植过程中的障碍。
by Barry Bloom

解决方案所用环境: ASP.NET, .NET Framework, Application Center 2000

Visual Studio .NET (VS.NET) 的发布让我们部门的开发人员感到非常兴奋。自从VS.NET两年前在奥兰多的专业开发人员大会（PDC）上被引进以来，我们就一直在关注.NET。 最近.NET的发布使我们部门的领导阶层（包括我自己）都松了一口气，因为我们终于可以完全致力于用.NET开发了。当然，一个遗留的大问题是我们如何继续进行开发，以及我们应该将哪些应用程序移植到.NET。关于我们应该移植什么样的应用程序的争论仍很盛行，但那并不意味着你不能学习一些好的策略来帮助你将传统的应用程序移植到.NET。

在我开始介绍策略前，让我先解释一下我用的这个词“传统的”。我第一次听到这个术语是在Redmond由.NET构架组主办的一个作家大会上。一位发言人特别地不断地提到老式的Active Server Pages (ASP)/COM应用程序，把它们称为“传统的ASP”和“传统的COM”。这让我感到很有趣，因为他拒绝将这些Distributed Internet Architecture (DNA) 工具称为“遗留物”。我们拥有的不是遗留的Windows应用程序——实际上指没有用.NET的我们所有的Windows应用程序——取而代之，我们拥有的是“传统的Windows应用程序”。我发现，从Microsoft的角度来看，这个术语也用得很好。当你开始谈论把老的应用程序移植到.NET构架的移植策略时，将那些应用程序称为“传统的”吧，看看我们是否可以理解这个术语。没有人想用遗留的代码，但我打赌他们喜欢用传统的代码。

在我的公司， 我们有用共享的COM+组件来计算税率的传统的应用程序。当我们构建新的.NET应用程序时，我们给这些现有的税率计算服务增加一个XML服务接口。因为我们的环境大都依赖于这些重要的服务，所以对于我们现有的编码基数，我们必须继续用传统的COM+组件，对于.NET应用程序，我们用XML Web service部署新的服务器。为了获得最高程度的可用性，我们进行一个分阶段的移植，对于整个计划，一开始用四个服务器，结果用两个服务器，让它们为我们传统的和.NET应用程序服务。