我正在开发一个大型 .NET 1.1 项目,并且希望对其进行升级,主要是为了能够使用更好的工具,如 Visual Studio 2008,但也因为 .NET 中的新功能和更少的错误2.0 框架。
该项目包含 VB.NET 的大部分,但也有 C# 的部分。它是一个 Windows 窗体应用程序,使用各种第三方控件。使用 .NET 远程处理富客户端与与 MSSQL 2000 数据库接口的服务器进程对话。
如果我们决定执行升级,我们会遇到什么样的问题?
我正在开发一个大型 .NET 1.1 项目,并且希望对其进行升级,主要是为了能够使用更好的工具,如 Visual Studio 2008,但也因为 .NET 中的新功能和更少的错误2.0 框架。
该项目包含 VB.NET 的大部分,但也有 C# 的部分。它是一个 Windows 窗体应用程序,使用各种第三方控件。使用 .NET 远程处理富客户端与与 MSSQL 2000 数据库接口的服务器进程对话。
如果我们决定执行升级,我们会遇到什么样的问题?
从 .Net 2.0 开始,线程模型发生了变化,线程中未处理的异常将导致整个应用程序终止。我在更新一个执行大量线程并偶尔崩溃的应用程序时遇到了这个问题。显然 .Net 2.0 模型更健壮,因为无论如何您都应该抓住这些模型,但这是我在进行迁移时遇到的唯一真正问题。
这篇文章谈论它: http: //odetocode.com/blogs/scott/archive/2005/12/14/2618.aspx
我们现在正在考虑进行相同的迁移 Tobi。首先,您可以通过复制您的项目(或其中的一部分)并通过 .NET 2.0 编译器对其进行“试运行”来很好地了解预期内容。我的经验是 2.0 编译器会针对 1.1 编译器放任的不良编程实践给出更多警告。编译器会警告您有关隐式强制转换、“模糊”返回路径(函数不返回值的代码路径)和其他一些小问题。
以下是一些您可能会觉得有帮助的链接: .NET Framework Compatability
真的没什么。您会发现一些关于过时方法的编译警告,但通常这些警告很容易修复。
你应该大打出手,然后选择 3.5。这里的水很niiiiiiice。
看看这份关于将 .NET 2.0 应用程序升级到 3.5 的白皮书。我认为从 1.1 到 2.0 的变化更显着,但过程应该是相似的。
除了上面提到的应用程序配置之外,如果您使用任何 XSD 验证,您将需要替换一些有关加载和验证 XML 的代码。
我们处理电子邮件的方式必须改变。1.1版本使用system.WEB.mail,带有
Imports System.Web.Mail
'
Dim message As New MailMessage' this is a web.mail msg, not a net.mail msg
Dim objConn As SmtpMail
Dim objAttach As MailAttachment
'
message .From = "From@us.com"
' more properties assigned to objMail
objAttach = New MailAttachment(ExportName)
message.Attachments.Add(objAttach)
' Here's where we actually send the thing
SmtpMail.SmtpServer.Insert(0, "127.0.0.1")
objConn.Send(objMail)
新的有 system.NET.mail
Imports System.Net.Mail
'
Dim message as MailMessage ' this is a net.mail msg, not a web.mail msg
Dim data As Attachment
Dim client As New SmtpClient("127.0.0.1")
'
data = New Attachment(ExportName)
' Create the message and add the attachment
message = New MailMessage(EmailFrom, EmailTo, reportDescription)
message.Attachments.Add(data)
' Send the message
client.Send(message)
如果您使用 app.config 存储程序设置,您将看到的最多编译警告。System.Configuration.ConfigurationManager 不推荐使用 1.1 配置类。
您可能会看到来自编译器的其他警告将针对未初始化的变量(在变量声明中将它们设置为“= nothing”或“= null;”以使它们消失)和未使用的变量(编译器确定它们是安全删除)。
除了一些关于过时的东西的警告之外,大多数代码仍然应该编译。
但是对于 Visual Studio 生成的代码,您应该注意几件事。
如果您在 Visual Studio 2003 中生成了强类型数据集,您可以忘记在较新版本的 Visual Studio 中编辑它们。你必须重建它们,或者更好地用 nHibernate 之类的东西替换它们以获得最终的 OR-mapper-bliss
表单设计器仍应使用旧表单。您可能会有些困惑,因为 2005 和 2008 在这里使用部分类。因此,如果您创建新表单,代码看起来与旧表单不同。我从来没有升级过 ASP.Net 应用程序,所以我不知道 web-forms,但我想它会和 winforms 一样工作。大多数情况下它会起作用,但期待一些设计师的怪异。
.NET 1.1 和 .NET 2.0-3.5 是完全不同的框架,更重要的是,.NET 3.5 只是一组可以添加到 .NET 2.0 项目中的额外程序集 - 就核心程序集而言,实际上没有任何变化我知道——还有一个升级的编译器,它知道称为 LINQ 的语法糖、扩展方法等。
换句话说,我不认为 .NET 2.0-3.5 升级与 .NET 1.1-2.0 升级非常相似。
事情可能会编译好,但是我们在年初升级的应用程序中遇到了一些令人讨厌的运行时问题。
首先,当从 2.0 应用程序调用 1.1 Web 服务时,我们在 DateTime 对象中处理时区时遇到了许多问题,因为在序列化到线路时与 UTC 的转换似乎在框架版本之间的工作方式不同。
此外,2.0 异步 Web 服务使用基于事件的笨拙机制而不是 IAsyncResult 模式,如果您正在批处理您的请求,这将是非常痛苦的。
最后,我们有一些使用 Microsoft.mshtml.dll 托管嵌入式浏览器的遗留代码。升级到 2.0 会导致应用程序静默切换到该 dll 的较新版本,该版本具有一些与 javascript 交互相关的行为变化。最后一个案例有点晦涩,但表明迁移到较新的运行时可能会对您可能拥有的任何 COM 交互产生影响。
希望这可以帮助!
注意国际化的 RESX 文件。
当您在 .net 2.0 中重新打开 .net 1.1 表单时,RESX 文件会升级到新版本。在 .net 1.1 中,外语 .resx 文件仅包含更改。在 .net 2.0 中,默认 .resx 文件中的所有字段现在都移到了外语 resx 文件中。(例如.fr.resx)。如果您已经将表单国际化,则必须查看所有外语 resx 文件。
您可能已经使用/自己编写的一些用于大规模国际化的工具可能不再起作用,因为它们可能使用了编号资源。(多语言和基础设施)
Infragistics Winforms 控件修改 .net 1.1 中的 InitializeForm() 并使用资源编号系统访问资源。当迁移到 .net 2.0 时,Infragistics 资源的编号将失败,因为 resx 文件会重新生成。您将需要升级 Infragistics 库。
尽管您可能会收到一些已弃用的方法警告,但您可能不会遇到任何重大问题。编译器通常应该告诉您替换是什么。我知道一些 System.Configuration 的东西已经更新。
不应该有太多问题,因为理论上它是向后兼容的(我注意到 MikeeMike 关于线程异常的评论)。搬家之后,你会没事的,有很多不错的东西,比如泛型。尽管您不想一举将所有集合移植到泛型,但一旦完成此操作,您的代码应该会因为转换次数减少而更可靠 - 并且可能更快(尽管在这方面里程可能会有所不同) . 目前我即将开始我的三个产品的 .NET 2 -> .NET 4 转换。主要优势将是对多线程支持的进一步改进(并行 foreach 循环等)。