Generated banner for Dotnet Pinvoke
Generated logo for Dotnet Pinvoke

Dotnet Pinvoke

.NET (Microsoft)OfficialPublished by .NET (Microsoft)

  • Skill
  • Tool integration
  • Software development
  • MIT
  • No issues found

From the author

Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging existing native interop code, wrapping a C or C++ library for use in .NET, diagnosing crashes, memory leaks, or corruption at the managed/native boundary. DO NOT USE FOR: COM interop, C++/CLI mixed-mode assemblies, or pure managed code with no native dependencies.
— the description by .NET (Microsoft)

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a comprehensive guide to calling native C/C++ code from .NET applications. It covers the essential mechanics of bridging managed and unmanaged code, focusing on correct type mapping, memory management, string marshalling, and the use of modern source-generated interop via LibraryImport. The skill emphasizes safety, performance, and cross-platform compatibility, helping developers avoid common pitfalls like memory leaks, stack corruption, and access violations at the native boundary.

What it does

  • Maps native C/C++ types to their correct .NET equivalents to prevent data corruption.
  • Guides the implementation of DllImport and modern LibraryImport for AOT-compatible interop.
  • Provides patterns for safe memory ownership and native handle management using SafeHandle.
  • Explains correct string marshalling and encoding strategies for cross-platform support.
  • Offers debugging strategies for common interop failures like AccessViolationException.
  • Details how to handle native callbacks and function pointers safely.

When to use it

  • When you need to call functions from a native C or C++ library within a .NET project.
  • When writing new P/Invoke or LibraryImport declarations from native headers.
  • When debugging crashes, memory leaks, or data corruption occurring at the native boundary.
  • When migrating legacy DllImport code to modern LibraryImport for AOT or trimming support.
  • When wrapping native libraries to expose them as managed APIs.

Advantages

  • Reduces risk of memory corruption and crashes by enforcing correct type and memory contracts.
  • Improves application performance by leveraging source-generated interop.
  • Ensures cross-platform compatibility by addressing platform-specific type sizes.
  • Promotes robust error handling and resource management through SafeHandle usage.
  • Facilitates AOT and trimming compatibility for modern .NET deployments.

Usage examples

“How do I correctly map a C size_t type in my .NET P/Invoke signature?”
The agent will advise using nuint (on .NET 8+) or UIntPtr to ensure pointer-sized compatibility across 32-bit and 64-bit architectures, warning against the use of ulong.
“I am getting an AccessViolationException when calling a native function. How do I debug this?”
The agent will guide you to verify signature alignment, check struct sizes using Marshal.SizeOf, ensure proper memory pinning, and confirm that calling conventions match.
“How can I safely pass a string to a native C library that expects UTF-8?”
The agent will provide a LibraryImport example using StringMarshalling.Utf8 or a DllImport example using MarshalAs(UnmanagedType.LPUTF8Str).
“What is the best way to handle a native handle returned by a C library?”
The agent will recommend subclassing SafeHandle to ensure the native resource is automatically released and protected from double-free errors.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/dotnet/dotnet-pinvoke/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip dotnet-pinvoke.zip -d .agents/skills

Documentation by .NET (Microsoft)

.NET P/Invoke

Calling native code from .NET is powerful but unforgiving. Incorrect signatures, garbled strings, and leaked or freed memory are the most common sources of bugs — all can manifest as intermittent crashes, silent data corruption, or access violations far from the actual defect.

This skill covers both DllImport (available since .NET Framework 1.0) and LibraryImport (source-generated, .NET 7+). When targeting .NET Framework, always use DllImport. When targeting .NET 7+, prefer LibraryImport for new code. When native AOT is a requirement, LibraryImport is the only option.

When to Use This Skill

  • Writing a new [DllImport] or [LibraryImport] declaration from a C/C++ header

  • Reviewing P/Invoke signatures for correctness (type sizes, calling conventions, string encoding)

  • Wrapping an entire C library for use from .NET

  • Debugging AccessViolationException, DllNotFoundException, or silent data corruption at the native boundary

  • Migrating DllImport declarations to LibraryImport for AOT/trimming compatibility

  • Diagnosing memory leaks or heap corruption involving native handles or buffers

