Vanara: a .NET PInvoke library that maps Windows DLLs to typed C# assemblies

Vanara maps each Windows DLL to a matching .NET assembly, one DLL per assembly

Each Windows system library gets a dedicated .NET assembly named after the DLL it covers. Vanara.PInvoke.Gdi32.dll, for example, holds all functions and supporting enumerations, constants and structures exported from gdi32.dll. Kernel32.dll covers both kernel32.lib and kernelbase.lib in a single assembly. That one-to-one naming maps directly to the Windows Developer documentation, so finding a function in the Microsoft docs and then finding its Vanara equivalent follows the same namespace.

Types shared across many libraries, such as macros and enumerations that appear in multiple Windows headers, go into one of two shared assemblies. Macros like HIWORD and structures like SIZE live in Vanara.PInvoke.Shared. Helper classes that simplify interop calls and native memory management live in Vanara.Core. Every file inside a project is named after the Windows header file where those types are defined: FileApi.cs corresponds to fileapi.h, WinBase.cs to winbase.h, and WinNT.cs to winnt.h, all inside the Kernel32 project directory. Cross-referencing between the Vanara source and the Windows SDK documentation follows naturally from that convention. A question about a `fileapi.h` function leads to FileApi.cs in the Kernel32 project. Per-assembly readme files linked from the Supported Libraries table give a drill-down view of each assembly's coverage, which is where confirming that a specific function has been implemented is done before adding the package.

Adding Vanara: Vanara.Library for everything, or individual assemblies selected by DLL

Two installation strategies are documented. Vanara.Library is a single NuGet package that includes all Vanara assemblies. Per the README, this is 'Overkill, but easy.' For projects that want only the APIs they use, the selective path is to check which DLL a function comes from in the Microsoft documentation, find the matching assembly in the Supported Libraries table in the README, and then add that specific package via NuGet.

All packages build against .NET 4.8, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, .NET Standard 2.0 and 2.1, and Core 3.1. Projects that need support for .NET versions older than those should look to version 3.3.15 and earlier of the library, per the README.

Pre-release builds are available on MyGet at https://www.myget.org/feed/Packages/vanara. Every GitHub commit triggers a GitHub Actions build, and the resulting NuGet packages land there for test purposes before official release. Extensions for WinForms, WPF and UWP projects are available as additional assemblies.

Two calling patterns: fully qualified namespace or C# 6.0 static using directive

Once an assembly is referenced, calling a Windows API function works in two ways. With the fully qualified name approach, the namespace is included at each call site:

var bret = Vanara.PInvoke.Kernel32.GetComputerName(sb, ref sbSz);

With C# 6.0 and later, a static using directive at the top of the file brings all the functions from that namespace into scope, removing the prefix from each call:

using static Vanara.PInvoke.Kernel32;

var bret = GetComputerName(sb, ref sbSz);

Before calling any function, checking for overloads is a documented step. Functions often have overloads that handle memory allocation, pointer management, and complex call patterns automatically. Calling the lower-level form when an overload exists adds work that the library already does. For cases where there is a wrapper class in a supporting assembly, the README notes to look for it in the Security, System Services, Forms or Shell libraries, since those provide higher-level abstractions over the raw PInvoke signatures.

SafeHandle derivatives name Windows handle types and call the right cleanup function on disposal

Raw Windows handles become typed SafeHandle derivatives with automatic resource management. HTOKEN becomes SafeHTOKEN, which builds on the base handle with an automated release that calls CloseHandle on disposal. Naming follows the Windows API type directly, so searching for a handle type by its Windows name locates its Vanara equivalent.

Structures that allocate memory needing cleanup are changed from structs to classes implementing IDisposable, which means the .NET garbage collector and using statements handle cleanup rather than requiring explicit free calls. When a structure is always passed into a function as a constant reference, the Vanara signature uses the in modifier rather than ref. For MapDialogRect, whose Windows signature is `BOOL MapDialogRect(HWND hDlg, LPRECT lpRect)`, the Vanara version is `bool MapDialogRect(HWND hDlg, in RECT lpRect);`. Passing with in does not require the ref keyword at the call site, which removes a source of accidental mutation and matches the original API's intent.

