¿Cómo agregar .Net3.5 dll en el proyecto .Net2.0?

Question

Tengo un dll que se basa en .net 3.5 - usa internamente, por ejemplo, Linq, pero la API expuesta es sencilla, no tiene nada de lujoso. Como los genéricos de C# se resuelven en el momento de la compilación, supongo que para la parte llamante todo lo que cuenta es API (todas las partes públicas).

Sin embargo, cuando trato de utilizar este archivo dll del proyecto net2.0 obtengo información, que no se puede hacer referencia al dll porque el archivo DLL o una de sus dependencias requiere una versión posterior de .NET Framework.

Puedo instalar cualquier versión de .net que desee en la computadora de destino (cuando se instala toda la aplicación), pero no puedo cambiar la versión de .net para el proyecto en sí.

Entonces: cómo solucionar esto? Al agregar un dll de C a este proyecto, no tuve esos problemas, ¿son C o dlls autónomos o no?

Answer 1

C# dlls deben tener el tiempo de ejecución .Net para ejecutarse, ya que no se compilan hasta el código de máquina. En este caso, la dll dice que requiere Net 3.5, por lo que todo su proyecto deberá usar 3.5 o superior.

Para mantener su proyecto como Net 2.0 necesitaría construir otro ejecutable para contener la DLL 3.5 y comunicarse en procesos separados.

La DLL de C funcionó, ya que está compilada en código nativo y no requiere .Net Framework. (O al menos no la versión superior a 2,0)

Answer 2

Si está utilizando LINQ a objetos, entonces usted puede utilizar LINQ Puente: http://www.albahari.com/nutshell/linqbridge.aspx

se trata de una aplicación de LINQ a objetos para .NET 2.0.

Aún tendrá que compilar utilizando vs2008, pero puede compilar con .NET 2.0 como plataforma de destino en ese caso. (Esto es debido a que el compilador de C# 3 entiende cláusulas LINQ incluso si la orientación .NET 2.0, simplemente resolver las llamadas a linqbridge en lugar de las bibliotecas .NET 3.5 en este caso)

Answer 3

C# DLL no son autónomos . Si su DLL 3.5 necesita LINQ, depende de los ensamblados del sistema desde el marco 3.5 (3.0 para ser exactos), por lo tanto, toda la aplicación depende de esta versión.

Puede cargar el ensamblaje 3.5 dinámicamente y usar el reflejo para obtener acceso a las funciones que necesita. Esto requiere un poco de sobrecarga, por supuesto.

Answer 4

He estado usando System.Core y los nuevos System.Web.Extensions (por ejemplo) a partir de 3,5 en un 2,0 aplicación ASP.NET (usando VS2005) por un tiempo sin problemas. Similar a lo que Scott Hanselman escribió en su blog sobre here. Entonces sí, es posible.

.NET 3.5 aún se ejecuta en el mismo CLR que .NET 2.0. Entonces en tiempo de ejecución es todo lo mismo. (Suponiendo que ha rastreado las dependencias y ha copiado esas DLL 3.5 a la carpeta bin también).

La única limitación real es qué características de lenguaje C# puede usar en el momento del desarrollo. Tales como 'var', métodos de extensión o sintaxis de consulta LINQ.

Answer 5

Si está utilizando bibliotecas .NET 3.5, entonces los requisitos de su aplicación deberían ser tales que cualquier consumidor de su API también debería estar usando .NET 3.5.

La única manera de evitar esto es si se empaqueta todos las dependencias de su aplicación junto con él. Esto significa que las bibliotecas que utiliza su aplicación que dependen de .NET 3.0 y 3,5 marcos.

Sin embargo, no estoy seguro de la legalidad de arrancar trozos de los marcos .NET y envasarlos con una aplicación. Leí el EULA antes de hacer algo como esto. OMI, no vale la pena la molestia; solo instale 3.5, solicite a los usuarios que instalen 3.5 y terminen con él o solo utilicen características 2.0 y bibliotecas. Por lo menos, piratear de esta forma solo le causará más dolor con la implementación si hay actualizaciones de infraestructura en el futuro.

En cualquier caso, su aplicación funcionará en .NET 2.0 ya que 3.0 y 3.5 son solo bibliotecas extra sobre el tiempo de ejecución 2.0 y bibliotecas (como mencionó Craig) mientras que todas sus dependencias estén allí.

Answer 6

Nada bastante

pero hay maneras de conseguir el código felices trabajando juntos (en el orden de preferencia):

1) actualizar tanto proyectos a 3,5

Si he entendido bien, entonces su. net FW 2.0 Program tendrá dependencia en 3.5 Library, lo que significa que para que funcione cada funcionalidad del programa, ahora requiere FW 3.5. Como usted declara tener el código y la autoridad para recompilar el Programa e instalar cualquier FW en la implementación, puede actualizarlo a 3.5. Suena simple, pero como no hiciste esto, creo que tienes buenas razones (como que otros programas están más arriba en la cadena de llamadas que no puedes actualizar a 3.5/recompilar).

2) Da la vuelta al FW2. 0 compilador

Cree el programa al hacer referencia a la versión 2.0 de la biblioteca (o dummy, simplemente proporcionando la API pública). Cree la versión 3.5 de la Biblioteca por separado sin Programa (eliminando así la necesidad de hacer referencia al ensamblado FW incorrecto) y despliegue la versión 3.5 en lugar de la versión 2.0. Dado que 2.0 y 3.5 usan el mismo tiempo de ejecución de CLR, basta con engañar al compilador. Siempre que la implementación maching tenga FW 3.5 instalado, todo debería estar bien. Nota: todo está bien incluso si solo tiene .net 2.0 presente en la máquina de despliegue y el usuario no llama a las clases .net 3.5. Si lo hace, habrá choque;)

3) Downgrade Biblioteca a 2,0

si se utiliza sólo algunas clases del .NET FW entonces usted podría permanecer con el compilador 2,0 mediante la adición de los futuros que falta asambleas para proyectar. (esta es la solución del enlace de Hanselman compartida por Craig). Como ya se mencionó, perderá 3.5 azúcar sintáctico del compilador como vars.

elegir el que más se adapte mejor a su situación.