Diseñador Rechazar control de usuario

Question

Tengo un "Proyecto de biblioteca de control" de C++ compilado utilizando/CLR. Dentro de este proyecto hay un Control de usuario que realiza una llamada a una DLL nativa. Este control de usuario aparece en la caja de herramientas del diseñador como debería, pero no puedo arrastrarlo a un formulario. Sin la referencia a la DLL, el control del usuario se puede usar bien, pero con la referencia solo recibo el mensaje "No se pudo cargar el elemento de la caja de herramientas" cuando intento usarlo.

La llamada nativa es funcional y no daña el control de usuario de todos modos. El control de usuario se puede ver bien en el diseñador solo con la llamada DLL incluida. Además, si el control se agrega manualmente a un formulario y se ejecuta como un programa, también se mostrará bien.

Esto me hace sospechar que el problema es solo una cuestión de Visual Studio Designer que necesita saber dónde se encuentra esa DLL nativa. Pero no estoy seguro de cómo decirlo, o dónde colocar el archivo DLL para que pueda encontrarlo. Por lo que sé, no hay forma de que en la configuración del proyecto se haga referencia a una DLL nativa. Así que tiene sentido para mí que el diseñador se esté quejando simplemente porque no puede arreglarlo.

¿Hay alguna manera de que esto funcione?

Answer 1

Lamentablemente, ha encontrado un "error de diseño" en VS (o en otras palabras, una "función").

Su sospecha de que el problema es una cuestión del diseñador de Visual Studio que necesita saber dónde se encuentra el archivo DLL nativo es parcialmente derecho. No se trata de ignorar su ubicación, sino más bien del hecho de que el diseñador no puede reflexionar sobre los ensambles de modo mixto (aquellos que contienen código administrado y nativo) para crear una instancia del control. Esto está causando que la caja de herramientas muestre el error que anotó.

La solución consiste en compilar los archivos fuente de C++ utilizando /clr:pure para crear un EXE puramente administrado.

Otra posibilidad (también un "error por diseño" en VS) es que el control que está tratando de agregar se ha compilado como un componente de 64 bits. Como Visual Studio es un proceso de 32 bits, solo puede ejecutar módulos de 32 bits. Si bien le permite agregar una referencia a un ensamblaje de 64 bits, realmente no puede compilar JIT ese ensamblaje de 64 bits y ejecutarlo dentro del proceso.

La solución aquí es compilar su ensamblado de control de usuario utilizando la configuración "AnyCPU", que hará que se ejecute como un proceso de 32 bits en un entorno de 32 bits y un proceso de 64 bits en un 64- entorno de bits. Realmente, esto es lo mejor de ambos mundos, suponiendo que hayas escrito tu código correctamente.

Por último, si ninguno de los trabajos, siempre hay la opción de pasar por el diseñador.Todavía puede escribir el código necesario para crear una instancia de su control de usuario y establecer sus propiedades en el inicializador del formulario. Todo lo que perdería sería la capacidad de usar el control dentro del diseñador dentro de Visual Studio. Todo funcionaría como se esperaba en el tiempo de ejecución.

Answer 2

cosas para probar:

VS2010: copiar el archivo DLL en la carpeta Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies.

VS2008, VS2010: copie el dll en la carpeta AppData\Local\Microsoft\VisualStudio\<version>\ProjectAssemblies\.

Answer 3

Me parece que el control con la referencia a la DLL nativa falla porque Visual Studio no puede cargarlo. Intente configurar la variable de entorno PATH de forma global o para el ejecutable de Visual Studio cuando lo ejecute. Si eso no ayuda, intente depurar el comportamiento del tiempo de diseño de su control y debería poder localizar el problema.

Answer 4

Encontré esto que parece un problema similar?

https://connect.microsoft.com/VisualStudio/feedback/details/388107/winforms-designer-fails-to-load-managed-dll-having-unmanaged-dependencies#details

Así EM parecen ser oficialmente diciendo actualización de VS2008 a VS2010 como una solución.

¿Alguna vez encontró una solución diferente?

Este es un problema que estoy experimentando en este momento en VS2008 con un proyecto administrado C# .net utilizando un proyecto de envoltura C++ administrado usando un proyecto C++ no administrado.

Definitivamente, me parece que los ensamblados temporales de diseñador que Visual Studio está utilizando son un problema: carga el ensamblado contenedor de dependencia detectado en la carpeta temporal pero no en las dependencias no administradas del ensamblado contenedor. Puedo ver que esto está en C: \ Users \ Username \ AppData \ Local \ Microsoft \ VisualStudio \ 9.0 \ ProjectAssemblies. Cuando intento cargar el diseñador, se crea una nueva carpeta allí con la DLL administrada, pero no las dependencias no administradas. Lamentablemente, no puedo entender lo que la persona en la pregunta del enlace de Microsoft dice que es la solución usando $ (TargetDir).

Answer 5

Enlace su biblioteca con la opción /DELAYLOAD:"your_native.dll ". Esto resolvió el mismo problema para mí.

Answer 6

Tuve un problema similar al que puede ser el tuyo (¿quién sabe cuántas cosas podrían estar causando esto?), Básicamente, que no podía dejar los controles en un diseñador, pero los controles existentes funcionaban bien tanto en producción como en pruebas.

Para el registro, aquí fue mi solución:

1) cambiar la configuración de la solución a x86. Esto me permitió poner el control sobre el diseñador, moverlo, etc. 2) Cuando haya terminado, puede volver a AnyCPU o x64. Realmente solo estoy usando el diseñador para simplificar la configuración de algunos valores, y parece que todo lo de 32/64 bits causa problemas.