Skip to main content
Version: 4.0 (next)

Trimming and Native AOT

Humanizer 4's .NET 8 and newer assets publish compatibility metadata for trimming and Native AOT. Enum humanization and dehumanization are the important choice points: use generic overloads when the enum type is known at compile time, and treat the runtime Enum and Type overloads as reflection-dependent.

Example​

This executable uses generic enum APIs:

Program.cs
using System.Globalization;
using Humanizer;

CultureInfo.CurrentCulture = CultureInfo.GetCultureInfo("en-US");
CultureInfo.CurrentUICulture = CultureInfo.GetCultureInfo("en-US");

var label = JobState.ReadyToShip.Humanize();
var parsed = "READY TO SHIP".DehumanizeTo<JobState>();

Console.WriteLine($"Label: {label}");
Console.WriteLine($"Parsed: {parsed}");

enum JobState
{
    ReadyToShip
}

It prints:

Ready to ship

The generic parameter gives the trimmer and AOT compiler the enum's public fields. By contrast, DehumanizeTo(string, Type, ...) and the base-Enum Humanize(...) overloads construct generic methods through reflection and are annotated with both RequiresUnreferencedCode and RequiresDynamicCode.

Treat linker warnings as API feedback​

An IL2026 warning on a runtime enum overload means the linker cannot prove the target enum members survive. IL3050 means Native AOT cannot guarantee creation of the required code. Replacing the overload with the generic form is the normal remediation; suppressing either warning does not make the dynamic path safe.

Validate the published application​

Assembly compatibility metadata is not proof that every consumer call, dependency, target framework, and runtime identifier is safe. Keep trim warnings enabled, publish the actual application in CI, and execute a smoke path through its Humanizer calls. Reflection-heavy application code around Humanizer can still require its own annotations.