Question

I have a C++ ‘Control Library Project’ compiled using /CLR. Inside this project there is a User Control that makes a call to a native DLL. This user control appears in the designer toolbox as it should, but I cannot then drag it onto a form. Without the reference to the DLL the user control can be used fine, but with the reference I just get the message “Failed to load toolbox item” when trying to use it.

The native call is functional and not harming the User Control in anyway. The User Control can be viewed fine in the designer by itself with the DLL call included. Also if the control is added manually to a form and executed as a program, it will also display fine.

This makes me suspect that the problem is just a matter of Visual Studio Designer needing to know where that native DLL is located. But I’m not sure how to tell it, or where to put the DLL so that it can find it. As far as I known there is no way in the project settings to reference a native DLL. So it makes sense to me that designer is just complaining because it can’t fine it.

Is there a way to make this work?

Answer 1

Unfortunately, you’ve encountered a “bug by design” in VS (or in other words, a “feature”).

Your suspicion that the problem is a matter of the Visual Studio designer needing to know where the native DLL is located is partially right. It’s not a matter of ignorance to it’s location, but rather the fact that the designer cannot reflect over mixed-mode assemblies (those that contain both managed and native code) in order to instantiate the control. This is causing the toolbox to show the error you noted.

The workaround is to compile the C++ source files using /clr:pure to create a purely managed EXE.

Another possibility (also a “bug by design” in VS) is that the control you’re trying to add has been compiled as a 64-bit component. Because Visual Studio is a 32-bit process, it can only execute 32-bit modules. While it allows you to add a reference to a 64-bit assembly, it cannot actually JIT compile that 64-bit assembly and execute it within process.

The workaround here is to compile your user control assembly using the “AnyCPU” setting, which will cause it to execute as a 32-bit process in a 32-bit environment, and a 64-bit process in a 64-bit environment. Really, this is the best of both worlds, assuming you’ve written your code correctly.

Finally, if none of those work, there’s always the option of bypassing the designer. You can still write the code necessary to instantiate your user control and set its properties in the form’s initializer. All that you would be losing is the ability to use the control inside of the designer inside Visual Studio. Everything would work as expected at run-time.