Actualizando de .NET 1.1 a .NET 2.0, ¿qué esperar?

Question

Estoy trabajando en un gran proyecto .NET 1.1, y existe el deseo de actualizar esto, sobre todo para poder utilizar mejores herramientas como Visual Studio 2008, pero también debido a las nuevas características y la menor cantidad de errores en el .NET 2.0 framework.

El proyecto consiste en la parte más grande de VB.NET, pero también hay partes en C#. Es una aplicación de Windows Forms, que usa varios controles de terceros. Usando .NET remoto, el cliente rico habla con un proceso de servidor que interactúa con una base de datos MSSQL 2000.

¿Qué tipo de problemas podemos esperar en caso de que decidamos realizar la actualización?

Answer 1

Nada, en serio. Encontrará un par de advertencias sobre la compilación de métodos obsoletos, pero a menudo son triviales para solucionar.

Deberías disparar a lo grande e ir por 3.5. El agua está aquí por aquí.

Answer 2

Probablemente no tenga ningún quebrando problemas, aunque puede obtener algunas advertencias de métodos obsoletos. El compilador en general debería decirle cuál es el reemplazo. Sé que algunas de las cosas de System.Configuration se actualizaron.

Answer 3

La mayoría de las advertencias de compilación que verá son si usa app.config para almacenar la configuración del programa. La clase de configuración 1.1 estaba en desuso para System.Configuration.ConfigurationManager.

Otras advertencias que puede ver que provienen del compilador serán las variables sin inicializar (configúrelas en "= nada" o "= nulo;" en la declaración de variables para que desaparezcan), y las variables no utilizadas (el compilador seguro que son seguros de eliminar).

Answer 4

Eche un vistazo a este whitepaper al evolucionar una aplicación .NET 2.0 a 3.5. Sostengo que los cambios de 1.1 a 2.0 son más significativos, pero el proceso debería ser similar.

Answer 5

La mayor parte del código debe compilarse excepto por algunas advertencias sobre que las cosas están obsoletas.

Pero hay un par de cosas que debe tener en cuenta con respecto al código generado por Visual Studio.

Si ha generado conjuntos de datos fuertemente tipados en Visual Studio 2003, puede olvidarse de editarlos en las versiones más recientes de visual studio. Tendrás que reconstruirlos o mejor simplemente reemplazarlos con algo así como nHibernate para obtener OR-mapper-bliss

El diseñador de formularios debería funcionar con formularios antiguos. Sin embargo, puede obtener algo de confusión porque 2005 y 2008 usan clases parciales aquí. Entonces, si crea formularios nuevos, el código se ve diferente de los anteriores. Nunca he actualizado una aplicación ASP.Net, así que no sé sobre formularios web, pero supongo que funcionará igual que winforms. En general, funcionará, pero se espera algo de rareza de diseñador.

Answer 6

Estamos buscando hacer la misma migración en este momento Tobi. En primer lugar, puede obtener una buena idea de lo que puede esperar al hacer una copia de su proyecto (o una parte del mismo) y darle una "ejecución en seco" a través del compilador .NET 2.0. Mi experiencia con esto fue que el compilador 2.0 da más advertencias sobre malas prácticas de programación que el compilador 1.1 dejó pasar. El compilador le advertirá acerca de conversiones implícitas, rutas de retorno "ambiguas" (una ruta de código donde una función no devuelve un valor) y algunas otras cosas menores.

Aquí hay algunos enlaces que le puede resultar útil: .NET Framework Compatability

Word Document of Breaking changes in .NET Framework 2.0

Answer 7

Además de la materia configuración de aplicación se mencionó anteriormente, si se utiliza ningún tipo de validación XSD que tendrá que reemplazar algo de código alrededor de la carga y validando XML.

Answer 8

.NET 1.1 y .NET 2.0-3.5 son frameworks completamente diferentes, y lo que es más importante, .NET 3.5 es solo un conjunto de ensambles adicionales que puede agregar a su proyecto .NET 2.0 - ninguno de los ensambles principales realmente cambió , hasta donde yo sé, y un compilador actualizado que sabe sobre la sintaxis llamada LINQ, métodos de extensión, etc.

