Enable NuGet package validation

[oschwald]

What

Enable NuGet package validation for MaxMind.MinFraud by adding <EnablePackageValidation>true</EnablePackageValidation> to the project, matching what MaxMind.GeoIP2 and MaxMind.Db already do.

Why

With this enabled, dotnet pack runs Microsoft.DotNet.PackageValidation, which fails the build if the package's public API is binary- or source-incompatible with the latest published release. This catches accidental breaking API changes at pack time (the release workflow already runs dotnet pack on every pull request), keeping the library consistent with the validation the other MaxMind .NET packages already have.

Summary by CodeRabbit

• Chores
  • Enabled package validation in the project configuration to improve release quality checks.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: dbc404d8-a3be-4566-b590-22fb7c86df71

📥 Commits

Reviewing files that changed from the base of the PR and between d292229 and 21a8dfc.

📒 Files selected for processing (1)

• MaxMind.MinFraud/MaxMind.MinFraud.csproj

---

📝 Walkthrough

Walkthrough

This change adds a single property, EnablePackageValidation, set to true in the main PropertyGroup of the MaxMind.MinFraud project file, enabling NuGet package validation during build.

Changes

Package Validation Config

Layer / File(s)	Summary
Enable NuGet package validation MaxMind.MinFraud/MaxMind.MinFraud.csproj	Sets EnablePackageValidation to true in the top-level PropertyGroup.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Poem

A single line, a tiny switch,
Now NuGet checks without a hitch.
Hop, hop, validate away,
This bunny's proud of build day! 🐇📦

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: enabling NuGet package validation in the MinFraud project.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch enable-package-validation

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Code Review

This pull request enables package validation in the project file. The reviewer pointed out that to validate against the latest published release, a baseline version must be specified using the PackageValidationBaselineVersion property, and a compatibility suppression file should be generated to handle intentional breaking changes in version 6.0.0.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

While setting <EnablePackageValidation>true</EnablePackageValidation> enables the compatible framework and compatible runtime validators, it does not validate the package against a previously published release unless a baseline version is specified.\n\nTo achieve the goal mentioned in the PR description ("fails the build if the package's public API is binary- or source-incompatible with the latest published release"), you need to specify the <PackageValidationBaselineVersion> property.\n\nNote that since 6.0.0 introduces several intentional breaking changes (as documented in releasenotes.md), enabling baseline validation will cause the build to fail unless you also generate a compatibility suppression file. You can generate this file by running:\n\nbash\ndotnet pack /p:GenerateCompatibilitySuppressionFile=true\n\n\nThis will create a CompatibilitySuppressions.xml file in your project directory, which should be committed to source control to document and allow these intentional breaking changes.

    <EnablePackageValidation>true</EnablePackageValidation>\n    <PackageValidationBaselineVersion>5.3.1</PackageValidationBaselineVersion>

[oschwald]

Good catch on the distinction between the compatible-framework/runtime validators and a baseline comparison against a previously published version. That's correct: this change intentionally enables only the former, matching how MaxMind.GeoIP2 is configured (it also sets EnablePackageValidation without a PackageValidationBaselineVersion).

I'm keeping this PR minimal and not adding baseline validation here, mainly because 6.0.0 (with its intentional breaking changes) hasn't been published yet, so there's no meaningful prior baseline to validate against until after that release ships. Adding PackageValidationBaselineVersion (pointed at 6.0.0 once released) plus a CompatibilitySuppressions.xml for any further intentional breaks would be a reasonable follow-up once we're validating against a real baseline.

For this PR specifically, the CI dotnet pack job (including the Windows job, where these validators run) passed, so the framework/runtime compatibility checks enabled here are already exercised and green.