| id | package-selection |
|---|---|
| title | Choose the right package |
| sidebar_position | 3 |
| diataxis | explanation |
| persona | developer choosing dependencies |
import CodeBlock from '@theme/CodeBlock'; import quickStart from '!!raw-loader!../_examples/quick-start/Program.cs';
For ordinary applications, install Humanizer. That name is stable even though the package's internal layout changed across release lines.
| Documentation version | Normal install | Package shape |
|---|---|---|
2.10.1 through 3.0.10 |
Humanizer |
Metapackage that brings in Humanizer.Core and locale packages |
4.0 |
Humanizer |
Consolidated library with runtime, generated locale data, and analyzers |
The API reference for releases through 3.0.10 is generated from Humanizer.Core, because that is where the public implementation assembly lives. That does not change the normal install command.
Install Humanizer from NuGet:
dotnet add package Humanizer --version 4.0.0Then use the same Humanizer namespace regardless of package layout. This
verified program is compiled against the selected package:
{quickStart}
Choose Humanizer.Core directly only when you deliberately want the older release line's English-only core or must work around tooling that cannot restore its locale metapackage. Add only locale packages that exist for that exact release.
Do not copy Humanizer.Core.<locale> references from a historical release into
Humanizer 4. Locale packaging is version-specific, and package names are not
proof that an API is present in another release.
Package selection is a compatibility concern, not an API preference. Keep the documentation selector aligned with project.assets.json or your lock file when diagnosing restore or runtime behavior.