c# - versiones - Actualizando de.NET 1.1 a.NET 2.0, ¿qué esperar?
que version de net framework debo instalar (13)
La forma en que estábamos haciendo el correo electrónico tuvo que cambiar. La versión 1.1 usa 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 = "[email protected]"
'' 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)
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 .NET 2.0 marco.
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?
.NET 1.1 y .NET 2.0-3.5 son marcos completamente diferentes, y lo más importante, .NET 3.5 es simplemente un conjunto de ensambles adicionales que puede agregar a su proyecto .NET 2.0. Ninguno de los ensamblajes principales realmente se modificó, en la medida de lo posible. Soy consciente, 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 .NET 1.1-2.0.
Además de las cosas de configuración de la aplicación mencionadas anteriormente, si usa cualquier validación XSD necesitará reemplazar algún código para cargar y validar XML.
Eche un vistazo a este documento técnico sobre la evolución de 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.
Es probable que no tenga problemas de interrupción , aunque puede recibir 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.
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 pueden ser útiles: Compatibilidad con .NET Framework
Documento de Word de los cambios de última hora en .NET Framework 2.0
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 hacer que desaparezcan), y las variables no utilizadas (el compilador está seguro de que están seguro de eliminar).
La mayoría del código aún debe compilarse, excepto por algunas advertencias sobre el hecho de 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 la OR-mapper-bliss definitiva
El diseñador de formularios debe seguir trabajando 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 actualicé 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.
Nada en realidad. 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í.
Es probable que las cosas compilen bien, pero tuvimos algunos problemas desagradables de tiempo de ejecución con una aplicación que actualizamos a principios de año.
En primer lugar, tuvimos una serie de problemas con el manejo de la zona horaria en los objetos DateTime al llamar a los servicios web 1.1 desde una aplicación 2.0, ya que las conversiones hacia y desde UTC al serializar al cable parecían funcionar de manera diferente entre versiones de framework.
Además, los servicios web asincrónicos 2.0 usan el mecanismo basado en eventos klutzy en lugar del patrón IAsyncResult, que es una verdadera molestia si estás haciendo un lote de tus solicitudes.
Finalmente, teníamos algún código heredado que hospedaba un navegador integrado usando 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!
Se produce un cambio en el modelo de seguimiento en .Net 2.0 en adelante, donde las excepciones no controladas en un hilo provocarán la terminación de toda la aplicación. 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 al respecto: http://odetocode.com/blogs/scott/archive/2005/12/14/2618.aspx
Resolución de problemas de actualización de archivos RESX
Tenga 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 puede haber usado / escrito usted mismo para hacer la internacionalización en masa pueden no funcionar más, ya que pueden haber usado recursos numerados. (Multi Lang e Infragistics)
Los controles Infragistics Winforms modifican InitializeForm () en .net 1.1 y acceden a los recursos usando 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.
No debería haber demasiado problema, ya que en teoría es retrocompatible (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.).