C++ Interop (/CLR) - Error LNK2028

I want to integrate C# user control in an ˇ°classicalˇ± MFC application. The whole project contains one .EXE and many .DLLs with objects used by the .EXE.

When DLLs are compiled, object are declared with ˇ°_declspec(dllexport)ˇ±.

When objects are used in .EXE, the are declared with ˇ°_declspec(dllimport)ˇ±.

I have added the /CLR option only in the .EXE (DLLs have only ˇ°business objectsˇ±). And when I compile the solution, I have the following error:

Error LNK2028: unresolved token (0A0001A5) ˇ°public int __thiscall CXXX:Xxxx() ˇ­..ˇ±

When I compiled the solution without the /CLR option, all is good.

The help on this error explains that in native, the calling convention is ˇ°__cdeclˇ± and in /clr:pure it is ˇ°__clrcallˇ±. But IˇŻm not in /clr!pure, I use only the /CLR option.

Any idea on how to solve this problem Unfortunately, I cannot add the /CLR option in all DLLs because I have a lot of errors (it will be a hard work).

Thanks for your help

Francois

Did you get any responses directly to this I am seeing the same issue, and am looking for a resolution.

Thx

No, I still have the problem. I have sent a mail to Microsoft but no answer ...

In fact, I have solved one of my LNK2028 problem. One of the classes defined in a DLL have a method named MessageBox. I have a link problem due to the MessageBox macro in windows to change to MessageBoxA or MessageBoxW. I have renamed my methode to TDMessageBox and the link is correct. Perhaps you have the same problem (or with another Windows macro name)

No, I don't think I have the same problem, but thank you for the suggestion. If I learn anything, or resolve it, I will update the post.

Cheers,

Jan

Hi Francois,

I got my linker issue resolved, but I MUST WARN you that I have not fully investigated this to validate that I did the proper thing. It makes sense to me, but I am still going to do more research on this to verify. I ~think~ this is what is going on, but I am by no means an expert on this.

My situation (in simplistic terms):

I have a Managed.cpp file and an Unmanaged.cpp file. My Managed.cpp file is calling into an Unmanaged.cpp function. The Unmanged function is defined in my Unmanage.h file

I believe the Managed.cpp file compiles the declaration of the unmanaged.h function with the keyword __clrcall, while Unmanged.cpp compiles it with the __thiscall keyword. The linker cannot resolve the different 'signatures' if you will.

To resolve this, I placed the keyword __thiscall in my Unmanaged.h function declaration:

WAS:

--------

int MyUnmangedFunc( struct MySharedStruct& )

NOW:

--------

int __thiscall MyUnmanagedFunc( struct MySharedStruct& )

I believe that by forcing that keyword in the declaration, when it is included in the Managed.cpp file, it forces it to be generated the same way as in the Unmanaged file, and the linker issue is resolved.

Incidentally, this issue shows up when I am passing "MySharedStruct" into the function, which is declared to be shared between managed and unmanaged c++ by:

public value struct MySharedStruct

{

// whatever

};

When the struct was changed to a void *, I didn't get the linker error. I suspect void* is interpreted the same in managed and unmanaged, which wouldn't 'kick in' the __clrcall in managed.

Anywho, give this a try, and see if it works. I am not promising anything, I only tried this last night, and haven't fully studied the ramifications.

Cheers,

Jan

I don't know if this will help, but this declaration (in my example)

Incidentally, this issue shows up when I am passing "MySharedStruct" into the function, which is declared to be shared between managed and unmanaged c++ by:

public value struct MySharedStruct

{

// whatever

};

Allows MySharedStruct to be shared between managed and unmanged. It is the keyword value which tags it as such. Did you try that

Cheers,

Jan

PS I think I ran into the same issue, and switched to __stdcall. This was for NON-member functions of a class, and seemed to work.