¿Efectos de ASP.NET Framework de pasar de 2.0 a 3.5?

visual-studio visual-studio-2008

Question

Empecé a usar Visual Studio 2008 y siempre me pide que actualice mi proyecto de sitio web 2.0 a 3.5 cada vez que se abre.

• ¿Qué ocurre efectivamente cuando "actualizo" un proyecto de sitio web de 2.0 a 3.5 en Visual Studio?
• ¿Actualiza mi web.config? ¿Cómo cambia exactamente mi proyecto / sitio web / código?
• ¿Existe algún potencial para que cualquier método 2.0 / configuración BREAK después de la actualización a 3.5?
• ¿Hay algún problema involucrado?

Answer 1

¿Existe algún potencial para que cualquier método 2.0 / configuración BREAK después de la actualización a 3.5?

Siempre hay posibilidad de rotura, pero te sugiero que respaldes todo y lo apruebes más temprano que tarde. Si sigues posponiéndolo, descubrirá que es mucho más doloroso cuando tiene que compensar varias versiones de los cambios de la API de Framework.

Answer 2

Actualiza su web.config para usar algunos dlls más nuevos. Aún no he experimentado ningún cambio de rotura.

Answer 3

He actualizado varios proyectos de esta manera y no he tenido cambios importantes. Como experimento, hice esto en un proyecto que el resto de mi equipo estaba usando en VS2005 y tampoco experimenté problemas, aunque me aseguré de no verificar el archivo de mi solución (que guardamos localmente como una cuestión de política de todos modos).

Los resultados han sido transparentes para todos, con la ventaja adicional de poder apuntar a diferentes versiones de .Net.

Answer 4

Según tengo entendido, .NET 3.5 es .NET 2.0 con algunas bibliotecas adicionales, para nuevas características como LINQ. Por lo tanto, debería poder actualizar sin problemas.

Answer 5

Si actualiza el tipo de proyecto, simplemente actualiza los archivos .csproj / .vbproj para que funcionen con la nueva versión. Puede establecer la base de código de destino dentro de la configuración del proyecto para conservar la funcionalidad en las versiones de marco anteriores.

Answer 6

Si, en el asistente de actualización, elige no orientar su código a 3.5, nada de su aplicación cambiará. La principal diferencia es que "estudiará" su solución y proyectará los archivos de manera que no puedan ser abiertos por un IDE anterior.

Answer 7

Todos los cambios estarán en el archivo web.config. Crece ENORME con nuevas configuraciones para ensamblados .NET 3.5, controladores AJAX y configuraciones de configuración IIS7. Pero hay toneladas de documentaciones en Internet que describen las diferencias.

Answer 8

(Como se menciona en otras partes de las otras respuestas, más algunos extras :)

• La conversión de una solución VS 2005 a VS 2008 significa que tendrá que mantener duplicados, u otros también deben usar Visual Studio 2008 (mientras que el formato del archivo del proyecto (que de su pregunta no está usando de todos modos) no cambia en teoría entre 2005 y 2008, los archivos de la solución no son compatibles ...)

• La conversión del sitio web a 3.5 afecta principalmente a web.config. Algunas referencias se agregan a unos pocos ensamblados predeterminados de 3.5, como System.Core.dll. Y agregará las secciones de IIS 7 (que todo se ignora si el sitio se publica en un cuadro de IIS6).

• En general, no ve nuevos errores de tiempo de compilación de la actualización (y si lo hace, no esperaría muchos). Tanto los equipos C # como VB se han esforzado para garantizar la compatibilidad con versiones anteriores de todas las nuevas palabras clave LINQ ... para que pueda tener un nombre local "var" en un método llamado "where" en una clase llamada "from" y compila todo solo bien ... (una mejora para cualquiera que tuviera símbolos llamados "operador" en una base de código de VB 2003 al actualizar a 2005 :-)

• Obviamente, una vez que haya cambiado, necesitará .NET 3.5 en cualquier servidor que implemente. Sin embargo, a diferencia de .NET 1.1 vs .NET 2.0, no hay problemas de la versión CLR / AppPool de los que preocuparse, todo se ejecuta en .NET 2.0. Lea a continuación ...

Si le preocupa la regresión en tiempo de ejecución para cualquier código .NET 2.0 existente, hay buenas noticias y malas noticias.

La buena noticia: la regresión es prácticamente desconocida.

Las malas (u otras buenas noticias): si instaló .NET 3.5 en un servidor que ejecuta 2.0 sitios, ya ha probado las regresiones :)

Como se mencionó anteriormente, .NET 3.5 es realmente solo .NET 2.0 CLR con algunos ensamblajes adicionales y nueva funcionalidad de compilación.

Y cuando instala .NET 3.5, también instala un paquete de servicio para .NET 2.0 y 3.0. Por lo tanto, cualquier cambio importante ya estaría afectando a los sitios web de .NET 2.0, sin ningún paso de actualización explícito.

Scott Hanselman publicó aquí una buena explicación de la diferencia entre la versión de CLR y la versión de .NET Runtime hace un tiempo.

Un último comentario: debe tener en cuenta que al usar VS 2008 para apuntar a .NET 2.0, en realidad está compilando contra el .NET 2.0 actualizado. Por lo tanto, si utiliza uno de los métodos (muy pocos y raramente utilizados) añadidos silenciosamente a la versión actualizada de .NET 2.0, como GCSettings.LatencyMode, cuando implemente en un equipo que tenga el .NET 2.0 RTM original, lo hará no se ejecuta Lea sobre esto con más detalle aquí , y Scott también publicó una lista completa de cambios de API aquí )

Aunque encontrar un problema como este es bastante improbable, de alguna manera (incluso excluyendo los beneficios de las nuevas características 3.5), estás mejor con 3.5 :-)