26 votos

¿Puedo utilizar una biblioteca de net 4.0 en una aplicación. net 2.0?

Me estoy quedando en algunos problemas con mi .NET 4.0 bibliotecas .NET 2.0 aplicaciones. Supongo que yo estaba bajo la impresión de que ser un archivo DLL de Windows, mis otras .NET apps sería capaz de acceder a él. No es éste el caso? Las recomendaciones en términos de aplicaciones de apoyo en ambos entornos?

EDIT: me doy cuenta de que me había necesidad de instalar .NET 4.0 Framework en el sistema de destino, hay otras razones por las que esto no/no funciona?

EDIT: Probablemente debería haber sido más específico. Tenemos una actual, grandes o complejos, aplicación escrita en .NET 2.0 (ASP.NET ser exactos). Tenemos un nuevo conjunto de herramientas de integración y elementos del flujo de trabajo que estamos escribiendo .NET 4.0. Hemos querido añadir uno de los 4.0 creado bibliotecas para el .NET 2.0 proyecto (actualmente en VS2008) y hacer uso de algunos de sus métodos. Cuando hacemos esto, nos topamos con problemas, a menudo crípticos errores relacionados con la memoria.

Parecería que tanto Earwicker y Brian Rasmussen son correctos en la final. Como no estoy demasiado interesado en exponer las cosas a través de COM (no estoy seguro 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 busca a otros medios, que creo que nos hemos basado en nuestras necesidades específicas. A más largo plazo vamos a ver a mover la .NET 2.0 código de hasta 4.0.

18voto

Daniel Earwicker Puntos 63298

Sí, esto es perfectamente posible. Usted acaba de exponer los componentes escritos en 4.0 como objetos COM. El 2.0 de alojamiento de aplicaciones sólo los utiliza 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 ejecución tiene que implementar de forma idéntica.

El nuevo proceso de SxS apoyo en 4.0 significa que cuando el 4.0 objeto COM se carga, se tira en el tiempo de ejecución en lugar de tratar de ejecutar en el 2.0, por lo tanto los tiempos de ejecución están presentes en el proceso de la gestión de sus propios objetos. Aunque no se puede pasar directamente objetos CLR entre ellos, usted puede pasar interfaces COM, y el CLR de forma transparente envuelve a los objetos de interfaces COM.

No sé si se puede hacer un único ensamblado de interoperabilidad para ambas versiones. Pero es evidente que usted podría escribir un ensamblado de interoperabilidad en C# en el 2.0, se exporta al .tlb y, a continuación, importarlo en una asamblea en la versión 4.0. Que le da la coincidencia de dos de los ensamblados de interoperabilidad describir idénticos interfaces COM. (O simplemente construir el mismo código fuente de C# en cada versión del proyecto de ensamblado).

Bono de Actualización: Será la resultante de la aplicación de COM-basado (con lo que los problemas que conlleva)?

Depende de cómo se mire. Los autores de los componentes van a hacer como componentes COM. Por lo que la aplicación host necesita para localizar y cargar como componentes COM. Esto significa que a trastear con el GAC, el registro o SxS manifiesta, que es mucho menos limpio que simplemente decirle a la componente de los autores a la caída de su montaje en un determinado directorio, de modo que usted puede cargar con la reflexión.

Y esto tiene un impacto en el tiempo de ejecución: cuando el host tiene una referencia a un componente, habrá no uno, sino tres los objetos involucrados. El host tiene una referencia a un RCW, que tiene un puntero a una interfaz COM implementado por una convención, que a su vez contiene una referencia a la componente real. La CCAC en el medio hay una referencia contada objeto COM, y el anfitrión de la RCW tiene un finalizador que llama a Release en la convención, y cuando es destruido se cancela la asignación de la GCRoot que es mantener vivo el componente real.

Esto significa que - con una suficientemente complicada disposición de devolución de llamada de los punteros, etc. - el sistema puede terminar con la circular problemas de recuento de referencia, donde desconectado "isla" de los objetos de todas las referencias de unos a otros y así nunca se cancela la asignación.

10voto

Brian Rasmussen Puntos 68853

Tenga en cuenta que la versión 4.0 es asambleas más sólo adicionales. El propio runtime también ha cambiado en esta versión (nuevo modo GC concurrente, un montón de cambios en el grupo de subprocesos, mscorwks.dll ahora se llama clr.dll, etc..).

8voto

arik Puntos 322

He acaba de publicar un post básicamente lo que sugiere Daniel.

Cómo hacer un net 4 basado en DLL desde una aplicación. net 2 basado en

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

2voto

Pratik Puntos 5401

Puede ser posible dependiendo de cómo usted lo está utilizando. En .Net 4.0 usted tiene la opción de Proceso al Lado de Ejecución (InProc SxS). Esto le permite alojar a dos versiones diferentes de CLR en el mismo espacio de proceso. Esto se explica aquí.

Si usted puede tomar ventaja de esto en su situtaion no sé. Yo no tengo experiencia directa para ayudar a usted.

Algunos de los escenarios en los que este puede ser utilizado.

1voto

Phil Rykoff Puntos 6650

no creo que esto es posible. Tal vez un MSIL a nativo convertidor/compilador ayudaría, pero no tengo ninguna experiencia con éstos.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by: