我是一个.Net开发人员，其任务是将经典的ASP网站升级到ASP.NET。该网站目前正在靠运气和泡泡糖运行，但是没有足够的时间或者金钱来阻止进度并进行完全重写。当然，在升级时，我仍然需要能够提供新功能。

我应该使用什么策略对asp.net进行逐步平滑的更改？我应该转换为单层.net解决方案，然后重构为适当的多层解决方案，还是现在应该设计业务和数据层？我应该直接升级到3.5，还是仅仅升级到1.1并在升级后升级到2.0或者3.5会更容易？

完全转换可能需要3-5个月。还有一些现有的1.1代码，这就是为什么我考虑将其用作起点。

解决方案

完整的转换/重写需要多长时间？它还将取决于我们如何构造原始项目。

我可以回答，我们应该从一开始就定位v2.0(如果需要/需要，则为3.5)。无需使自己服从框架的1.1.

试试这些链接

从ASP迁移

关键注意事项

将ASP转换为ASP.NET

从ASP到ASP.NET的迁移指南

我们可能需要查看新的ASP.NET MVC框架。灵活性水平惊人，编码风格更类似于ASP经典方法，尽管教会与国家之间的分隔要好得多。

看一下Snitz论坛(www.snitz.com)，它们目前在ASP中，但ASP.NET的端口已基本完成。这两个代码库都可供我们查看，因此我们可能会了解它是如何完成的以。

我将避免进入.NET 1.1，因为Microsoft将于10/14/2008结束对.NET Framework v 1.1的支持。扩展支持将持续到2013年10月8日，但购买通常费用昂贵。任何错误或者安全漏洞都将无法解决，这是问题。

http://support.microsoft.com/lifecycle/?LN=zh-CN&x=11&y=10&p1=1249

保罗

作为一个长期的经典ASP程序员，现在是一个ASP.NET开发人员，我会花时间在2.0框架(如果需要/需要这些功能，则为3.5)中进行适当的架构。

我的上一份工作是，我们要重建的是很多非常糟糕的经典ASP应用程序，" nuke and pave"方法是最成功的。使用现有的经典应用程序作为功能规格和线框，并以此为基础构建任务和技术规格。

不要扔掉代码！

这是我们可能会犯的最严重的错误(在大型代码库上)。查看我们不应该做的事情，第1部分。

我们已经为旧代码投入了大量精力，并解决了许多错误。扔掉它是一个经典的开发人员错误(而且我已经做过很多次了)。就像春季大扫除一样，它使我们感觉"更好"。但是，我们无需购买新公寓和所有新家具即可为房屋装潢。我们可以一次在一个房间上工作...也许有些事情只需要一个新的绘画作业。因此，这就是重构的用武之地。

对于应用程序中的新功能，请在经典的ASP中使用Cand编写它。重写此新代码时，我们将被迫模块化。如果有时间，可以将部分旧代码很好地重构到Cas中，然后逐步解决这些错误。最终，我们将用所有新代码替换应用程序。

我们也可以编写自己的编译器。很久以前，我们为经典的ASP应用程序编写了一个，以便我们输出PHP。这就是Wasabi，我认为这就是Jeff Atwood认为Joel Spolsky走出摇滚乐的原因。实际上，也许我们应该将其发货，然后我们就可以使用它了。

它允许我们在下一版本中将整个代码库切换到.NET，而仅重写源代码的一小部分。这也使很多人称呼我们为疯，但是编写编译器并不那么复杂，它为我们提供了很大的灵活性。

另外，如果这是内部唯一的应用程序，则将其保留。不要重写它，因为它是唯一的客户，并且如果我们需要以经典asp的身份运行它，则可以满足该要求。

最简单的方法是先跳入头部。获取一些asp.net书籍，然后深入Visual Studio。做例子，玩弄它，为自己创造一些乐趣。我们会边做边学。

我还在努力从经典的ASP逐步过渡到ASP.NET。我们的第一个阶段是将一些常见的逻辑从ASP包含迁移到暴露给COM Interop的.NET程序集，以便经典ASP和ASP.NET都可以调用它们。我已经使用ASPUnit编写了一些测试，以验证迁移到.NET程序集后的行为(具有更安全的重构优势)。一旦核心逻辑进入.NET，我们就可以开始在ASP.NET中创建新页面，并按照自己的步调将各个ASP页面迁移到ASP.NET。

我会推荐.NET 2.0或者3.5而不是1.1. ASP.NET MVC看起来是有吸引力的升级途径。