Estamos planeando mover una aplicación heredada que utiliza la biblioteca corporativa 4.1 que usa .Net 3.5 en una aplicación web .Net 4.0..Net 3.5 Dll en una aplicación .Net 4.0 cualquier problema
Nos preguntamos ¿causará esto algún problema de rendimiento? ¿Se ejecutará el código .net 3.5 en un grupo de aplicaciones diferente?
Finalmente he encontrado una respuesta a esto. El problema de rendimiento que mencioné previamente que mi equipo descubrió se debe a algo más. No carga .NET 3.5 en .NET 4.0 App Domain.
lectura de este artículo: http://msdn.microsoft.com/en-us/magazine/ee819091.aspx
En SxS-Proc no resuelve los problemas de compatibilidad enfrentan los desarrolladores de bibliotecas . Cualquier bibliotecas directamente cargados por una aplicación - ya sea a través de una referencia directa o un Assembly.Load - se seguir para cargar directamente en el tiempo de ejecución y dominio de aplicación de la aplicación de cargarlo. Esto significa que si una aplicación se vuelve a compilar para funcionar contra el .NET Framework 4 tiempo de ejecución y todavía tiene dependientes conjuntos construidos contra .NET 2.0, esos dependientes se carga en el .NET 4 tiempo de ejecución también. Por lo tanto, todavía recomendamos probar sus bibliotecas frente a todas las versiones [s] de la estructura que desea admitir. Esto es una de las razones por las que hemos continuado para mantener nuestro alto nivel de compatibilidad con versiones anteriores .
Por lo tanto, no hay ningún problema al cargar los ensamblados .NET 3.5 directamente en las aplicaciones .NET 4.0 sin recompilarlos en .NET 4.0.
4.0 es un superconjunto de 3.5 por lo que no debería haber ningún problema. Todos ustedes 3,5 código funcionará como lo había hecho cuando estaba construido con VS 2008. Es necesario seguir este primer
Hay un enlace de MSDN What's New in the .NET Framework 4
Migration Guide to the .NET Framework 4
.NET Framework 4 RTM Application Compatibility Walkthrough
Si busca un Google usted encontrará muchos artículos titulados algo así como "Novedades en 2010". Usted no va a encontrar cosas como "¿Cuál es diferente"
A excepción de esta pequeña golosina De MSDN:
.NET Framework 4 es altamente compatible con las aplicaciones que están construidas con anterior de .NET Framework versiones, a excepción de algunos cambios que se hicieron para mejorar la seguridad, cumplimiento de normas, corrección, fiabilidad y rendimiento.
.NET Framework 4 no utilizar automáticamente su versión del tiempo de ejecución de lenguaje común para funcionar aplicaciones que se construyen con versiones anteriores del .NET Framework. Para ejecutar aplicaciones antiguas con .NET Framework 4, debe compilar su aplicación con el objetivo .NET Framework versión especificado en las propiedades de su proyecto en Visual Studio, o se puede especificar el tiempo de ejecución apoyado con el elemento en una aplicación archivo de configuración.
Bueno, no debería tener ningún problema de rendimiento. Sin embargo, una gran diferencia es que .Net 4.0 viene con un tiempo de ejecución diferente que puede introducir algunas diferencias.
Se cuestiona si habrá problemas de rendimiento generalmente no se pueden responder ya que depende de lo que está haciendo su código. Lo más probable es que no vea ningún problema.
Aunque Microsoft hizo mucho para permanecer compatible hacia atrás con la versión anterior del tiempo de ejecución, debe tener en cuenta que hay varios cambios de rotura. Los encontrará documentados en MSDN aquí:
.NET Framework 4 Migration Issues (incluyendo documentación sobre ASP.NET, .NET Core, datos/ADO.NET, WCF, WPF y XML)
Microsoft también proporciona orientación y enlaces a más tareas de planificación de la migración:
Como usted debe estar preparado para cualquier problema, no se olvide de programar un tiempo para pruebas adicionales.
.NET 3.5 Las DLL se cargan en un dominio de aplicación separado de .NET 4. Por lo tanto, todas las llamadas a .NET 3.5 DLL de .NET 4 se realizarán en el dominio de la aplicación. Eso significa bastante sobrecarga. A menos que pueda reconstruir el código fuente 3.5 en .net 4, no recomendaría su uso. Uno de mi equipo lo intentó y luego vieron un rendimiento bastante malo, así que volvieron a .NET 3.5. Hasta que obtengamos el código fuente para todas las DLL .net 3.5 o los proveedores liberen .net 4 DLLs, no vamos a actualizar nuestra base de código a la red 4.
¿Tiene alguna referencia para esto? –
Basado en mi experiencia hasta ahora, esperaba que Omar estuviera en lo cierto, pero después de iniciar Process Exprlorer y echar un vistazo, solo veo dos AppDomains cargados "SharedDomain" y "DefaultDomain" y no veo ninguna evidencia de que solo el 3.5 los ensamblajes se están cargando en uno de los dominios. En su lugar, todos los ensamblajes que no sean mscorlib se cargan en el DefaultDomain. Más detalles aquí http://msdn.microsoft.com/en-us/magazine/cc163791.aspx#S4 – jpierson
Planifique sus propias pruebas de perforación. Para obtener orientación, consulte this de los patrones & prácticas.
No sé qué bloques está utilizando, pero debería considerar migrar a EntLib v5.0, ya que hubo mejoras de rendimiento importantes en el bloque de aplicaciones de registro, así como una refactorización/limpieza de la infraestructura subyacente. Consulte el Migration Guide for Enterprise Library 5.0.
-1: "así que no debería haber ningún problema. El código de todos ustedes 3.5 funcionará como lo hizo cuando se creó con VS 2008": la lista de cambios de interrupción es realmente larga, consulte aquí un punto de entrada a los diversos. Tecnologías NET: [.NET4 Lista completa de cambios de última hora] (http://muneebbaig.blogspot.com/2010/04/net4-complete-list-of-breaking-changes.html). En general, cualquier cambio en un producto, incluido el cambio del entorno de tiempo de ejecución .NET, debe ir acompañado de pesadas pruebas. –