Tiempo de ejecución soportado v4.0 en app.config después de actualizar VS11 Beta a VS2012 RC

Question

Después de actualizar de VS11 Beta a VS2012 RC - He modificado la orientación de .NET 4.0 a .NET 4.5. Lo noté en la aplicación siguiente sección

<startup> 
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> 
</startup> 

¿Para qué sirve lo anterior?

Cuando traté de crear un nuevo proyecto (no actualización del proyecto existente) desde dentro VS2012 RC no veo la sección anterior en app.config

Answer 1

Eso es un efecto secundario del control de versiones .NET eterna cenagal. .NET 4.5 no es una versión paralela de .NET Framework, reemplaza completamente una instalación de .NET 4.0. Al igual que 3.0 y 3.5 reemplazaron una instalación de .NET 2.0.

Las actualizaciones 3.0 y 3.5 fueron bastante suaves, el marco acaba de adquirir un conjunto de ensamblajes nuevos. Los conjuntos CLR y la clase base básica no cambiaron. Mucho.

El archivo clr.dll incluido con la versión 4.5 del framework todavía tiene el número de versión 4.0.30319. El mismo número de versión de la versión 4.0 del CLR. Y no tiene problemas para ejecutar aplicaciones .NET que se dirigen al framework .NET 4.0.

Sin embargo, esa versión de framework fue muy modificada internamente. Adquirió la proyección de lenguaje que permite escribir aplicaciones Metro que se ejecutan en Windows 8 en un lenguaje administrado. Los cambios pesados ​​incluyen mover clases de un ensamblaje a otro, lo que permite que la implementación en un teléfono o pizarra sea modesta. El archivo app.exe.config agregado a su proyecto asegura que su usuario tenga esa versión requerida. La implementación del archivo .config es opcional, pero el usuario verá un mensaje de excepción bastante opaco cuando solo tiene instalado .NET 4.0. No estoy seguro de cómo se ve eso. La instalación automática que se desencadena cuando no tiene 4.5 probablemente tampoco funcione.

Answer 2

Mientras que Hans Passant tiene razón en todo lo que dice, echa de menos un punto clave que es el papel del encabezado PE en esta debacle.

Dado que Dotnet 4.5 es una instalación in situ sobre la parte superior de Dotnet 4.0, y porque no actualiza el número de versión Dotnet, el resultado es que los binarios construidos con Dotnet 4.5 tienen el antiguo número de versión Dotnet 4.0 en su encabezado PE del binario (4.0.30319).

Porque CLR usa este valor en el encabezado PE para determinar qué versión de Dotnet Framework cargar y porque este valor no cambia para los ensamblados construidos contra Dotnet 4.5, entonces, en ausencia de información adicional, el CLR no tiene forma de saber si un ensamblado con 4.0.30319 en el encabezado PE requiere un enlace a Dotnet 4.0 o 4.5.

Es la presencia del elemento supportedRuntime en app.config que proporciona esta información adicional al CLR. Por lo tanto, si inicia una aplicación Dotnet 4.5 con la entrada supportedRuntime presente en un sistema que solo tiene Dotnet 4.0 instalado, entonces el CLR mostrará un mensaje útil que le informará que no tiene instalada la versión requerida de Dotnet. Mientras que si inicia la misma aplicación Dotnet 4.5 sin la entrada supportedRuntime en un sistema que solo tiene Dotnet 4.0 instalado, entonces la aplicación puede comenzar a ejecutarse, pero luego se bloquea cuando más tarde trata de usar una función Dotnet 4.5.

Si bien los proyectos creados con VS2012 RC y la orientación a Dotnet 4.5 pueden haber perdido la entrada supportedRuntime, los proyectos creados con VS2012 RTM tienen la entrada.