26

My project run successful without errors in .NET Frame work 3.5. But, When I target it to .NET Frame work 4. I got the error:

"A call to PInvoke function has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature."

I used unmanaged library as below:

[StructLayout(LayoutKind.Sequential )]
public class DGNElemCore
{
    public int offset;
    public int size;
    public int element_id;
    public int stype;          
    public int level;
    public int type;
    public int complex;
    public int deleted;
    public int graphic_group;
    public int properties;
    public int color;
    public int weight;
    public int style;
    public int attr_bytes;       
    public IntPtr attr_data;  
    public int raw_bytes;
    public IntPtr raw_data;                 

}

[DllImport("DgnLib.dll", EntryPoint = "DGNOpen")]           
public static extern IntPtr  DGNOpen(string fileName, int bUpdate)

Do you know how to fix this error ?

Martin Liversage
  • 104,481
  • 22
  • 209
  • 256
taibc
  • 897
  • 2
  • 15
  • 39
  • 1
    http://stackoverflow.com/questions/13006580/error-calling-c-dll-function-in-c-sharp ? suggests the return type should be `DGNElemCore`, not `IntPtr` (btw: I found that by doing a google search for `DGNOpen pinvoke` - it was the second answer... right after your duplicate of this question on MSDN) – Marc Gravell Dec 04 '13 at 10:34
  • @MarcGravell: But `DGNOpen` returns a `DGNHandle` which I believe is a void pointer thus `IntPtr` is the right type. Or did I overlook something? – Martin Liversage Dec 04 '13 at 10:39
  • *Do you know how to fix this error?* Yes, I do know how. But that is contingent on seeing the native declarations. This is interop. Asking a question with only half of the interface is like a game of pin the tail on the donkey. – David Heffernan Dec 04 '13 at 10:40
  • 1
    Moving to .NET 4 typically also means you moved to a new VS version, VS2010+. Which uses a different default for the Platform target setting, now forcing 32-bit code. 64-bit code is pretty permissive of declaration mistakes, 32-bit code is not. CallingConvention matters, it should be Cdecl for this function. Return type is good, it is DGNHandle which is a pointer. – Hans Passant Dec 04 '13 at 12:26

2 Answers2

55

Add this along with dll import.

, CallingConvention = CallingConvention.Cdecl)]

As taken from here.

Platform invoke

To improve performance in interoperability with unmanaged code, incorrect calling conventions in a platform invoke now cause the application to fail. In previous versions, the marshaling layer resolved these errors up the stack.

Debugging your applications in Microsoft Visual Studio 2010 will alert you to these errors so you can correct them. If you have binaries that cannot be updated, you can include the element in your application's configuration file to enable calling errors to be resolved up the stack as in earlier versions. However, this may affect the performance of your application.

Ehsan
  • 31,833
  • 6
  • 56
  • 65
  • Thanks No One very much ! I added ", CallingConvention = CallingConvention.Cdecl" and successful – taibc Dec 05 '13 at 02:56
  • Just saved the day with this one. Had a very old DLL that would not play nice with my new projects until I added the calling convention. +1 :) – iCollect.it Ltd Jul 08 '15 at 10:38
  • 3
    I don't see how those paragraphs from the link explain why you needed to specify the calling convention? What was "incorrect" to begin with? VB code that uses the Declare statement don't use attributes. – shawn1874 Apr 03 '18 at 19:00
  • @Ehsan Did not work for me in a more complicated scenario spawning the same error message as described in the comments of [this answer](https://stackoverflow.com/a/50002894/3911632). Please take a look if you have any ideas. – Chad Jan 23 '20 at 05:57
1

I added, CallingConvention.ThisCall, while importing the DLL and it worked

Please try other constants, and check which one works in your environment

Khabri ONBBC
  • 11
  • 1