CODEWITHSUNDEEP
c#unmanaged
Matty C
Matty C

Reputation: 21

Differences in methods to call unmanaged C++ dll from C#

I am calling some unmanaged C functions (in an external dll) from C#. I have 2 different methods to do so, and I am not sure of the differences between the 2 (other than the amount of code)

Method #1

[DllImport("PComm32.dll",CallingConvention=CallingConvention.StdCall, EntryPoint ="PmacSelect")]
public static extern int PmacSelect(IntPtr intPtr);

int device = PmacSelect(IntPrt.Zero);

Method #2

[UnmanagedFunctionPointer(CallingConvention.StdCall)]
public delegate int PmacSelect(IntPrt intptr);

[DllImport("kernel32.dll")]
public static extern IntPtr LoadLibrary(string dllToLoad);

[DllImport("kernel32.dll")]
public static extern IntPtr GetProcAddress(IntPtr hModule, string procedureName);

[DllImport("kernel32.dll")]
public static extern bool FreeLibrary(IntPtr hModule);

public PmacSelect PmacSelectFunction;


private IntPtr pDll = LoadLibrary("PComm32");
IntPtr pAddressOfFunctionToCall = GetProcAddress(pDll, "PmacSelect"); //find the function in the loaded pcomm32 dll

PmacSelectFunction = (PmacSelect)Marshal.GetDelegateForFunctionPointer(pAddressOfFunctionToCall,type(PmacSelect));

int device = PmacSelectFunction(IntPrt.Zero);

Both methods work, and call the PmacSelect Function located in the PComm32.dll file. My question is what are the functional differences between the 2 methods? Method #1 must rely on windows managing the DLL in the background for me as needed? Could windows load and unload the dll without my knowledge? I dont really care if it does, as long as it automatically loads is when I call a function in the dll.

Method #2 The DLL is loaded explicitly when I call LoadLibrary. Does the library remain in memory until I free it?

Upvotes: 2

Views: 446

Answers (2)

user2605194
user2605194

Reputation:

When you pinvoke with DllImport, LoadLibrary ends up getting called for you, and the exported function is (hopefully) found in the EAT. Basically in your second example you're doing the same thing as a typedef + GetModuleHandle & GetProcAddress for c/c++.

The only reason I could think to use your second method, would be if the DllMain of your unmanaged module executes code upon attachment to a process, which you might depending on the scenario want to have specific timing control over when that module gets loaded into your process.

Upvotes: 0

Darrin Cullop
Darrin Cullop

Reputation: 1208

I'll give you answers, but you seem to already understand what is going on.

My question is what are the functional differences between the 2 methods?

There is no functional difference between the two methods. In the first method (which you should use if at all possible), the DotNet framework is handling everything for you. Under the hood, it is doing exactly what you're doing manually: Calling LoadLibrary, GetProcAddress, and at some point, FreeLibrary. Those are the steps to calling a function in a DLL.

Method #1 must rely on windows managing the DLL in the background for me as needed? Could windows load and unload the dll without my knowledge?

Yes, that's exactly right, although I wouldn't say it is without your knowledge. You are telling it to do that when you write [DllImport("PComm32.dll"...)].

Method #2 The DLL is loaded explicitly when I call LoadLibrary. Does the library remain in memory until I free it?

Again, yes, you understand what is happening.

Since you seem to answered your own questions and I've merely confirmed your answers, let you give you the reasons why you should (almost) always use #1:

  1. It works just as well
  2. It is easier to use and easier to read / maintain
  3. There is no value in doing it the hard way (#2)

I can only think of one reason that you would ever want to bother with the second method: If you needed to be able to replace the DLL, on the fly, with a newer version or something, without quitting your application, then you would want the fine grain control over when the DLL is unloaded (so that the file can be replaced).

That is unlikely to be a requirement except in very special cases.

Bottom Line: If you're using C#, you accept the fact that you are giving control to the framework in exchange for being able to focus on the work, and not worry about things like DLL or memory management. The DotNet framework is your friend, let it do the heavy lifting for you, and focus your efforts on the rest of the code.

Upvotes: 2

Related Questions