Unable to use Winforms control because of unresolved dependencies

Question

Problem: I have a WinForms control ('MyControl') with a dependency on myCli.dll, a dll written in C++ CLI. This component is third party (written by another team). myCli.dll has a dependency on myLibrary.dll which is written by yet another party. The control lives in myAssembly.dll, which is a C# controls and resources library.

I had this control working great when myCli.dll didn't have a dependency on myLibrary.dll. I could add it to forms, build it, and so on. But the new version of myCli.dll came out and I relinked against it. Suddenly, the IDE is behaving badly. The key issue appears to be that the IDE is unable to resolve the myCli.dll dependency on myLibrary.dll.

When I attempt to drag the control from the toolbox to a design surface, I get the error:

"Failed to create component 'MyControl'.  

The error message follows:

'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"

My belief is that if I can figure out where to put myLibrary.dll, I will resolve the reference issue. I don't know this for sure. Does someone know what I should do to resolve the issue?

Answer 1

In my case my code on Initialize and Form_Load contained calls to another project depending on DLL references. By excluding this code with

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

I was able to add the control on design time.

HTH

Answer 2

我认为DLL需要进入项目目录，然后将其设置为在构建时复制到输出目录。

Answer 3

For designer support, I think the myLibrary.dll must either go into C:\\Program Files\\Visual Studio xxx\\Common7\\IDE\\PublicAssemblies (assuming that myCLI.dll also lives there), or to the place where myCLI.dll exists or you might try copying it to C:\\Windows\\System32 - the system should be able to find it then.

Make sure to add it to the project as well and set it to "Copy always" as suggested by Clippit '98.

Answer 4

Another way to find the proper place would maybe the usage of Process Monitor . Just filter the output for your dll and check in which paths it searches for the file.

Answer 5

myCli.dll and all its dependencies need to be in the exact same folder, otherwise VS will not be able to find them.

The easiest way you could do this, is make sure that when it builds myCli.dll, it copies all the files to the Debug/Release folders, and then just reference those controls in your project from the Debug/Release folders directly.

Answer 6

I know this is an old thread, but just chiming in with what I used to fix my exact issue.

I initially used Peter Rakké's solution from this question ( https://stackoverflow.com/a/15077337/34440 ). But it wasn't the ideal one as it forced a change in my usual patterns.

Since my C++/CLI only used functions from the native dll at execution time and contained it's own interface information, I just changed the native dlls to be delay loaded. I added the two native dlls under the project settings in Visual Studio (Project Properties -> Configuration Properties -> Linker -> Input -> Delay Loaded Dlls). Make sure to set the Configuration and Platform drop downs at the top of the properties dialog box to be the All options and do a complete rebuild.

I could then reference the types from the C++/CLI DLL in my nested controls and forms.

Answer 7

Same situation as MedicineMan. WinForms project using 2 different components in libraryA.dll, which in turn had a dependency on libraryB.dll.

Solution that worked for me (just referencing applicable DLLs in all projects, even when all libraries are built in Debug mode, and without manually copying DLLs to different folders):

1. For components in libraryA.dll that override draw events, exit if in DesignTime mode:

    If Me.DesignMode Then Exit Sub 

2. For components in libraryA.dll with public properties using types from libraryB.dll, use attributes to Hide these properties from the designer (check syntax carefully - I've seen several other posts that have some strange spelling / variations):

    <DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> 

3. Re-build components, then re-start Visual Studio before using in WinForms project. For some reason changes in Attributes aren't detected during the same session and I burnt another couple of hours before trying the obvious.

If you're still having problems, there's an excellent post on getting debugging info during component binding (ie when you drag-n-drop component onto form): How to enable assembly bind failure logging (Fusion) in .NET (scroll down to answer by Mike Goatly).

Good luck.