Call Native Libraries from C# with P/Invoke (2026)

P/Invoke is how C# talks to native code, but it’s not a simple function call; it’s a full-blown inter-process communication mechanism with its own marshaling and type conversion rules.

Let’s see it in action. Imagine we have a simple C DLL, NativeLib.dll, that exports a function AddNumbers:

// NativeLib.c
#include <windows.h>

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) {
    switch (fdwReason) {
        case DLL_PROCESS_ATTACH:
        case DLL_THREAD_ATTACH:
        case DLL_THREAD_DETACH:
        case DLL_PROCESS_DETACH:
            break;
    }
    return TRUE;
}

extern "C" __declspec(dllexport) int AddNumbers(int a, int b) {
    return a + b;
}

We compile this into NativeLib.dll. Now, in C#, we can call AddNumbers like this:

using System;
using System.Runtime.InteropServices;

public class NativeCaller
{
    // Import the native function
    [DllImport("NativeLib.dll", CallingConvention = CallingConvention.Cdecl)]
    public static extern int AddNumbers(int a, int b);

    public static void Main(string[] args)
    {
        int result = AddNumbers(5, 10);
        Console.WriteLine($"The sum is: {result}"); // Output: The sum is: 15
    }
}

Here, [DllImport("NativeLib.dll", CallingConvention = CallingConvention.Cdecl)] is the magic. It tells the .NET runtime that AddNumbers is a function defined in NativeLib.dll. CallingConvention.Cdecl specifies how arguments are passed and how the caller cleans up the stack, matching the C standard.

The core problem P/Invoke solves is bridging the gap between managed (C#) and unmanaged (native DLL) code. Native libraries have their own memory management, type systems, and calling conventions. P/Invoke acts as a translator, converting .NET types to their native equivalents and vice-versa, and ensuring the correct calling convention is used. This allows you to leverage existing C/C++ libraries or interact with the operating system’s native APIs directly from your C# code.

When you call AddNumbers(5, 10) from C#, the following happens under the hood:

1. Type Marshaling: The int arguments 5 and 10 are marshaled by the .NET runtime. For simple types like int, this is usually a direct bit-for-bit copy, as both C# int and C int are typically 32-bit signed integers.
2. Function Resolution: The runtime finds the AddNumbers function within NativeLib.dll.
3. Calling Convention: The runtime invokes AddNumbers using the specified CallingConvention.Cdecl. This means the C# code pushes arguments onto the stack, and the called C function is responsible for cleaning up the stack after it returns.
4. Execution: The native AddNumbers function executes, calculates 5 + 10 = 15.
5. Return Value Marshaling: The integer 15 is returned from the native function. It’s marshaled back into a C# int.
6. Result Assignment: The returned C# int is assigned to the result variable.

The [DllImport] attribute is highly configurable. You can specify the library name, the entry point name (if it differs from the C# method name using EntryPoint), the character set for strings (CharSet.Ansi, CharSet.Unicode, CharSet.Auto), and the calling convention. For strings, CharSet.Auto is often the safest bet as it defaults to Unicode on Windows and Ansi on other platforms.

Consider a more complex example with strings: a native function that appends " World" to a given string.

// NativeLib.c
#include <windows.h>
#include <string.h>

extern "C" __declspec(dllexport) void AppendWorld(char* str, int bufferSize) {
    if (str && bufferSize > 11) { // Ensure enough space for " World" + null terminator
        strcat_s(str, bufferSize, " World");
    }
}

In C#:

using System;
using System.Runtime.InteropServices;

public class NativeCaller
{
    [DllImport("NativeLib.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
    public static extern void AppendWorld([MarshalAs(UnmanagedType.LPStr)] string str, int bufferSize);

    public static void Main(string[] args)
    {
        // We need a mutable string buffer. A fixed-size character array is common.
        // The buffer must be large enough for the original string, " World", and null terminator.
        byte[] buffer = new byte[100]; // Allocate a buffer
        string initialString = "Hello";
        int bytesCopied = System.Text.Encoding.ASCII.GetBytes(initialString, 0, initialString.Length, buffer, 0);
        buffer[bytesCopied] = 0; // Null terminate

        // P/Invoke typically passes strings by reference to the native side.
        // We can't directly pass a C# string because they are immutable.
        // We need to marshal it as a mutable character array or use a helper.
        // For simplicity here, let's assume a helper or a different signature.

        // A more robust approach involves passing a pointer to a managed buffer:
        IntPtr bufferPtr = Marshal.AllocHGlobal(buffer.Length);
        Marshal.Copy(buffer, 0, bufferPtr, buffer.Length);

        // The native function needs to accept a pointer and size.
        // Let's redefine the native function signature slightly for demonstration:
        // extern "C" __declspec(dllexport) void AppendWorldPtr(char* str, int bufferSize);

        // And the P/Invoke signature:
        [DllImport("NativeLib.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
        public static extern void AppendWorldPtr(IntPtr str, int bufferSize);

        AppendWorldPtr(bufferPtr, buffer.Length);

        // Copy back and null-terminate the result
        Marshal.Copy(bufferPtr, buffer, 0, buffer.Length);
        Marshal.FreeHGlobal(bufferPtr); // Release native memory

        // Find the null terminator to get the actual string
        int nullIndex = Array.IndexOf(buffer, (byte)0);
        string resultString = System.Text.Encoding.ASCII.GetString(buffer, 0, nullIndex);

        Console.WriteLine($"The modified string is: {resultString}"); // Output: The modified string is: Hello World
    }
}

The [MarshalAs(UnmanagedType.LPStr)] attribute tells the marshaler how to convert the C# string to a native type. LPStr indicates a null-terminated ANSI string. For Unicode, you’d use UnmanagedType.LPWStr. The bufferSize is crucial because native code often doesn’t know the managed string’s length and needs a fixed buffer size to prevent buffer overflows. Passing IntPtr and Marshal.AllocHGlobal/Marshal.FreeHGlobal is the standard way to manage memory that needs to be passed to and from native code.

A common pitfall is incorrect type marshaling, especially with strings, arrays, and structs. If the [MarshalAs] attribute or the C# type doesn’t match the native function’s expectation, you’ll get corrupted data or crashes. Another is the calling convention; mismatching it leads to stack corruption and unpredictable behavior. Always ensure the CallingConvention in [DllImport] matches how the native function was compiled. For C++ functions, extern "C" is essential to prevent name mangling.

When dealing with structs, ensure the [StructLayout] attribute on the C# struct precisely matches the memory layout of the native struct. LayoutKind.Sequential is common, but Pack and Size might need to be specified to align with the native definition.

The next hurdle you’ll likely encounter is handling complex data structures or callbacks from native code back into managed code.