All functions that allocate memory to be freed by the caller use a safe memory handle rather than a raw pointer. Functions also come with overloads, including generated overloads, that handle memory allocation, pointer management and complex patterns automatically. Calling the lower-level base signature when a higher-level overload exists means doing work the library already does.

Supporting assemblies go beyond raw PInvoke: Security, SystemServices, Windows.Shell and Windows.Forms

Five wrapper assemblies sit above the PInvoke layer. Vanara.Core provides helper classes for interop and native memory. Vanara.Security wraps security-related APIs. Vanara.SystemServices covers system services. Vanara.Windows.Forms provides Windows Forms extensions, and Vanara.Windows.Shell covers shell functionality. WPF, WinUI and UWP extensions are also available as separate assemblies, per the top-level repository entries, which include WPF.Extensions/, WinUI.Extensions/ and Windows.Extensions/.

Those wrapper assemblies exist because raw PInvoke signatures for Shell and Security functions are especially involved. COM interface wrapping, output buffer management and multi-step API sequences are common in those areas, and wrapper classes remove the repetitive scaffolding. For a developer who wants access to a specific Security API, the README recommendation is to check the Security assembly's library page before reaching for the raw PInvoke assembly.

Vanara is Windows-only, and writing PInvoke declarations manually is the cross-platform alternative

All Vanara assemblies target Windows APIs. A .NET project that needs to run on Linux or macOS cannot use Vanara for platform-independent code, because there are no Linux or macOS implementations of Windows-specific DLLs. Where calls are conditionally compiled for Windows only, Vanara remains an option, but it adds a Windows-specific NuGet dependency to the project's package tree that must be excluded from non-Windows builds.

Not every Windows API is covered. Functions added in newer Windows releases do not appear in Vanara until a later library version. The Supported Libraries table in the README shows coverage per DLL, and the per-assembly readme files give function-level detail. For a function not yet in Vanara, GitHub's project search can confirm whether it appears anywhere in the repository, but if it does not, the only path is a manual DllImport declaration outside the library.

The alternative to adopting Vanara is writing PInvoke declarations by hand using DllImport attributes in C#. That approach requires writing the type mappings, handling marshalling attributes, wrapping handles in SafeHandle derivatives manually, and managing allocated memory in calling code. Vanara's existing mappings remove that work for covered APIs, at the cost of adopting a third-party library that may not yet wrap the exact DLL function a project needs.

MIT license, releases every few weeks, and the last push was on 2026-09-29

License is MIT, per the LICENSE file at the repository root. Version 5.0.5 was released on 2026-05-16, 5.0.6 on 2026-08-12, and 5.0.7 on 2026-08-15. Per the README, new versions come out every few weeks after sufficient testing. Release notes are published in the Releases section of GitHub, and all NuGet packages are pushed to nuget.org on each release.

GitHub Actions runs a CI build on every commit. Build status appears in the repository header. Pre-release packages from those builds are on MyGet for test use before official release.

The last push was on 2026-09-29. The repository is not archived. Version 5.0.x is the current release line across the three most recent tagged releases, all of which carry full release notes.

Editorial conclusion

Vanara is for .NET developers who need to call Windows native APIs frequently enough that writing raw DllImport declarations by hand becomes unsustainable. Version 5.0.x supports .NET 4.8 through 10.0 and Standard 2.0 and 2.1; projects on older .NET versions need 3.3.15 or earlier. The library is Windows-only by design, which means cross-platform code cannot adopt it without conditional compilation guards around every call. Before adding an assembly, check the Supported Libraries table in the README to confirm coverage of the specific function you need, since not every Windows API is implemented.

Frequently asked questions

Official sources

1. dahall/Vanara on GitHub
2. Issues
3. License: MIT
4. README
5. Releases