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?
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:
It works just as well
It is easier to use and easier to read / maintain
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.
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.
Related
A pointer is passed to me from a C++ dll as followed:
[DllImport("myfile.dll", EntryPoint = "LoadFile", SetLastError = true, CharSet = CharSet.None)]
public static extern IntPtr dLoadFile(string x);
IntPtr p = dLoadFile("myfile");
//Do things with p.
Marshal.FreeHGlobal(p) //crash on this line with exception below.
System.Runtime.InteropServices.COMException: 'One or more arguments
are invalid (Exception from HRESULT: 0x80000003)'
Should I free the memory allocated to IntPtr ? And if yes, how to do it properly ?
Obviously it seems that Marshal.FreeHGlobal() is not the way to go...
Thanks
The general rule is that "who allocates the resources needs to be called to perform the cleanup". In c#, you d not own the memory : the clr owns it. Your shared c# assemblies also share the clr, therfore you have the impression to create an object in one assembly and free it in another. When performing interoperability, a resource created by a library should be cleaned up by the same library via an additional exported api. There are some exceptions though, and they regard when operating systems objects are created :according to the specific documentation of the object in question, you can free the resource at caller site.
In your case, you should export the appropriate api in my file.dll that properly perform the cleanup.
This rule allows you not to disclose internal details, thus allowing you to change your internals without breaking the caller.
For example, in the old .NET Framework 2.0 Source Code (Windows Forms, Visual Studio 2005 - Whidbey), the GetClientRect function was defined using HandleRef:
[DllImport(ExternDll.User32, ExactSpelling=true, CharSet=CharSet.Auto)]
public static extern bool GetClientRect(HandleRef hWnd, [In, Out] ref NativeMethods.RECT rect);
In the new Windows API Code Pack (from Microsoft, 2009/2010) the same function is defined using IntPtr:
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
internal static extern bool GetClientRect(IntPtr hwnd, ref CoreNativeMethods.RECT rect);
Actually HandleRef is not used in any of the Windows API Code Pack source files, while it was heavily used in the native methods signatures in the old .NET Framework source files.
It's a bit fishy. HandleRef is not needed when handle values are stored in a SafeHandle derived object. Which the code pack declares, ZeroInvalidHandle, with several derived ones from it like SafeWindowHandle.
However, it doesn't actually use any of these SafeHandle classes anywhere. Not so sure if it really has to, a lot of the Vista and Win7 extensions are actually COM interfaces. Not the traditional handle based C API. They are kept alive through reference counts and are thus not subject to this kind of garbage collector mishap.
Personally I just never worry about this. Getting a class object collected while the API call is executing is a bug. It can happen just as easily a microsecond after the API call completed. Still a bug, just not one that makes the API call fail. Not so sure I'd actually want it to not fail, I'd much prefer an exception when I got a bug in my code. Microsoft needs to protect itself from this, they don't want to get the blame for the exception. I do.
My guess is that the newer code samples use IntPtr merely because it's simpler to understand.
A quick glance through Reflector at the function signatures in the various NativeMethods classes found in the .NET Framework shows that the actual usage is pretty well split between the two.
I assume this is based on whether or not there is a need to prevent the object from being garbage collected prematurely (which is the primary advantage to using HandleRef). Also keep in mind that using HandleRef is unnecessary unless the handle that you're passing is to a managed object. Unmanaged objects will not get garbage collected.
IntPtr is just structure that wraps pointer. As for HandleRef MSDN says "Wrapping a handle with HandleRef guarantees that the managed object is not garbage collected until the platform invoke call completes." There is a chance that GC can finalize handle during P/Invoke if you don't do anything with it after P/Invoke call. So HandleRef looks more safe.
How do I unload a DLL which has been loaded using DllImport in C#?
The most reliable way to unload an unmanaged DLL from a process that got loaded by a [DllImport] pinvoke declaration is to load it yourself, again, by pinvoking LoadLibrary(). That gives you a reliable handle to the DLL and works correctly even if the module name of the DLL is ambiguous. It doesn't have any affect at runtime, other than the Windows loader increasing the internal reference count on the DLL from 1 to 2.
You can then pinvoke FreeLibrary() twice to decrease the reference count to 0, passing it the IntPtr you got from LoadLibrary(). That unloads the DLL, as well as any dependent DLLs that got loaded.
Beware that you'll get very nasty failure when you try to pinvoke any exported function on the DLL again, any time after doing this. The pinvoke marshaller is unaware that the DLL isn't around anymore and will call the function at the address it thinks is still valid. Which bombs your program with an AccessViolation exception if you are lucky. Or runs a completely random bit of code if you are not so lucky and the address space formerly occupied by the DLL got re-used by another DLL. Anything can happen then, none of it good.
This should free a module previously loaded when you called P/Invoke function.
[DllImport("kernel32", SetLastError=true)]
static extern bool FreeLibrary(IntPtr hModule);
public static void UnloadModule(string moduleName)
{
foreach(ProcessModule mod in Process.GetCurrentProcess().Modules)
{
if(mod.ModuleName == moduleName)
{
FreeLibrary(mod.BaseAddress);
}
}
}
Based on Peters recommendation this works for me:
[DllImport("kernel32", SetLastError = true)]
private static extern bool FreeLibrary(IntPtr hModule);
public static void UnloadImportedDll(string DllPath)
{
foreach (System.Diagnostics.ProcessModule mod in System.Diagnostics.Process.GetCurrentProcess().Modules)
{
if (mod.FileName == DllPath)
{
FreeLibrary(mod.BaseAddress);
}
}
}
Late to the party, but I've made a tool to do this. It's supposed to run in Unity, but I think it can be adopted to other C# solutions. It's available here: https://github.com/mcpiroman/UnityNativeTool.
Please note that it is essentionally a hack (but often used hack, see Harmony), so I don't quite recommend using it at production code.
Since I came across the information here while I was looking around for information I figure I will contribute back what I ended up doing to fix an issue with the Sixense SDK on OSX IN UNITY. You'll see in there an implementation of dynamically loading/unloading a dylib on OSX:
https://gist.github.com/amirebrahimi/d7b02c01bcd3ca7da144
How long is the typical overhead added by calling a .dll written in C++ from a C# application using the following syntax?
[DllImport("abc.dll", EntryPoint = "xcFoo", CallingConvention = CallingConvention.Cdecl)]
public extern static Result Foo(out IntPtr session,
[MarshalAs(UnmanagedType.FunctionPtr)]ObjectCallback callback,
UInt64 turnKey,
string serverAddress,
string userId,
string password);
Is there a more efficient way to do it?
Check out this article on how to improve interop performance. What to do and what best to avoid.
http://msdn.microsoft.com/en-us/library/ms998551.aspx
Are you talking about the overhead of invoking the native method? If so, I dont think it is significant at all, as there are a lot of such calls in the .NET framework class libraries.
Now, whether the overhead is significant for your scenario can only be answered by doing performance measurements, and comparing them against what you expect.
The marshalling into the native method will cost three memory allocations from the NT heap, which is not so bad. It's the delegate back that gets worrysome.
A good method to check this sort of thing is throw in a break point where you make calls. Don't know when the library is loaded, so maybe only check the break point on the second call (unless loading cost is your main concern). Then open up the disassembly window in visual studio and see how many lines there are before your dll function is being invoked.
i know this question is old but ive managed to call native functions blazingly fast with not only using calli CIL instruction but also with special trick, but ofc you need to handle pinnig and/or marshalling arguments yourself if you deal with complex types including strings..
I have this problem, which I am dealing with for some time already. At start, I have two dlls with unmanaged code (let's say... dll_1, dll_2) and managed aplication in c#. What i'm supposed to do is to get pointers to unmanaged functions in dll_1 in managed code, pack it into structure, and send this structure as an argument to unmanaged function in dll_2. Have anyone dealt with that kind of problem before maybe?
Since you don't do anything in managed code but the DLLs live in the same process, just use an IntPtr (is automatically 32 or 64 bits depending on the platform) to pass the unmanaged pointer around. You can of course also insert the IntPtr into your struct and use it as argument or return value when using an external call (e.g. [DllImport('YourDll')] static extern IntPtr ImportedFunction();).
However, to give you more information, it would be necessary to know more about the DLL calls and their data structures.