locked
Calling old C++ code from VB.net projects using P/Invoke gets "Unable to find entry" error RRS feed

  • Question

  •  

    I'm trying to reuse my old C++ code in a VB.net project. It appears one way to do that is using the so-called P/invoke method which is what I have attempted to do. It appears my VB.net project does find and pick up the dll created for the old C++ code, but at run time I get an error indicating the C++ entry point is not being found.

     

    Here is the exact code.  I'm creating a .dll called CPShortTest.dll with this C++ code (doesn't matter if I build the .dll with VS6 or VS8):

     

    #include "stdafx.h"

    BOOL APIENTRY DllMain( HANDLE hModule,

    DWORD ul_reason_for_call,

    LPVOID lpReserved

    )

    {

        return TRUE;

    }

    int __declspec(dllexport) shorttest(void)

    {

       return(3);

    }

     

    In VB.net code I have:

     

    Imports System.IO

    Imports System.Text

    Imports System.Collections

    Imports System.Runtime.InteropServices

    Public Class NativeMethods

      <DllImport("CPShortTest.dll")> _

        Public Shared Function shorttest() As Integer

      End Function

    End Class

    ....

    Dim Integer ind = NativeMethods.shorttest()

        Unable to find an entry point named 'shorttest' in DLL 'CPShortTest.dll'.

     

    I have gone through many different variations of the above approach and so far no solution.  Any help would be appreciated

    Friday, April 4, 2008 12:17 AM

All replies

  • The function may have been exported with a mangled name. You can check the export name using a tool like Dumpbin.exe or Dependency Walker. The easiest way to control the export name is to use a DEF file.

     

    You should also use the _stdcall calling convention in the function (or change the DllImport attribute).

     

     

    Friday, April 4, 2008 8:32 AM
  • Dear Mattias,

     

    Thanks for the reply. 

     

    I have tried 2 other calling conventions including __stdcall with the same result.  In fact, just using __stdcall instead of __declspec(dllexport) doesn't even export the symbol.  But with __declspec the symbol gets exported and in fact dumpbin then shows it as a __stdcall (see below).

     

    As for mangling, yes, it is getting mangled up pretty good.  Is it not supposed to?  Here is the dumpbin output:

                   ?short_test@@YGHH@Z (int __stdcall short_test(int))

     

    How would you change the DllImport on the other side to match this and get exactly that?

     

    Also, I have never used .DEF files directly so if you can spell it out exactly what I need to do in the .DEF file that would help.

     

    I looked at dependencywalker.  Even though a nice tool for other purposes, I'm not sure if it helps me here because while it gives useful information when run on the .dll, it doesn't do anything pertinent for the VB.net app in regardes to the .dll being imported and the symbol we're looking for.  In other words, I don't know what the symbol the VB.net app is looking for is and dependencywalker doesn't seem to either!  It would have been a nice complement to dumpbin if it did but doesn't.  If you know of a way to make it do that let me know.

     

    Regards,

     

    Rasar

    Friday, April 4, 2008 5:12 PM