Stop Signals

  • Single function? Map the signature (Steps 1-3), handle strings/memory only if relevant, skip tooling and migration sections.

  • Don't migrate existing DllImport to LibraryImport unless the user asks or AOT/trimming is an explicit requirement.

  • Don't recommend CsWin32 unless the target is specifically Win32 APIs.

  • Don't generate callbacks (Step 8) unless the native API requires function pointers.

  • Review request? Use the validation checklist — don't rewrite working code.

Inputs

InputRequiredDescription
Native header or documentationYesC/C++ function signatures, struct definitions, calling conventions
Target frameworkYesDetermines whether to use DllImport or LibraryImport
Target platformsRecommendedAffects type sizes (long, size_t) and library naming
Memory ownership contractYesWho allocates and who frees each buffer or handle

Agent behavior: When documentation and native headers diverge, always trust the header. Online documentation (including official Win32 API docs) frequently omits or simplifies details about types, calling conventions, and struct layout that are critical for correct P/Invoke signatures.


Workflow

Step 1: Choose DllImport or LibraryImport
AspectDllImportLibraryImport (.NET 7+)
MechanismRuntime marshallingSource generator (compile-time)
AOT / Trim safeNoYes
String marshallingCharSet enumStringMarshalling enum
Error handlingSetLastErrorSetLastError
Availability.NET Framework 1.0+.NET 7+ only
Step 2: Map Native Types to .NET Types

The most dangerous mappings — these cause the majority of bugs:

C / Win32 Type.NET TypeWhy
longCLong32-bit on Windows, 64-bit on 64-bit Unix. With LibraryImport, requires [assembly: DisableRuntimeMarshalling]
size_tnuint / UIntPtrPointer-sized. Use nuint on .NET 8+ and UIntPtr on earlier .NET. Never use ulong
BOOL (Win32)intNot bool — Win32 BOOL is 4 bytes
bool (C99)[MarshalAs(UnmanagedType.U1)] boolMust specify 1-byte marshal
HANDLE, HWNDSafeHandlePrefer over raw IntPtr
LPWSTR / wchar_t*stringUTF-16 on Windows (lowest cost for in strings). Avoid in cross-platform code — wchar_t width is compiler-defined (typically UTF-32 on non-Windows)
LPSTR / char*stringMust specify encoding (ANSI or UTF-8). Always requires marshalling cost for in parameters

For the complete type mapping table, struct layout, and blittable type rules, see references/type-mapping.md.

❌ NEVER use int or long for C long — it's 32-bit on Windows, 64-bit on Unix. Always use CLong. ❌ NEVER use ulong for size_t — causes stack corruption on 32-bit. Use nuint or UIntPtr. ❌ NEVER use bool without MarshalAs — the default marshal size is wrong.

Step 3: Write the Declaration

Given a C header:

int32_t process_records(const Record* records, size_t count, uint32_t* out_processed);

DllImport:

[DllImport("mylib")]
private static extern int ProcessRecords(
    [In] Record[] records, UIntPtr count, out uint outProcessed);

LibraryImport:

[LibraryImport("mylib")]
internal static partial int ProcessRecords(
    [In] Record[] records, nuint count, out uint outProcessed);

Calling conventions only need to be specified when targeting Windows x86 (32-bit), where Cdecl and StdCall differ. On x64, ARM, and ARM64, there is a single calling convention and the attribute is unnecessary.

Agent behavior: If you detect that Windows x86 is a target — through project properties (e.g., <PlatformTarget>x86</PlatformTarget>), runtime identifiers (e.g., win-x86), build scripts, comments, or developer instructions — flag this to the developer and recommend explicit calling conventions on all P/Invoke declarations.

// DllImport (x86 targets)
[DllImport("mylib", CallingConvention = CallingConvention.Cdecl)]

// LibraryImport (x86 targets)
[LibraryImport("mylib")]
[UnmanagedCallConv(CallConvs = [typeof(CallConvCdecl)])]

