Native AOT | The .NET Blog

.NET 10 Ships with Ubuntu 26.04 LTS — Here's What's New

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

It’s Ubuntu LTS day. Ubuntu 26.04 (Resolute Raccoon) launched today, and as with every Ubuntu LTS, it ships with the latest .NET LTS — in this case, .NET 10.

If you deploy .NET apps on Linux, this is the release cycle you care about. LTS on LTS — five years of support for the OS, matching .NET 10’s own long-term support window.

Install .NET 10 in two commands

sudo apt update
sudo apt install dotnet-sdk-10.0

That’s it. .NET is one of the officially supported toolchains on Ubuntu — not a third-party add-on. Microsoft and Canonical work together to make sure it works on day one.

Try it immediately

Here’s the thing I love about this: you can pull an ubuntu:resolute container image and be running C# in under a minute.

docker run --rm -it ubuntu:resolute
apt update
apt install -y dotnet-sdk-10.0
dotnet run - << 'EOF'
using System.Runtime.InteropServices;
Console.WriteLine($"Hello {RuntimeInformation.OSDescription} from .NET {RuntimeInformation.FrameworkDescription}");
EOF

That dotnet run - with a heredoc is a file-based app pattern — no project file, no directory, just C# piped to stdin. Honest, if you haven’t tried file-based apps yet, it’s worth a look.

Containers: update `-noble` to `-resolute`

The new container images use the resolute tag. Migration is a one-liner:

sed -i "s/noble/resolute/g" Dockerfile

All existing image flavors — including Chiseled — are available. The Chiseled images are still my go-to for production: minimal attack surface, no shell, no package manager, just the runtime. Update the tag and rebuild.

Native AOT: 3ms startup, 1.4MB binary

Ubuntu 26.04 ships a dedicated AOT package:

apt install -y dotnet-sdk-aot-10.0 clang

Here’s what you get when you publish a simple app:

dotnet publish app.cs
# artifacts/app/app — 1.4MB native binary

Startup time:

real 0m0.003s

3 milliseconds. For a full ASP.NET Core web service, the self-contained binary is around 13MB. That’s a completely self-contained deployable with no runtime dependency whatsoever.

For cloud-native workloads where cold-start time matters — Functions, containers, serverless — this is a legitimate game changer.

What changed in Ubuntu 26.04 that affects .NET

Three things worth knowing:

Linux 7.0 — The .NET team will start Linux 7.0 testing once they get 26.04 VMs in the lab. No breaking changes expected, but they’ll verify.
Post-quantum cryptography — Ubuntu 26.04 introduces PQC support, and .NET 10 added post-quantum cryptography APIs as well. Good alignment.
cgroup v1 removed — Ubuntu 26.04 drops cgroup v1. .NET added cgroup v2 support years ago, so this is a non-event. But if you’re on an older runtime, double-check.

Need .NET 8 or 9?

Those are available via the dotnet-backports PPA:

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0 # or dotnet-sdk-9.0

Support is “best-effort” — not the same guarantee as the LTS package in the main archive — but the packages are there and they work.

Wrapping up

Every two years, the Ubuntu LTS + .NET LTS alignment gives you a solid, long-support foundation for production workloads. Ubuntu 26.04 with .NET 10 is that foundation for the next cycle.

If you’re containerizing .NET apps, update your Dockerfiles. If you’re deploying on bare metal or VMs, apt install dotnet-sdk-10.0 and you’re done.

Read the full post from Richard Lander for the complete installation walkthrough and container details.

Writing Node.js Native Addons in C# with .NET Native AOT

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Here’s a scenario I love: a team that works on .NET tooling had native Node.js addons written in C++ and compiled via node-gyp. It worked. But it required Python to be installed on every developer’s machine — an old version of Python, mind you — just to build a package that nobody on the team would ever touch directly.

So they asked a very reasonable question: we already have the .NET SDK installed, why are we writing C++ at all?

The answer was Native AOT, and the result is genuinely elegant. Drew Noakes from the C# Dev Kit team wrote up how they did it, and I think it’s worth understanding even if you’re not building VS Code extensions.

The basic idea

A Node.js native addon is a shared library (.dll on Windows, .so on Linux, .dylib on macOS) that Node.js can load at runtime. The interface is called N-API — a stable, ABI-compatible C API. N-API doesn’t care what language produced the library, only that it exports the right symbols.

