¿Puedo usar una biblioteca .NET 4.0 en una aplicación .NET 2.0?

Question

Tengo algunos problemas al utilizar mis bibliotecas .NET 4.0 en aplicaciones .NET 2.0. Supongo que tenía la impresión de que al ser una DLL de Windows, mis otras aplicaciones .NET podrían acceder a ella. ¿No es este el caso? ¿Alguna recomendación en términos de aplicaciones de soporte en ambos entornos?

EDIT: Me doy cuenta de que tendría que instalar el .NET Framework 4.0 en el sistema de destino, ¿hay otras razones por las que esto no funcionará?

EDIT: Probablemente debería haber sido más específico. Tenemos una aplicación actual, grande/compleja, escrita en .NET 2.0 (ASP.NET sea exacto). Tenemos un nuevo conjunto de herramientas de integración y elementos de flujo de trabajo que estamos escribiendo en .NET 4.0. Queríamos agregar una de las 4.0 bibliotecas creadas al proyecto .NET 2.0 (actualmente en VS2008) y hacer uso de algunos de sus métodos. Cuando hacemos esto, tenemos problemas, a menudo errores crípticos relacionados con la memoria.

Parece que tanto Earwicker como Brian Rasmussen están en lo cierto al final. Como no estoy muy interesado en exponer cosas a través de COM (no estoy seguro de si esto es técnicamente COM o no, pero independientemente), creo que voy a seguir con la idea de que los dos no son "compatibles" y buscar otros medios, que creo tenemos basándonos en nuestras necesidades específicas. A más largo plazo buscaremos mover el código .NET 2.0 hasta 4.0.

Answer 1

Sí, esto es perfectamente posible. Simplemente expone los componentes escritos en 4.0 como objetos COM. La aplicación de alojamiento 2.0 solo los usa como objetos COM y no tiene idea de si son nativos, 2.0, 4.0 o lo que sea. COM es la interfaz común que ambas versiones de tiempo de ejecución deben implementar de forma idéntica.

El nuevo soporte SxS en proceso en 4.0 significa que cuando se carga el objeto COM basado en 4.0, obtiene el tiempo de ejecución requerido en lugar de intentar ejecutarse en el 2.0, por lo que ambos tiempos de ejecución están presentes en el proceso de gestión de su objetos propios Aunque no puede pasar directamente objetos CLR entre ellos, puede pasar interfaces COM, y CLR envuelve sus objetos de forma transparente en las interfaces COM por usted.

No sé si puede hacer un único conjunto de interoperabilidad para que funcionen ambas versiones. Pero claramente podría escribir un ensamblado de interoperabilidad en C# en 2.0, exportarlo a .tlb y luego importarlo a un ensamblado en 4.0.Eso le da dos conjuntos de interoperabilidad que coinciden que describen interfaces COM idénticas. (O simplemente crea la misma fuente de C# en el proyecto de ensamblaje de cada versión).

Actualización de bonificación: ¿La aplicación resultante estará basada en COM (con cualquier problema que implique)?

Depende de cómo lo mires. Los autores de los componentes los convertirán en componentes COM. Entonces, la aplicación host necesita ubicarlos y cargarlos como componentes COM. Esto significa perder el GAC, el registro o los manifiestos de SxS, que es mucho menos limpio que solo decirle a los autores de los componentes que dejen caer su ensamblaje en un directorio determinado para que pueda cargarlo con reflexión.

Y tiene un impacto en el tiempo de ejecución: cuando el host tiene una referencia a un componente, no habrá uno sino tres objetos involucrados. El host tiene una referencia a un RCW, que tiene un puntero a una interfaz COM implementada por un CCW, que a su vez contiene una referencia al componente real. El CCW en el medio es un objeto COM contado por referencia, y el RCW del host tiene un finalizador que llama al Release en el CCW, y cuando se destruye, desasigna el GCRoot que mantiene vivo el componente real.

Esto significa que, con una disposición suficientemente complicada de punteros de devolución de llamada, etc., el sistema puede terminar con problemas circulares de conteo de referencias, donde una "isla" desconectada de objetos tiene referencias entre ellos y nunca desasignarse

Answer 2

Tenga en cuenta que la versión 4.0 es algo más que ensamblajes adicionales. El tiempo de ejecución en sí mismo también se ha modificado en esta versión (nuevo modo GC concurrente, muchos cambios en el grupo de subprocesos, mscorwks.dll ahora se llama clr.dll, etc.).

Answer 3

Su ensamblado compilado para .NET 4 contendrá referencias a otras bibliotecas de marcos .NET 4 que no están presentes en .NET 2.0.

Si desea que sus aplicaciones sean compatibles con .NET 2.0, puede utilizar Visual Studio 2005 o target sus proyectos en .NET 2.0 si está utilizando Visual Studio 2008 o 2010. Por supuesto, si destina sus proyectos a. NET 2.0 no podrá aprovechar las características .NET 3.5/4.

Answer 4

Puede ser posible dependiendo de cómo lo esté usando. En .Net 4.0 tiene la opción de En proceso de ejecución paralela (InProc SxS). Esto le permite alojar dos versiones diferentes de CLR en el mismo espacio de proceso. Esto es explained here.

Si puede aprovechar esto en su situtaion no lo sé. No tengo experiencia directa para ayudarte.

Algunos scenarios en que esto se puede utilizar.

Answer 5

Parece que la característica en proceso paralela que se agregó a CLR 4 no ayudaría en este caso ya que quiere usar una biblioteca .NET4.0 en una aplicación .NET2.0. Por lo que yo entiendo, SxS en proceso sería útil si el caso fuera el opuesto (consumir un .NET2.0 en una aplicación .NEt4.0) ya que el CLR de 4.0 funcionará junto con 2.0 en el mismo proceso ..

Answer 6

Acabo de publicar una publicación, básicamente, lo que Daniel sugirió.

How to use a .NET 4 based DLL from a .NET 2 based application

código fuente y la descripción en: http://code.msdn.microsoft.com/Using-a-NET-4-Based-DLL-bb141db3

Answer 7

tuve un problema similar con mi aplicación en la que yo no era capaz de hacer referencia a una API, que estaba utilizando .NET 4.0 componentes.
Para resolver esto, creé un nuevo proyecto de biblioteca de clases que hacía referencia a mi proyecto .net 4.0 y luego llamé a ese nuevo ensamblado desde mi proyecto .net 2.0. Cartografié los datos procedentes del proyecto .net 4.0 que utilizará mi proyecto .net 2.0.
Eso resolvió mi problema.