Si tengo un ensamblado CLR 2.0 (código administrado puro, sin problemas de modo mixto) al que debo vincular desde una aplicación 4.0 CLR, ¿el código 2.0 se ejecuta en el 2.0 CLR o 4.0?Al vincular un .NET 2.0 Managed Assembly desde una aplicación .NET 4.0, ¿qué marco se utiliza?
Básicamente, ¿hay algún riesgo de que se produzcan 4.0 cambios que afecten el código 2.0?
La respuesta anterior es incorrecta. Obtienes codo con codo con los marcos completos. Una APLICACIÓN .NET 2 (tenga en cuenta que significa EXE, no biblioteca) no se promocionará automáticamente a .NET 4.
Pero si una aplicación .Net 4 carga un ensamblado .Net 2, se carga en el mismo tiempo de ejecución (de lo contrario, podrían compartir información). El ensamblado .Net 2 se carga en el tiempo de ejecución .net 4 utilizando un modo de compatibilidad que se supone que minimiza la rotura en los cambios (principalmente para los cambios de seguridad en .Net 4).
Un ensamblado .Net 2 no puede hacer referencia a un conjunto .Net 4 porque no tendría características.
La única excepción a esto que conozco es si carga un ensamblado .Net desde una aplicación C++. La aplicación C++ puede cargar y alojar dos tiempos de ejecución. Podría tener un ensamblado .Net 2 y un conjunto .Net 4 cargado, pero no podrían comunicarse directamente entre sí. Así es como funcionan los Proc CLR en SQL Server. Puede tener .Net 2 CLR Proc y .Net 4 CLR Proc que no se comunican, pero ambos están cargados en el servidor.
Hubo un excelente artículo en MSDN Magazine sobre el alojamiento de .Net framework recientemente, pero no lo puedo encontrar ahora. Tal vez alguien más puede publicar el enlace.
Así que debería ser capaz de cargar casi cualquier ensamblado .Net 2 en un ejecutable .Net 4 sin mucho problema. Los únicos problemas que he visto son los permisos de seguridad.
Básicamente, ¿hay algún riesgo de que se produzcan 4.0 cambios que afecten el código 2.0?
Nope. Comenzando con .NET 4, no tiene que preocuparse por problemas de compatibilidad en absoluto! La versión 4 introdujo una nueva característica llamada "In-Process Side-by-Side Execution", que básicamente le permite cargar múltiples versiones del CLR en el mismo proceso.
En otras palabras, como su aplicación principal se ejecuta en el tiempo de ejecución 4.0, puede indicarle que cargue el tiempo de ejecución 2.0 cuando cargue el ensamblado 2.0 CLR. El ensamblado 2.0 CLR usará el tiempo de ejecución 2.0, mientras que su aplicación continuará utilizando el tiempo de ejecución 4.0.
¿Cómo se especifica esto? Creo que solo puede agregar un archivo de configuración para su ensamblado CLR 2.0 (por ejemplo, "My.dll.config" en el mismo directorio que "My.dll"), pero no lo he probado con DLL. Sin embargo, esto es lo que pones en el archivo de configuración de su montaje:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
Esto es correcto, de acuerdo con los documentos. Sin embargo, parece que a veces el compilador C# agregará y alias v2.0 ensamblados que luego causan problemas de carga. ¿Puede explicar esto? Aquí hay un ejemplo: http: // stackoverflow.com/questions/3841911/linking-to-a-net-v2-0-assembly-from-a-net-v4-0-assembly-also-appear-to-link-a – codekaizen
Gracias por la respuesta, pero di esto pasa creando un proyecto de prueba rápido. Tengo una aplicación de consola que ejecuta 4.0 y una biblioteca de clase que ejecuta 3.5. He creado un archivo de configuración como se especificó, y Environment.Version es 4.0 para ambos. – AlexWilson
El archivo de configuración no funcionará para una DLL. Debe agregarse al archivo de configuración .EXE, ya que eso es lo que carga el tiempo de ejecución. – codekaizen
si la respuesta de htw no conteste en su lugar, o se estrella en usted. Echar un vistazo a este
Hombre, he hecho esto antes y me olvidé totalmente de esta app.config
No sé si está hablando del artículo "API de alojamiento de CLR": msdn.microsoft.com/en-us/magazine/cc163567.aspx – user276648