When I use c++ dll in c#, I get the PInvokeStackImbalance error.
Managed Debugging Assistant 'PInvokeStackImbalance' has detected a problem in.....
Here is the c# code I used:
[DllImport("Mydll.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern bool MyFunction(char[] logPath, float f1, float f2);
c++ dll function
EXTERNC MYDLL_API bool WINAPI MyFunction(char[] logPath, float f1, float f2);
c++ environment : VS 2013 (win32)
c# environment : VS 2013 (.net framework 4.5)
I've been searching for this problem, but couldn't find the answer I'm looking for.
How can I solve this?
Related
I have an old DLL which was built in VC6.0.
And I want to use this DLL at VC2019 project.
This DLL file is a MFC DLL, and contains a lot of classes and functions.
There is no problem for using classes and functions except these three functions (which contains CString parameter).
The exported DLL functions (class functions) are like below:
class CColorListCtrl : public CListCtrl
{
...
public:
int AddColumn(CString szHeaderStr, int nColWidth);
int AddItem(CString szItem);
bool SetItemTip(int nRow, int nCol, CString szTip);
...
}
And the link errors are like below:
error LNK2001: unresolved external symbol "public: int __thiscall CColorListCtrl::AddColumn(class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > >,int,int)" (?AddColumn#CColorListCtrl##QAEHV?$CStringT#DV?$StrTraitMFC#DV?$ChTraitsCRT#D#ATL#####ATL##HH#Z)
error LNK2001: unresolved external symbol "public: int __thiscall CColorListCtrl::AddItem(class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > >)" (?AddItem#CColorListCtrl##QAEHV?$CStringT#DV?$StrTraitMFC#DV?$ChTraitsCRT#D#ATL#####ATL###Z)
error LNK2001: unresolved external symbol "public: bool __thiscall CColorListCtrl::SetItemTip(int,int,class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > >)" (?SetItemTip#CColorListCtrl##QAE_NHHV?$CStringT#DV?$StrTraitMFC#DV?$ChTraitsCRT#D#ATL#####ATL###Z)
The DLL exported functions are like below:
?AddColumn#CColorListCtrl##QAEHVCString##HH#Z
?AddItem#CColorListCtrl##QAEHVCString###Z
?SetItemTip#CColorListCtrl##QAE_NHHVCString###Z
For fix this problem, I changed Project Character Set (Project Setting -> General -> Character Set) as "Use Multi-Byte Character Set", but the problem is not solved.
I noticed that CString class was changed, so the CString classes at VC6 and VC2019 are different.
I have no idea to resolve this prblem. Also I can not change DLL, because I removed the project for this DLL.
Please help me.
Thank you.
CString in VC++ 6 and VC++ 2019 are not compatible with each other because there is a difference.
That is, if you use CString as a parameter for the export function in VC6 dll, you cannot directly call VC6 dll in VS2019.
I suggest one solution:
First, create a dll that acts as a repeater in vc6. The export function of this dll uses, for example, LPCTSTR as a parameter. Let this dll be A.dll and the original dll be B.dll.
Inside the A.dll, the export function of the B.dll is called and the result is converted to LPCTSTR and returned.
VS2019 calls the export function of A.dll. LPCTSTR is compatible between VS2019 and VS6, so you can solve your problem in this way.
There is some notes in this article (CStringT Class) where it states:
If your code contains the workaround for linker errors that is
described in Exporting String Classes Using CStringT, you
should remove that code. It is no longer needed.
I notice that the subsequent article that it refers to does state:
In the past, MFC developers have derived from CString to specialize
their own string classes. In Microsoft Visual C++.NET (MFC 8.0), the
CString class was superseded by a template class called CStringT.
It provides an explanation of what you can do to resolve linker issues.
I'm currently porting a large project to Atmel Studio from ICCAVR as I need to use some of the ASF libraries for the project I'm working on.
I'm getting this error with the code example below in regards to trying to convert the following line to Atmel Studio
void debugoutf(__flash char * header, __flash char * msg);
Error pointer targeting address space '__flash' must be const in
function parameter 'header'
I tried using the macro in the documentation so that it can compile in Atmel Studio.
#ifndef FLASHVAR_H_
#define FLASHVAR_H_
#include <avr/pgmspace.h>
#if defined(__ICCAVR__) // IAR C Compiler
#define FLASH_DECLARE(x) __flash x
#endif
#if defined(__GNUC__) // GNU Compiler
#define FLASH_DECLARE(x) x __attribute__((__progmem__))
#endif
IAR to AVR Conversion
void debugout(FLASH_DECLARE (char * header), char * msg);
My question is have I done the conversion correctly, as I don't think I've done it correctly as nothing is getting printed out in my UART debugging.
The problem with using __attribute__((__progmem__)) on a variable is that whenever you want to read data from such a variable, you can't just access it in the usual way that you would access a variable from RAM. Instead, you have to use special functions provided by the avr/pgmspace.h header in avr-libc, like pgm_read_byte.
That's pretty annoying, but you don't have to do it that way because why they added named address spaces like __flash to recent versions of GCC (assuming you are using C, not C++). I recommend you stop using __attribute__((__progmem__)) and use __flash instead, if your version of GCC supports it. If the compiler gives you an error or warning because it expects items stored in flash to be marked as const, you can simply add const to the declaration/definition (in the right position). If you have trouble doing that, please post a new question or edit this question so it contains a MCVE.
For the example code you gave, you should try writing:
void debugoutf(const __flash char * header, const __flash char * msg);
I have a need to compile an existing message library generated using ZeroC's ICE with c++ clr.
I've been at this for a while and I'm having no luck.
I have a very simple .ice message file defined.
Upon generating the cpp and h files for this, I try to compile them into a .dll.
My slice2cpp command line args are
C:\Program Files (x86)\ZeroC\Ice-3.5.1\bin\slice2cpp.exe --depend --dll-export=ENABLE_DLL -I"C:\Program Files (x86)\ZeroC\Ice-3.5.1\slice" -I".\.." --underscore "E:\test\platform\platform\testMessage.ice"
This generates me a testMessage.cpp and testMessage.h files.
Upon attempting to compile these, I get the error:
Error 7 error LNK2028: unresolved token (0A00098D) "class IceUtil::Shared * __cdecl IceInternal::upCast(class IceInternal::ObjectFactoryManager *)" (?upCast#IceInternal##$$FYAPEAVShared#IceUtil##PEAVObjectFactoryManager#1##Z) referenced in function "public: __cdecl IceInternal::Handle<class IceInternal::ObjectFactoryManager>::Handle<class IceInternal::ObjectFactoryManager>(class IceInternal::Handle<class IceInternal::ObjectFactoryManager> const &)" (??0?$Handle#VObjectFactoryManager#IceInternal###IceInternal##$$FQEAA#AEBV01##Z) E:\test\platform\platform\testMessage.obj platform
As per usual with Ice, I have to link the Iced.lib and IceUtild.lib files.
I compile with no pre compiled headers and /clr option on (not pure clr or safe)
using VS2013. The body of the testMessage.ice file is very simple.
#ifndef _MESSAGE_ICE_
#define _MESSAGE_ICE_
module messaging {
class Message
{
string clientId;
string origin;
string destination;
string messageType;
string suffix;
};
sequence<Message> MessageSeq;
class NonQueuedMsg extends messaging::Message {};
};
#endif
Compiling without the CLR option on results in success.
I imagine this is all caused by my lack of familiarity with c++ clr.
Any help would be appreciated.
I had the same problem after the migration of my projects to vs 2013.
The project c++ with ice compile fine
but the project c++/cli with ice don't links.
I fixed linking problem in ObjectFactoryManagerF.h :
#ifdef __cplusplus_cli
IceUtil::Shared* upCast(ObjectFactoryManager* p) { return (IceUtil::Shared*) p; };
#else
IceUtil::Shared* upCast(ObjectFactoryManager* );
#endif
I stopped trying to make C++/CLI and ICE-generated code work together after I read on their forum here that they didn't support it.
What I've done.. I've made native static library on the client's side where I had C++/CLI. Static library fully encapsulated all communication stuff and was referenced from C++/CLI part. As a result I've got a Mixed (C++/CLR) Recommended Rules assembly. It works fine plus I've got easier portable application.
I am wrapping a method of dll(c++) in C++/CLI. I am using x86 windows-xp machine with Vc++ 2010.
I have both x86 and x64 configuration in my c++/CLI project.
I am getting a compile error in x64 only. here is code snippet
struct A
{
int data;
A *__ptr32 next;
}
pin_ptr<A *>pinned = &obj->next; // A obj
above line is being compiled only in x86 configuration.
In x64 im am getting a compile error: can't convert A * to pin_ptr <Type>
compiler option: /clr
__pt32 constrains the pointer to a 32 bit pointer that only works on x86.
x64 works with 64 bit pointers...
just remove the size constraint and use it like a regular pointer:
struct A
{
int data;
A* next;
}
i have a header file named NetworkInterfaceInfoProvider.h.
in this header file i declare a class as follow:
#ifndef INETWORK_INTERFACE_INFO_PROVIDER_H
#define INETWORK_INTERFACE_INFO_PROVIDER_H
#pragma once
/*#include "stdafx.h"*/
#include "IConfig.h"
#include "NetworkAddapterAddresses.h"
#include "InstaledAddapters.h"
namespace IRNetwork
{
class CLASS_DECLSPEC INet;
struct CLASS_DECLSPEC GenericIPAddress;
/*
* provide information about all network interface related adapters such as installed interfaces , addresses , best routes and ...
* TO DO: implement Other OS's
*/
class CLASS_DECLSPEC INetworkInterfaceInfoProvider
{
public:
INetworkInterfaceInfoProvider(void);
~INetworkInterfaceInfoProvider(void);
int32_t GetBestRouteTo(char* destIp,uint16_t port,ip_t *ip);
int32_t GetBestRouteTo(GenericIPAddress* ip);
private:
INet* snet;
};
}
#endif
when i want to use it in my console application i got following linker error
*note: the library of above code has been linked to my console application.
CLASS_DECLSPEC is dll import/export definition*
error LNK2019: unresolved external symbol "__declspec(dllimport)
public: int __thiscall
IRNetwork::INetworkInterfaceInfoProvider::GetBestRouteTo(char
,unsigned short,char ()[65])" (_imp?GetBestRouteTo#INetworkInterfaceInfoProvider#IRNetwork##QAEHPADGPAY0EB#D#Z)
referenced in function "void __cdecl test_adapters(void)"
(?test_adapters##YAXXZ) testDhcpv4.obj testDhcpv4
what is wrong here?
Hmm. From the error I would say importing looks good. So maybe there was an error while exporting. Assuming you are using Visual Studio, you can use dumpbin to check if your dll is exporting correctly:
Open the Visual Studio Command Prompt (available from the windows start menu) and type
dumpbin /EXPORTS yourlib.dll
Then you should see our export, something like (dump from one of my dlls):
...
170 A9 00108120 ??1AbstractParam#param#core#megamol##UAE#XZ = ??1BoolParam#param#core#megamol##UAE#XZ (public: virtual __thiscall megamol::core::param::BoolParam::~BoolParam(void))
...
If the function your are calling is not listed, you should doublecheck if your dllexport is set correctly while building your dll.
If the function is listed, but looks different, you should check for the calling conventions to be the same for your application and your dll.
If the function is listed and the name looks identical to what the error message says, doublecheck if you are linking the import library of the dll correctly.
Also check if the runtime-configuration is the same for your application and your dll (e.g. Multi-Threaded-Dll or Multi-Threaded-Debug-Dll).