dll - ¿Puedo usar una biblioteca.NET 4.0 en una aplicación.NET 2.0?
.net-2.0 .net-4.0 (7)
Acabo de publicar una publicación, básicamente, lo que Daniel sugirió.
Cómo usar una DLL basada en .NET 4 desde una aplicación basada en .NET 2
Código fuente y descripción en: http://code.msdn.microsoft.com/Using-a-NET-4-Based-DLL-bb141db3
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?
EDITAR : me doy cuenta de que necesitaría instalar .NET 4.0 Framework en el sistema de destino, ¿hay otras razones por las que esto no funcionará?
EDITAR : 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.
Parece que la característica en proceso lado a lado 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 ...
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 se explica aquí .
Si puede aprovechar esto en su situtaion, no lo sé. No tengo experiencia directa para ayudarte.
Algunos scenarios en los que esto puede ser utilizado.
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 administración de sus propios objetos. 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 ensamblado de interoperabilidad para que ambas versiones funcionen. 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 a 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 mantiene referencias entre sí y nunca se desasignan.
Su ensamblado compilado para .NET 4 contendrá referencias a otras bibliotecas .NET 4 framework 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 a .NET 2.0 si está utilizando Visual Studio 2008 o 2010. Por supuesto, si orienta sus proyectos a .NET 2.0, lo hará no ser capaz de aprovechar las características de .NET 3.5 / 4.
Tenga en cuenta que la versión 4.0 es más que solo 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.).
Tuve un problema similar con mi aplicación en el que no pude hacer referencia a una API que usaba componentes .net 4.0.
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. Mapeé los datos que regresaban del proyecto .net 4.0 para ser utilizado por mi proyecto .net 2.0.
Eso resolvió mi problema.