0

I created a dll with visual C++ 2010 express (win32). Then moved the file inside the bin directory (debug or release) of a visual C# 2010 express (X86) application because I wanted to call a function from this assembly:

public MyForm() { InitializeComponent(); functionCall(); } [DllImport("extern.dll", CallingConvention = CallingConvention.Cdecl)] public static extern void functionCall(); 

Everything worked properly.
Then I decided to move some of the functionality of this form inside a user control, among them this extern function call.

public MyControl() { InitializeComponent(); functionCall(); } [DllImport("extern.dll", CallingConvention = CallingConvention.Cdecl)] public static extern void functionCall(); 

Now a problem arises: Visual Studio designer cannot show the Form, despite if the program is executed it runs ok. The error on the form designer is the following:

Could not load file or assembly extern.dll or one of its dependencies. Operation is not supported. (Exception from HRESULT…)

If I call the function from a different thread (for some reason I need it), Visual Studio crashes without any clue. On the web I’ve read about problems displaying winform by the VS designer, but no one seems to answer my exact question, in particular the dll file is not blocked and both the unmanaged .dll and the managed .exe seem to be 32bit.

UPDATE:
It’s incredible how, despite all searches made I missed the only keyword that would have helped me: DesignMode.
I fixed it like this:

public MyControl() { InitializeComponent(); if (!isDesignMode()) functionCall(); } private bool isDesignMode() { return (System.Diagnostics.Process.GetCurrentProcess().ProcessName.ToLower() == "vcsexpress" || System.Diagnostics.Process.GetCurrentProcess().ProcessName.ToLower() == "devenv"); } 
1
  • 1
    The odds that this DLL can be found at design time are very low, Windows will look in the wrong directories. Use the DesignMode property to prevent dangerous code from running at design time. Commented Aug 4, 2015 at 13:17

1 Answer 1

1

The Visual Studio designer does not support many things (in my experiences - inheritance, generics, and various database stuff). Instead, what you can do is wrap any usages of unsupported mechanics in a check to the DesignMode property:

if (this.DesignMode) { //TODO: some fake UI changes that represent what the external call // does so what you see in the designer is more accurate } else { //TODO: Use unsupported mechanic, such as using an external dll // Note that it's best to put the actual extern method definition elsewhere } 

It's possible that the problem is when the designer performs static initialization of your class, it encounters the extern reference and immediately tries loading the referenced dll (which it can't find, for some reason). I've found it best to put all extern definitions in their own wrapper classes (such as Win32ToolKit static class for all the User32.dll stuff).

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.