Designer Rejecting User Control

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.

Link your library with /DELAYLOAD:"your_native.dll" option. This solved the same problem for me.