.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