En otras palabras, no creo que una actualización .NET 2.0-3.5 sea muy similar a una actualización de .NET 1.1-2.0.

Answer 9

Hay un cambio en el modelo de seguimiento en .Net 2.0 en adelante, donde las excepciones no controladas en un hilo provocarán que la aplicación finalice. Me encontré con esto cuando actualicé una aplicación que hacía muchos subprocesos y ocasionalmente se bloqueaba. Obviamente, el modelo .Net 2.0 es más robusto, ya que de todos modos deberías atraparlos de todos modos, pero fue el único problema real que tuve al realizar la migración.

Este artículo habla todo sobre ella: http://odetocode.com/blogs/scott/archive/2005/12/14/2618.aspx

Answer 10

cosas probablemente compilará bien, pero tuvimos algunos problemas de tiempo de ejecución desagradables con una aplicación que nos pasaron al comienzo del año.

Primero, tuvimos una serie de problemas con el manejo de zona horaria en objetos DateTime cuando llamamos a 1.1 webservices desde una aplicación 2.0, ya que las conversiones hacia y desde UTC al serializar al cable parecían funcionar de forma diferente entre versiones de framework.

Además, los servicios web asincrónicos 2.0 utilizan el mecanismo basado en eventos klutzy en lugar del patrón IAsyncResult, que es una verdadera molestia si está realizando un lote de sus solicitudes.

Finalmente, teníamos algún código heredado que hospedaba un navegador incrustado utilizando Microsoft.mshtml.dll. La actualización a 2.0 provocó que la aplicación cambiara silenciosamente a una versión más nueva de esa DLL, que tenía un comportamiento cambiado relacionado con la interacción con JavaScript. Este último es un caso poco claro, pero muestra que pasar al tiempo de ejecución más nuevo puede tener implicaciones para cualquier interacción COM que pueda tener.

Espero que esto ayude!

Answer 11

La forma en que estábamos haciendo el correo electrónico tuvo que cambiar. La versión 1.1 se utiliza System.Web.Mail, con

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) 

y el nuevo tiene 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) 

Answer 12

archivos RESX problemas de actualización

cuidado con los archivos RESX internacionalizados.

Cuando vuelve a abrir un formulario de red 1.1 en .NET 2.0, el archivo RESX se actualiza a una nueva versión. En .net 1.1, el archivo .resx de idioma extranjero solo contenía los cambios. En .NET 2.0 TODOS los campos en el archivo .resx predeterminado ahora se mueven al archivo resx de idioma extranjero. (.fr.resx por ejemplo).Si ya ha internacionalizado el formulario, habrá que examinar todos los archivos de resx de idioma extranjero.

Herramientas de internacionalización

Algunas herramientas que se haya usado/escritos ti mismo para hacer internacionalización en masa puede no trabajar más, ya que pueden haber utilizado los recursos numerados. (Multi Lang & Infragistics)

Los controles Infragistics Winforms modifican InitializeForm() en .net 1.1 y acceden a los recursos mediante un sistema de numeración de recursos. Cuando se migre a .net 2.0, la numeración de los recursos de Infragistics fallará a medida que se vuelva a generar el archivo resx. Deberá actualizar sus bibliotecas de Infragistics.

Answer 13

No debería haber demasiado problema, ya que en teoría es compatible con versiones anteriores (noto el comentario de MikeeMike sobre las excepciones de subprocesos). Después de la mudanza, estarás bien que haya algunas cosas bonitas como los genéricos. Aunque no desee exportar todas sus colecciones a los genéricos de una sola vez, una vez que haya hecho esto, su código debería ser más confiable debido a la menor cantidad de conversiones, y probablemente más rápido (aunque el millaje puede variar en este aspecto) . En este momento estoy a punto de comenzar la conversión de .NET 2 -> .NET 4 de mis tres productos. La principal ventaja serán las mejoras adicionales en el soporte de subprocesos múltiples (bucles foreach paralelos, etc.).