No se puede usar el control Winforms debido a dependencias no resueltas

Question

Problema: Tengo un control WinForms ('MyControl') con una dependencia en myCli.dll, una dll escrita en C++ CLI. Este componente es de terceros (escrito por otro equipo). myCli.dll tiene una dependencia en myLibrary.dll escrita por otra parte. El control reside en myAssembly.dll, que es una biblioteca de controles y recursos de C#.

Tenía este control funcionando muy bien cuando myCli.dll no tenía una dependencia en myLibrary.dll. Podría agregarlo a formularios, compilarlo, etc. Pero apareció la nueva versión de myCli.dll y volví a vincularla. De repente, el IDE se está portando mal. El problema clave parece ser que el IDE no puede resolver la dependencia myCli.dll en myLibrary.dll.

Cuando intento arrastre el control de la caja de herramientas a una superficie de diseño, me sale el error:

"Failed to create component 'MyControl'. 

El mensaje de error siguiente:

'System.IO.FileNotFoundException: Could not load file or assembly 'myCli.dll, Version 0.0.0.0, Culture=neutral, PublicKeyToken=2fb8da784abc560a' or one of its dependencies. 
The system cannot find the file specified" 

Mi creencia es que si puedo averiguar dónde poner myLibrary.dll, resolveré el problema de referencia. No lo sé con certeza. ¿Alguien sabe lo que debo hacer para resolver el problema?

Answer 1

Creo que el archivo DLL debe ir al directorio del proyecto, luego configurarlo para que se copie al directorio de salida en la compilación.

Answer 2

Para el soporte de diseño, creo que el myLibrary.dll o bien debe entrar en C:\Program Files\Visual Studio xxx\Common7\IDE\PublicAssemblies (suponiendo que myCLI.dll también vive allí), o al lugar donde myCLI.dll existe o es posible que trate de copiarlo en C:\Windows\System32 - el sistema debe ser capaz de encontrarlo entonces.

Asegúrese de agregarlo también al proyecto y configurarlo en "Copiar siempre" como lo sugiere Clippit '98.

Answer 3

Otra forma de encontrar el lugar adecuado sería tal vez el uso de Process Monitor. Simplemente filtra la salida de tu dll y comprueba en qué rutas busca el archivo.

Answer 4

myCli.dll y todas sus dependencias deben estar en la misma carpeta, de lo contrario VS no podrá encontrarlas.

La manera más fácil de hacerlo es asegurarse de que cuando crea myCli.dll, copia todos los archivos en las carpetas Depurar/Liberar y luego solo hace referencia a esos controles en su proyecto desde las carpetas Depurar/Liberar directamente.

Answer 5

En mi caso, mi código en Initialize y Form_Load contenía llamadas a otro proyecto según las referencias de DLL. Al excluir este código con

if (!DesignMode) 
{ 
    //add your initializing code (for runtime!) here 
} 

Pude agregar el control en el tiempo de diseño.

HTH

Answer 6

Sé que este es un viejo hilo, pero sólo campanadas con lo que se utiliza para fijar mi problema exacto.

Inicialmente utilicé la solución de Peter Rakké a partir de esta pregunta (https://stackoverflow.com/a/15077337/34440). Pero no fue el ideal ya que forzó un cambio en mis patrones habituales.

Desde mi C++/CLI sólo se utilizan las funciones de la DLL nativa en tiempo de ejecución y el contenido es información de la interfaz propia, acabo de cambiar los archivos DLL nativos para ser cargado retraso. He añadido los dos archivos DLL nativos bajo la configuración del proyecto en Visual Studio (Propiedades del proyecto -> Propiedades de configuración -> Enlazador -> Entrada -> Delay Cargado DLL). Asegúrese de ajustar la configuración y menús desplegables de la plataforma en la parte superior del cuadro de diálogo de propiedades para ser los Todas las opciones y hacer una reconstrucción completa.

pude después hacer referencia a los tipos de la C++/CLI DLL en mis controles anidados y formas.

Answer 7

La misma situación que medicineman. Proyecto WinForms utilizando 2 componentes diferentes en libraryA.dll, que a su vez tenía una dependencia en libraryB.dll.

solución que funcionó para mí (solo referencia DLL aplicables en todos los proyectos, incluso cuando todas las bibliotecas se construyen en modo de depuración, y sin necesidad de copiar manualmente archivos DLL a diferentes carpetas):

1. Para los componentes en libraryA. DLL que dibujar eventos de anulación, si está en modo de salida designtime:

   If Me.DesignMode Then Exit Sub 
   

2. para los componentes en libraryA.dll con propiedades públicas utilizando tipos de libraryB.dll, el uso de atributos para ocultar estas propiedades del diseñador (comprobar la sintaxis con cuidado - He visto varios otros mensajes que tienen algunas variaciones ortográficas/extraños):

   <DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> 
   

3. componentes reconstruir, a continuación, volver a iniciar Visual Studio antes de usar en el proyecto de Windows Forms. Por algún motivo, los cambios en los Atributos no se detectan durante la misma sesión y los quemo durante un par de horas antes de intentar lo obvio.

Si todavía tiene problemas, hay un excelente post en conseguir información de depuración durante el componente de unión (es decir, cuando se arrastra y soltar componente en forma): How to enable assembly bind failure logging (Fusion) in .NET (desplácese hacia abajo para responder por Mike Goatly) .

Buena suerte.