Sign in to follow this  

[.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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
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 this post


Link to post
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)
#endif

BOOL 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)
#endif


extern "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 this post


Link to post
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 this post


Link to post
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.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this