# [.net] platform invoke issue

This topic is 3638 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

using vista X64 & vstudio 2K8 beta 2 i'm trying to get P/invoke working so i could interop with legacy code & i thought i'd start with something simple so i made a new win32 console project (then set as dll & empty project) with just this __declspec(dllexport) int returns20() { return 20; } i build my dll & i always get a entry point not found exception in my C# program C# part looks like [DllImport("dlltest.dll")] public static extern int returns20(); upon calling the returns20() function in C# my program gives me the exeption everywhere i looked on the web the issue is related to a missnamed type (can't happen here , did 10+ dll with diferent names to try , always copy pasting the name) or to wrongly placed file (tried with absolute path & tried while having it in the same dir) i also know the C# prog does manage to lookup the dll but simply rejects it as if i let it in cpu agnostic (default to 64 bit on my pc) it will throw another exception (badformat exception) now the worse part is i can't see how i could mess up the dll generation but it must be on that side that the issue resides since the exact same p/invoke code works when i invoke winapi native code any clues? or if no clues anyone be so kind to zip me a solution with 2 small projects (1 defining a simple c function in a dll & other using it in a winform to display the result?) both compiled & source so i could see if it actually runs on my comp & if so if it also runs once i compile it myself? apreciate any help you all could provide edit: forgot to add , dependency walker seems to see functions in my dll just fine too & is able to remove the decoration & see their right name so that's one more thing putting me at loss exact exception i get is (don't google it , i'm translating from french might not be exact) "could not find entry point <function name here> for testdll"

##### Share on other sites
self bumping once because with interop being the big thing nowadays i can't imagine no one could answer me & it doesn't seem possible either that visual studio beta 2 could be pushing out wrongly compiled dlls, wtb a clue!

##### Share on other sites
I think it has to do with name mangling. This link may help:

Summary: Try putting 'extern "C"' in front of your __declspec(dllexport) lines.

##### Share on other sites
i crash coursed this over vacation. i don't understand your problem, but i'll post my test code. This is mostly autogenerated by vc8ee. New project, win32; application settings, DLL, export symbols.

.cpp
#include "stdafx.h"#include "screenripper.h"#ifdef _MANAGED#pragma managed(push, off)#endifBOOL APIENTRY DllMain( HMODULE hModule,                       DWORD  ul_reason_for_call,                       LPVOID lpReserved					 ){	//switch (ul_reason_for_call)	//{	//case DLL_PROCESS_ATTACH:	//case DLL_THREAD_ATTACH:	//	break;	//case DLL_THREAD_DETACH:	//case DLL_PROCESS_DETACH:	//	break;	//}    return TRUE;}#ifdef _MANAGED#pragma managed(pop)#endif// This is an example of an exported function.SCREENRIPPER_API int verify_interop(void){	return 42;}

.h
// The following ifdef block is the standard way of creating macros which make exporting // from a DLL simpler. All files within this DLL are compiled with the SCREENRIPPER_EXPORTS// symbol defined on the command line. this symbol should not be defined on any project// that uses this DLL. This way any other project whose source files include this file see // SCREENRIPPER_API functions as being imported from a DLL, whereas this DLL sees symbols// defined with this macro as being exported.#ifdef SCREENRIPPER_EXPORTS#define SCREENRIPPER_API __declspec(dllexport)#else#define SCREENRIPPER_API __declspec(dllimport)#endifextern "C" SCREENRIPPER_API int verify_interop(void);

Once I got all that working I wrapped all my C++ functionality with a few extern "C" wrapper functions, which are the public interface. Its apparently a whole lot easier to interop with C than with C++ due to symbol mangling.

##### Share on other sites
yea the C++ name mangling was the issue , i wonder why it cant handle that by default tho as dependency walker manages to unmangle the function names in my dll just fine

##### Share on other sites

This topic is 3638 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.