2010-01-18 23 views
6

Estoy usando Visual Studio 2008 para crear una solución con dos proyectos: una aplicación de consola C# y una DLL C++. Quiero que la aplicación llame a una función desde el dll usando P/Invoke. Por lo tanto, estoy tratando de agregar el dll como referencia a la aplicación C#. Pero cuando pruebo el comando Agregar referencia, Visual Studio no me deja hacerlo a menos que establezca la propiedad/clr en el dll (en Propiedades de configuración: General). Ahora, pensé que P/Invoke podría manejar dlls win32 simples. De hecho, si construyo mi dll sin/clr y simplemente lo copio a mano para bin/Debug, entonces la aplicación funciona bien. Entonces, ¿por qué se necesita/clr para agregar el dll como referencia? Y si VS no me deja agregarlo, ¿hay alguna solución (limpia) para que mi aplicación encuentre el dll?¿Agregar una referencia desde una aplicación C# a una DLL compilada sin/clr?

veo que alguien tenía un problema similar aquí (aunque con un DLL tercera parte): Unable to add a DLL Reference to VS 2008 La respuesta que obtuvo fue la de construir un envoltorio. Pero esto no es realmente necesario, ya que la aplicación puede usar el dll muy bien; es solo el paso Agregar referencia que no funciona. Y además, ¿el código del contenedor no necesita una referencia al dll, lo que plantea el mismo problema que antes? Realmente me gustaría una respuesta que no implique escribir un envoltorio en absoluto.

Respuesta

7

¿Por qué no acaba de agregar un paso posterior a la compilación para copiar su DLL no administrada a su directorio de proyecto? No necesita una "referencia" para poder referirse a una DLL no administrada, y parece que el único problema que está experimentando se debe a que el archivo no se copia automáticamente en la ruta de búsqueda.

+0

me escribió una etapa de pre-construcción para la aplicación de C# utilizando esta línea de comandos: copia "$ (SolutionDir) Depurar \ MathDll.dll" "$ (TargetDir)". Desgraciadamente, me gustaría que la funcionalidad "Agregar referencia" funcionara, porque ahora tengo que mantener esto, y supongo que será diferente para las compilaciones de lanzamiento ... Realmente no veo por qué "Añadir referencia" no debería manejar este tipo de cosas. –

+3

Acabo de encontrar una manera un poco más clara de hacer esto. En lugar de utilizar un comando DOS anterior/posterior a la creación, agregué el dll al proyecto C# como un "elemento existente". Luego, bajo sus propiedades, configuro "Copiar en el directorio de salida" a "Copiar si es más nuevo". (Su "Acción de compilación" es "Contenido".) Esto todavía me parece un poco hackish, pero al menos soluciona el problema de depuración frente a versión, y es un poco más fácil de detectar. –

+0

¡Vaya! Me di cuenta de que mi segunda solución no resuelve el problema de depuración frente a versión, porque hice referencia al dll desde la carpeta Debug. Por otro lado, la primera solución podría solucionar este problema cambiando el comando para copiar "$ (SolutionDir) $ (Configuration) \ MathDll.dll" "$ (TargetDir)". –

6

Al utilizar PInvoke en una DLL de C++, no es necesario añadir una referencia. Las referencias solo son necesarias cuando llamas al código administrado en otra DLL. Simplemente ponga la DLL C++ en el mismo directorio y agregue su nombre al atributo DllImport

0

Teóricamente se podría añadir el C++ - DLL como un recurso vinculado a su C# -DLL. Esto haría que .NET copie su C++ - DLL siempre que copie el C# -DLL incluso dentro del GAC. Teóricamente significa que hay algunas desventajas:

  • Se puede instruir al compilador de C# (csc.exe) a través de las opciones de línea de comandos para añadir el recurso vinculado, pero nunca he encontrado una manera de hacerlo a través de .csproj o incluso visual Studio
  • Si el C# -DLL contiene controles WinForms usuario y desea utilizarlo en el diseñador no lo puedo trabajar porque las copias Winforms-designer C# -DLL en una ubicación temporal en el que se carga, pero no tiene en cuenta el recurso vinculado .
  • No sé si funciona si usted pone su C# -DLL en la GAC ​​(sí, el C++ - DLL también entraría en un recurso, pero no sé si se determina cuando se ejecuta su C# - DLL)

Así que si ninguna de las anteriores es un no-go para usted puede llamar a Csc.exe lo siguiente:!

csc.exe ... /linkresource:cpp.dll 

la esperanza que esto puede ayudar!

0

resuelto un problema similar de la siguiente manera:

  1. En todas las máquinas de desarrollo , añade el camino hacia la DLL-s de que se trate a la variable PATH del medio ambiente. De esta forma, todos los desarrolladores podrían depurar todos los ejecutables que tengan una referencia al ensamblado con archivos dll-s no administrados, sin la necesidad de escribir un script de compilación posterior para cada ejecutable.

  2. Para la producción, la tarea msbuild nocturna construye todo en una sola carpeta, y las dll-s no administradas que están marcadas como "Contenido/Siempre copiar" se incluyen automáticamente con la construcción de ese ensamblaje del que forman parte .

Cuestiones relacionadas