c# - tengo - net framework todas las versiones

Al ejecutar una aplicación en.net 4.0, compilada bajo.net 2.0

Question

Asumiendo que:

1. El código fuente de C # a continuación se compila bajo .NET 2.0 (CLR 2.0); y
2. La aplicación anterior utiliza el app.config listado a continuación; y
3. Solo .NET 4.0 (CLR 4.0) está instalado en el entorno del cliente que ejecuta la aplicación,

entonces, ¿qué versión de .NET se carga internamente para ejecutar la aplicación en el entorno del cliente?

Descripción

La siguiente aplicación de la consola simplemente mostrará que su versión de CLR es v4.0.30319 en la consola, pero la respuesta de @Reed Copsey de la pila ( ¿rendimiento de CLR 2.0 vs 4.0? ) Muestra que, en este caso, se carga .NET 2.0. Además, en MSDN dice que cuando useLegacyV2RuntimeActivationPolicy se establece en falso false :

Use la política de activación predeterminada para .NET Framework 4 y versiones posteriores, que es para permitir que las técnicas de activación de tiempo de ejecución heredadas carguen la versión 1.1 o 2.0 de CLR en el proceso.

Parece que .NET 2.0 se carga a pesar de que app.config tiene una configuración .NET 4.0. ¿He entendido mal algo?

Fuente

Código fuente C #

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
string version = Environment.Version.ToString();
Console.WriteLine(version);
}
}
}

app.config

<?xml version="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="false">
<supportedRuntime version="v4.0.30319"/>
</startup>
</configuration>

Answer 1

La conclusión es que en su escenario, especificó .Net 4 como su único tiempo de ejecución compatible, por lo que su aplicación se cargará con CLR 4.

El comportamiento de CLR con su programa es exactamente como está diseñado:

Cuando ejecuto su aplicación de prueba con el tiempo de ejecución supportedRuntime como v4.0, Process Explorer muestra que carga mscorlib v4.0.30319.

Cuando corro con el tiempo de ejecución refirmado como v2.0.50727, Process Explorer muestra que carga mscorlilb v2.0.50727.

Cuando corro sin un elemento refinado en tiempo de ejecución, Process Explorer muestra que carga mscorlilb v2.0.50727.

Esta publicidad de Microsoft indica que el elemento supportedRuntime define la versión específica en la que se ejecuta su programa:

De forma predeterminada, una aplicación se ejecuta en la versión de .NET Framework para la que fue creada. Si esa versión no está presente y el archivo de configuración de la aplicación no define las versiones compatibles, puede ocurrir un error de inicialización de .NET Framework. En este caso, el intento de ejecutar la aplicación fallará.

Para definir las versiones específicas en las que se ejecuta su aplicación, agregue uno o más elementos al archivo de configuración de su aplicación. Cada elemento enumera una versión compatible del tiempo de ejecución, con la primera que especifica la versión más preferida y la última que especifica la versión menos preferida.

Hay dos elementos separados en juego, aquí. Solo el elemento supportedRuntime se aplica a su escenario.

El elemento supportedRuntime define las versiones de CLR en las que se ejecutará su aplicación, en el orden preferido. Si enumera los tiempos de ejecución admitidos, entonces se usarán esas versiones de CLR, bajando de la lista de arriba a abajo hasta que se encuentre una versión de CLR instalada. Si no incluye los tiempos de ejecución de soporte, su programa se ejecutará con la versión del CLR con el que se compiló.

El elemento useLegacyV2RuntimeActivationPolicy se aplica solo a ensamblajes de modo mixto --- programas o DLL que contienen código administrado (.Net) y no administrado (nativo). Su programa de muestra no es un ensamblaje de modo mixto. Para ensamblajes de modo mixto, establecer el valor en false (predeterminado), o no configurarlo todo, usa la nueva carga lado a lado en proceso de .Net 4 para ensamblajes de modo mixto, por lo que su aplicación puede ejecutarse con CLR 4, y cargue un ensamblaje de modo mixto en el mismo proceso usando CLR 1.0-2.0. Establecerlo como true esencialmente vuelve a la funcionalidad anterior antes de .Net 4, donde la funcionalidad lado a lado en proceso está deshabilitada, y cualquier versión de CLR seleccionada para ejecutar la aplicación intentará cargar su ensamblaje en modo mixto. La versión de CLR utilizada para cargar el ensamblaje en modo mixto será la que se seleccione para ejecutar la aplicación, según la versión que se usó para compilar la aplicación, y sus tiempos de ejecución admitidos, si corresponde.

Hay un artículo de MSDN Magazine y un artículo de MSDN sobre la carga de .Net 4 y la ejecución en proceso lado a lado (In-Proc SxS) para componentes COM, que también tiene un impacto en su escenario sin componentes COM. Antes de .Net 4, si compilaba su aplicación con una versión de CLR, y esa versión no estaba disponible en el sistema en tiempo de ejecución, la aplicación se ejecutaría automáticamente en una versión más nueva de CLR si se instalaba. A partir de .Net 4, las aplicaciones ahora no se ejecutarán con una versión más nueva del CLR a menos que especifique la versión más nueva en el elemento supportedRuntimes .

Aquí hay una cita del artículo de MSDN:

Desarrolladores de aplicaciones. El alojamiento de lado a lado casi no tiene efecto en los desarrolladores de aplicaciones. De forma predeterminada, las aplicaciones siempre se ejecutan contra la versión de .NET Framework en la que se crearon; Esto no ha cambiado. Sin embargo, los desarrolladores pueden anular este comportamiento y hacer que la aplicación se ejecute bajo una versión más reciente de .NET Framework (ver escenario 2).

Desarrolladores y consumidores de bibliotecas. El alojamiento de lado a lado no resuelve los problemas de compatibilidad que enfrentan los desarrolladores de bibliotecas. Una biblioteca que se carga directamente con una aplicación, ya sea a través de una referencia directa o mediante una llamada de Assembly.Load, continúa utilizando el tiempo de ejecución del dominio de aplicación en el que se carga. Debe probar sus bibliotecas con todas las versiones de .NET Framework que desee admitir. Si una aplicación se compila con el tiempo de ejecución de .NET Framework 4 pero incluye una biblioteca que se creó con un tiempo de ejecución anterior, esa biblioteca también usará el tiempo de ejecución de .NET Framework 4. Sin embargo, si tiene una aplicación que se creó con un tiempo de ejecución anterior y una biblioteca que se creó con .NET Framework 4, debe obligar a su aplicación a usar también .NET Framework 4 (ver escenario 3).

Finalmente, si está en Vista, Win7, Server 2008, Server 2008 R2, automáticamente tiene instalado CLR 2.0 . Por lo tanto, si eliminara el elemento supportedRuntimes o lo cambiara a v2.0.50727, es posible que aún tenga CLR 2.0 disponible como tiempo de ejecución.