If the managed method name differs from the native export name, specify EntryPoint to avoid EntryPointNotFoundException:

// DllImport
[DllImport("mylib", EntryPoint = "process_records")]
private static extern int ProcessRecords(
    [In] Record[] records, UIntPtr count, out uint outProcessed);

// LibraryImport
[LibraryImport("mylib", EntryPoint = "process_records")]
internal static partial int ProcessRecords(
    [In] Record[] records, nuint count, out uint outProcessed);
Step 4: Handle Strings Correctly
  1. Know what encoding the native function expects. There is no safe default.

  2. Windows APIs: Always call the W (UTF-16) variant. The A variant needs a specific reason and explicit ANSI encoding.

  3. Cross-platform C libraries: Usually expect UTF-8.

  4. Specify encoding explicitly. Never rely on CharSet.Auto.

  5. Never introduce StringBuilder for output buffers.

❌ NEVER rely on CharSet.Auto or omit string encoding — there is no safe default.

// DllImport — Windows API (UTF-16)
[DllImport("kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
private static extern int GetModuleFileNameW(
    IntPtr hModule, [Out] char[] filename, int size);

// DllImport — Cross-platform C library (UTF-8)
[DllImport("mylib")]
private static extern int SetName(
    [MarshalAs(UnmanagedType.LPUTF8Str)] string name);

// LibraryImport — UTF-16
[LibraryImport("kernel32", StringMarshalling = StringMarshalling.Utf16,
    SetLastError = true)]
internal static partial int GetModuleFileNameW(
    IntPtr hModule, [Out] char[] filename, int size);

// LibraryImport — UTF-8
[LibraryImport("mylib", StringMarshalling = StringMarshalling.Utf8)]
internal static partial int SetName(string name);

String lifetime warning: Marshalled strings are freed after the call returns. If native code stores the pointer (instead of copying), the lifetime must be manually managed. On Windows or .NET Framework, CoTaskMemAlloc/CoTaskMemFree is the first choice for cross-boundary ownership; on non-Windows targets, use NativeMemory APIs. The library may have its own allocator that must be used instead.

Step 5: Establish Memory Ownership

When memory crosses the boundary, exactly one side must own it — and both sides must agree.

❌ NEVER free with a mismatched allocator — Marshal.FreeHGlobal on malloc'd memory is heap corruption.

Model 1 — Caller allocates, caller frees (safest):

[LibraryImport("mylib")]
private static partial int GetName(
    Span<byte> buffer, nuint bufferSize, out nuint actualSize);

public static string GetName()
{
    Span<byte> buffer = stackalloc byte[256];
    int result = GetName(buffer, (nuint)buffer.Length, out nuint actualSize);
    if (result != 0) throw new InvalidOperationException($"Failed: {result}");
    return Encoding.UTF8.GetString(buffer[..(int)actualSize]);
}

Model 2 — Callee allocates, caller frees (common in Win32):

[LibraryImport("mylib")]
private static partial IntPtr GetVersion();
[LibraryImport("mylib")]
private static partial void FreeString(IntPtr s);

public static string GetVersion()
{
    IntPtr ptr = GetVersion();
    try { return Marshal.PtrToStringUTF8(ptr) ?? throw new InvalidOperationException(); }
    finally { FreeString(ptr); } // Must use the library's own free function
}

Critical rule: Always free with the matching allocator. Never use Marshal.FreeHGlobal or Marshal.FreeCoTaskMem on malloc'd memory.

Model 3 — Handle-based (callee allocates, callee frees): Use SafeHandle (see Step 6).

Pinning managed objects — when native code stores the pointer or runs asynchronously:

// Synchronous: use fixed
public static unsafe void ProcessSync(byte[] data)
{
    fixed (byte* ptr = data) { ProcessData(ptr, (nuint)data.Length); }
}

// Asynchronous: use GCHandle
var gcHandle = GCHandle.Alloc(data, GCHandleType.Pinned);
// Must keep pinned until native processing completes, then call gcHandle.Free()
Step 6: Use SafeHandle for Native Handles

Raw IntPtr leaks on exceptions and has no double-free protection. SafeHandle is non-negotiable.

internal sealed class MyLibHandle : SafeHandleZeroOrMinusOneIsInvalid
{
    // Required by the marshalling infrastructure to instantiate the handle.
    // Do not remove — there are no direct callers.
    private MyLibHandle() : base(ownsHandle: true) { }

    [LibraryImport("mylib", StringMarshalling = StringMarshalling.Utf8)]
    private static partial MyLibHandle CreateHandle(string config);

    [LibraryImport("mylib")]
    private static partial int UseHandle(MyLibHandle h, ReadOnlySpan<byte> data, nuint len);

    [LibraryImport("mylib")]
    private static partial void DestroyHandle(IntPtr h);

    protected override bool ReleaseHandle() { DestroyHandle(handle); return true; }

    public static MyLibHandle Create(string config)
    {
        var h = CreateHandle(config);
        if (h.IsInvalid) throw new InvalidOperationException("Failed to create handle");
        return h;
    }

    public int Use(ReadOnlySpan<byte> data) => UseHandle(this, data, (nuint)data.Length);
}

// Usage: SafeHandle is IDisposable
using var handle = MyLibHandle.Create("config=value");
int result = handle.Use(myData);
Step 7: Handle Errors

Set LibraryImportAttribute.SetLastError to true when the native API's contract requires capturing the OS last-error value, then retrieve it with Marshal.GetLastPInvokeError().

// Win32 APIs — check SetLastError
[LibraryImport("kernel32", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
internal static partial bool CloseHandle(IntPtr hObject);

if (!CloseHandle(handle))
    throw new Win32Exception(Marshal.GetLastPInvokeError());

// HRESULT APIs
int hr = NativeDoWork(context);
Marshal.ThrowExceptionForHR(hr);
Step 8: Handle Callbacks (if needed)

Preferred (.NET 8+): UnmanagedCallersOnly — avoids delegates entirely, no GC lifetime risk:

[UnmanagedCallersOnly]
private static void LogCallback(int level, IntPtr message)
{
    string msg = Marshal.PtrToStringUTF8(message) ?? string.Empty;
    Console.WriteLine($"[{level}] {msg}");
}

[LibraryImport("mylib")]
private static unsafe partial void SetLogCallback(
    delegate* unmanaged<int, IntPtr, void> cb);

unsafe { SetLogCallback(&LogCallback); }

The method must be static, must not throw exceptions back to native code, and can only use blittable parameter types.

Fallback (older TFMs or when instance state is needed): delegate with rooting

[UnmanagedFunctionPointer(CallingConvention.Cdecl)] // Only needed on Windows x86
private delegate void LogCallbackDelegate(int level, IntPtr message);

// CRITICAL: prevent delegate from being garbage collected
private static LogCallbackDelegate? s_logCallback;

public static void EnableLogging(Action<int, string> handler)
{
    s_logCallback = (level, msgPtr) =>
    {
        string msg = Marshal.PtrToStringUTF8(msgPtr) ?? string.Empty;
        handler(level, msg);
    };
    SetLogCallback(s_logCallback);
}

If native code stores the function pointer, the delegate must stay rooted for its entire lifetime. A collected delegate means a crash.

GC.KeepAlive for short-lived callbacks: When converting a delegate to a function pointer with Marshal.GetFunctionPointerForDelegate, the GC does not track the relationship between the pointer and the delegate. Use GC.KeepAlive to prevent collection before the native call completes:

var callback = new LogCallbackDelegate((level, msgPtr) =>
{
    string msg = Marshal.PtrToStringUTF8(msgPtr) ?? string.Empty;
    Console.WriteLine($"[{level}] {msg}");
});

IntPtr fnPtr = Marshal.GetFunctionPointerForDelegate(callback);
NativeUsesCallback(fnPtr);
GC.KeepAlive(callback); // prevent collection — fnPtr does not root the delegate

Cross-Platform Library Loading

Use NativeLibrary.SetDllImportResolver for complex scenarios, or conditional compilation for simple cases. Use CLong/CULong for C long/unsigned long. Note: CLong/CULong with LibraryImport requires [assembly: DisableRuntimeMarshalling].

// Trivial: use platform naming convention
// The default naming convention adds corresponding prefix and extension when
// searching the nativelibrary. The resultant file name will be mylib.dll on
// Windows, libmylib.so on Linux and libmylib.dylib on macOS.
private const string LibName = "mylib";

// Simple: conditional compilation
// WINDOWS, LINUX, MACOS are predefined only when targeting an OS-specific TFM
// (e.g., net8.0-windows). For portable TFMs (e.g., net8.0), these symbols are
// not defined — use the runtime resolver approach below instead.
#if WINDOWS
    private const string LibName = "mylib.dll";
#elif LINUX
    private const string LibName = "libmylib.so";
#elif MACOS
    private const string LibName = "libmylib.dylib";
#endif

// Complex: runtime resolver
// When targeting netstandard2.0 or other frameworks when OperatingSystem.IsXXX
// is not available, use RuntimeInformation.IsOSPlatform(OSPlatform.XXX) api.
NativeLibrary.SetDllImportResolver(typeof(MyLib).Assembly,
    (name, assembly, searchPath) =>
    {
        if (name != "mylib") return IntPtr.Zero;
        string libName = OperatingSystem.IsWindows()
            ? "mylib.dll"
            : OperatingSystem.IsMacOS()
                ? "libmylib.dylib" : "libmylib.so";
        NativeLibrary.TryLoad(libName, assembly, searchPath, out var handle);
        return handle;
    });

Migrating DllImport to LibraryImport

For codebases targeting .NET 7+, migrating provides AOT compatibility and trimming safety.

  1. Add partial to the containing class and make the method static partial

  2. Replace [DllImport] with [LibraryImport]

  3. Replace CharSet with StringMarshalling

  4. Preserve SetLastError = true for APIs that require capturing the OS last-error value

  5. Remove CallingConvention unless targeting Windows x86

  6. Build and fix SYSLIB1054–SYSLIB1057 analyzer warnings

Enable the interop analyzers:

<PropertyGroup>
    <EnableTrimAnalyzer>true</EnableTrimAnalyzer>
    <EnableAotAnalyzer>true</EnableAotAnalyzer>
</PropertyGroup>

Tooling

CsWin32 (Win32 APIs)

For Win32 P/Invoke, prefer Microsoft.Windows.CsWin32 over hand-written signatures. It source-generates correct declarations from metadata. Add a NativeMethods.txt listing the APIs you need:

dotnet add package Microsoft.Windows.CsWin32
CsWinRT (WinRT APIs)

For WinRT interop, use Microsoft.Windows.CsWinRT to generate .NET projections from .winmd files.

Objective Sharpie (Objective-C APIs)

For binding Objective-C libraries (macOS/iOS), use Objective Sharpie to generate initial P/Invoke and binding definitions from Objective-C headers.


Validation

Review checklist
  • [ ] Every signature matches the native header exactly (types, sizes)

  • [ ] Calling convention specified if targeting Windows x86; omitted otherwise

  • [ ] String encoding is explicit — no reliance on defaults or CharSet.Auto

  • [ ] Memory ownership is documented and matched (who allocates, who frees, with what)

  • [ ] SafeHandle used for all native handles (no raw IntPtr escaping the interop layer)

  • [ ] Delegates passed as callbacks are rooted to prevent GC collection

  • [ ] DllImportAttribute.SetLastError or LibraryImportAttribute.SetLastError set to true when the native API requires last-error capture

  • [ ] Struct layout matches native (packing, alignment, field order)

  • [ ] CLong/CULong used for C long/unsigned long in cross-platform code

  • [ ] If using CLong/CULong with LibraryImport, [assembly: DisableRuntimeMarshalling] is applied

  • [ ] No bool without explicit MarshalAs — always specify UnmanagedType.Bool (4-byte) or UnmanagedType.U1 (1-byte) to ensure normalization across the language boundary.

Runnable validation steps
  1. Build with interop analyzers enabled — confirm zero SYSLIB1054–SYSLIB1057 warnings:

    <EnableTrimAnalyzer>true</EnableTrimAnalyzer>
    <EnableAotAnalyzer>true</EnableAotAnalyzer>
  2. Verify struct sizes match — for every struct crossing the boundary, assert Marshal.SizeOf<T>() equals the native sizeof

  3. Round-trip test — call the native function with known inputs and verify expected outputs

  4. Test with non-ASCII strings — pass strings containing characters outside the ASCII range to confirm encoding is correct

Reference Files

  • references/type-mapping.md — Complete native-to-.NET type mapping table, struct layout patterns, blittable type rules. Load when encountering types not covered in Step 2 above, or when working with struct layout or blittable type questions.

  • references/diagnostics.md — Common pitfalls, failure modes and recovery, debugging approach, external resources. Load when debugging an existing P/Invoke failure or reviewing interop code for correctness issues.

Files

references/type-mapping.md

Native-to-.NET Type Mapping

Complete reference for mapping C/Win32 types to .NET types. Every parameter must match exactly — this is where most P/Invoke bugs originate.

Primitive Types

C / Win32 Type.NET TypeNotes
intintAlways 32-bit in Win32 ABI
int32_tint
uint32_tuint
int64_tlong
uint64_tulong
DWORDuint
HRESULTintSome tools project this as an enumeration
floatfloat
doubledouble

Dangerous Types (Most Common Bug Sources)

These types have non-obvious mappings that frequently cause bugs:

C / Win32 Type.NET TypeWhy It's Dangerous
longCLongC long is 32-bit on Windows, 64-bit on 64-bit Unix — never use int or long. With LibraryImport, requires [assembly: DisableRuntimeMarshalling] or you get SYSLIB1051. With DllImport, works without it
size_tnuint / UIntPtrPointer-sized. Use nuint on .NET 8+ and UIntPtr on earlier .NET. Never use ulong — causes stack corruption on 32-bit
intptr_tnintPointer-sized
BOOL (Win32)intNot bool — Win32 BOOL is 4 bytes
bool (C99)[MarshalAs(UnmanagedType.U1)] boolMust specify 1-byte marshal
void*void*Requires unsafe context

Handle and String Types

C / Win32 Type.NET TypeNotes
HANDLE, HWNDSafeHandlePrefer over raw IntPtr
LPWSTR / wchar_t*stringUTF-16 on Windows (lowest cost for in strings). Avoid in cross-platform code — wchar_t width is compiler-defined (typically UTF-32 on non-Windows)
LPSTR / char*stringMust specify encoding (ANSI or UTF-8). Always requires marshalling cost for in parameters

Blittable Types

Blittable types have identical managed and native layouts — zero marshalling overhead.

Blittable: byte, sbyte, short, ushort, int, uint, long, ulong, float, double, nint, nuint, and structs of only blittable fields. With [assembly: DisableRuntimeMarshalling], bool (1 byte) and char (2 bytes, char16_t) are also treated as blittable.

Not blittable (without DisableRuntimeMarshalling): bool, char, string, decimal, anything with MarshalAs.

Struct Layout

// Sequential layout (most common)
[StructLayout(LayoutKind.Sequential)]
internal struct Vec3 { public float X, Y, Z; }

// Explicit layout for unions
// C: typedef union { int32_t i; float f; } Value;
[StructLayout(LayoutKind.Explicit, Size = 4)]
internal struct Value
{
    [FieldOffset(0)] public int I;
    [FieldOffset(0)] public float F;
}

// Non-default packing
// C: #pragma pack(push, 1)
[StructLayout(LayoutKind.Sequential, Pack = 1)]
internal struct PackedHeader
{
    public byte Magic;
    public uint Size;    // At offset 1, not 4
    public ushort Flags; // At offset 5, not 8
}

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
.NET (Microsoft)
Publisher
.NET (Microsoft) (Official)
Source
dotnet/skills · plugins/dotnet-advanced/skills/dotnet-pinvoke · commit 96c3d68
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by .NET (Microsoft).

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download dotnet-pinvoke.zip