.NET Native AOT can produce exactly that. It compiles your C# code ahead-of-time into a native shared library with arbitrary entry points. That’s the whole trick.

The project setup

The project file is minimal:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot is what tells the SDK to produce a shared library on dotnet publish. AllowUnsafeBlocks is needed for the N-API interop with function pointers and fixed buffers.

Exporting the entry point

Node.js expects your library to export napi_register_module_v1. In C#, [UnmanagedCallersOnly] does exactly that:

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

A few things worth calling out here. nint is a native-sized integer — the managed equivalent of intptr_t. The u8 suffix produces a ReadOnlySpan<byte> with a UTF-8 string literal, passed directly to N-API without any encoding allocation. And [UnmanagedCallersOnly] exports the method with the exact entry point name Node.js is looking for.

Resolving N-API against the host process

N-API functions are exported by node.exe itself, not a separate library. So instead of linking against something, you resolve them against the running process at startup:

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

With that in place, your P/Invoke declarations work cleanly:

[LibraryImport("node", EntryPoint = "napi_create_string_utf8")]
internal static partial Status CreateStringUtf8(
 nint env, ReadOnlySpan<byte> str, nuint length, out nint result);

The source-generated [LibraryImport] handles the marshalling. ReadOnlySpan<byte> maps to const char*, function pointers pass through directly, and it’s all trimming-compatible.

What an actual exported function looks like

Here’s the registry reader they built — the whole function, from reading arguments to returning a result:

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

Important note on the try/catch: an unhandled exception in an [UnmanagedCallersOnly] method crashes the host process. You always catch and forward to JavaScript via ThrowError.

Calling it from TypeScript

dotnet publish produces your platform-specific native library. You rename it to .node (Node.js convention for native addons) and use it with a standard require():

interface RegistryAddon {
 readStringValue(keyPath: string, valueName: string): string | undefined;
}

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;

const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
 'InstallLocation'
);

That’s it. TypeScript into C#, no Python, no C++.

What they gained

The immediate win was contributor experience: no specific Python version needed, yarn install works with just Node.js and the .NET SDK. CI pipelines got simpler too.

Performance was comparable to the C++ implementation. Native AOT produces optimized native code, and for string marshalling and registry access, the difference is negligible. The slightly larger memory footprint of the .NET runtime doesn’t matter in a long-running VS Code extension process.

But the bit that caught my attention was this: they noted that with Native AOT producing shared libraries that load directly into the Node.js process, they could potentially host more .NET logic in-process, avoiding the serialization and process-management overhead of their current pipe-based approach. That’s a longer-term exploration, but the foundation is now in place.

Why I think this is interesting beyond VS Code extensions

We often talk about Native AOT in the context of serverless cold starts or embedded scenarios. This is a different angle: using Native AOT to bridge .NET into ecosystems that traditionally required C or C++. Any environment that can load a native shared library — Electron apps, Python extensions via ctypes, Rust via FFI, Node.js via N-API — is now a potential host for C# code.

For .NET developers who’ve been eyeing some interop scenario but didn’t want to learn a C++ build system, this pattern is worth knowing. Write your logic in C#, expose it with [UnmanagedCallersOnly], compile with PublishAot, and load it from wherever you need it.

Wrapping up

The C# Dev Kit team replaced Python/C++ overhead with clean C# code that everyone on the team already knows how to write and debug. The approach is not complicated once you see it, and it’s a great example of Native AOT solving a real problem that doesn’t get talked about enough.

If you want the full walkthrough with all the string marshalling helpers, check the original post on the .NET blog. There’s also node-api-dotnet if you need a higher-level framework for more complex scenarios.

Native AOT | The .NET Blog

.NET 10 Ships with Ubuntu 26.04 LTS — Here's What's New

Install .NET 10 in two commands

Try it immediately

Containers: update -noble to -resolute

Native AOT: 3ms startup, 1.4MB binary

What changed in Ubuntu 26.04 that affects .NET

Need .NET 8 or 9?

Wrapping up

Writing Node.js Native Addons in C# with .NET Native AOT

The basic idea

The project setup

Exporting the entry point

Resolving N-API against the host process

What an actual exported function looks like

Calling it from TypeScript

What they gained

Why I think this is interesting beyond VS Code extensions

Wrapping up

Containers: update `-noble` to `-resolute`