Auto-remove manual `NuGet.*` version pins on future major versions by ITaluone · Pull Request #666 · Fallout-build/Fallout

ITaluone · 2026-08-29T15:35:55Z

fallout-migrate now pins NuGet.Framework 7.9.0 on 10.x build projects, and removes that pin when the target Fallout major matches or moves beyond the marker.
I chose the marker version v11 because of various comments mentioning this version upgrade in that major version.

If someone feels to leave it until v12, please ping me on that one.

Changes

On Fallout 10.x, RewriteCsprojsStep inserts this block into the first ItemGroup of only the _build.csproj:

<!-- fallout-migrate:delete-at-v11:start -->
<!-- Pin the NuGet.Framework version, so .NET 10.0.400 does not cause the build to fail. -->
<PackageReference Include="NuGet.Framework" Version="7.9.0" />
<!-- fallout-migrate:delete-at-v11:end -->

The v11 in the marker is the next major after MigrationContext.FalloutVersion (the version fallout-migrate resolved for this run).
When that resolved version is already on the marker major (11), the step deletes everything from :start through :end.
A later major does not add a new pin. It only removes a block whose marker already matches.
Does nothing if the build project itself is .NETFramework (since the netstandard2.0 removage)
Does only pin on the build project itself (leaves any other .csproj alone)

Why?

.NET SDK 10.0.400 loads NuGet.Frameworks 7.9.0.0 while evaluating the build project. Without an explicit pin, MSBuild fails when calling e.g. Solution.MyProject.GetTargetFrameworks(). The pin is only needed on the 10.x line. The marker tells fallout-migrate to drop the block on v11 so consumers do not have to edit the csproj by hand.

Proposed workaround migration for #638

dennisdoomen · 2026-08-30T11:22:50Z

I'm going to park this one until we have settled on a path in #638. Also, upgrades between 10.x must always be backwards compatible and fallout-migrate is only supposed to be used between Nuke -> Fallout 10 -> Fallout 10 + 1.

IT-VBFK · 2026-08-30T13:47:03Z

Ok.. but why this shouldn't be backwards compatible? The one and only reason for this is to stay without breaking changes (or in other words: be prepared for .NET 10.0.400 SDK upgrade in consumer projects)

I did this for two projects to be able to move forward to 10.0.400.

dennisdoomen · 2026-08-31T05:27:15Z

Ok.. but why this shouldn't be backwards compatible? The one and only reason for this is to stay without breaking changes (or in other words: be prepared for .NET 10.0.400 SDK upgrade in consumer projects)

I don't understand your point. It's just that I want to make sure that we're not going to misuse fallout-migrate for fixing breaking changes in the v10 stream.

IT-VBFK · 2026-08-31T14:32:42Z

😆

Ok.. I don't get it either, because it is no breaking change in the v10 stream, but a potential breaking change (which this could prevent) in the consumer's repos when upgrading to 10.0.400..

dennisdoomen · 2026-09-19T07:44:54Z

Getting back to this PR, the way I interpret it is that it doesn't solve the problem unless people use fallout-migrate, right? Because the point of fallout-migrate is to either help move people from Nuke to Fallout, or from one major version of Fallout to the next. It is not meant to be used for minor versions as Fallout is supposed to support Semantic Versioning.

And I don't see the "pin" this PR talks about.

So can we just do what I suggested here so that people bumping the Fallout packages from 10.4 to 10.5 will get the fix automatically?

IT-VBFK · 2026-09-19T08:14:29Z

Line 331-336 adds the pin with a descriptive comment

IT-VBFK · 2026-09-19T08:15:05Z

So can we just do what I suggested #638 (comment) so that people bumping the Fallout packages from 10.4 to 10.5 will get the fix automatically?

Sure, if this works :)

dennisdoomen · 2026-09-19T09:18:00Z

Line 331-336 adds the pin with a descriptive comment

That's fallout-migrate. That will not play a role until we move to v11.

Sure, if this works :)

Why the smiley? You don't think that will work?

IT-VBFK · 2026-09-19T09:41:54Z

Hmm.. not sure.

Because of the .netstandard2.0 "burden". Otherwise, everything netstandard2.0 related here makes no sense.

dennisdoomen

Did some testing. After #677, the pin isn't necessary anymore. But we could still have this migration step to remove it when people upgrade to version 10.5 or higher. However, it needs to become a separate step. That RewriteCsprojsStep is already exploding.

ITaluone · 2026-09-21T06:45:37Z

ok.. should I also remove explicit pins for NuGet.Packaging / NuGet.Protocol / NuGet.Resolver in case anyone has this pins, since they would break the compilation after migration.

dennisdoomen · 2026-09-21T06:58:43Z

ok.. should I also remove explicit pins for NuGet.Packaging / NuGet.Protocol / NuGet.Resolver in case anyone has this pins, since they would break the compilation after migration.

Why would they break compilation?

ITaluone · 2026-09-21T07:05:07Z

Why would they break compilation?

Hmm.. true, but still unnecessary though. Remove or leave alone?

dennisdoomen · 2026-09-21T07:10:33Z

Hmm.. true, but still unnecessary though. Remove or leave alone?

If people have been adding it to work around the .NET 10.0.400 issue, it might be nice to have fallout-migrate remove it when we move to v11.

ITaluone · 2026-09-21T07:17:30Z

So, not like now, but a v11 migration only?

dennisdoomen · 2026-09-21T09:34:24Z

So, not like now, but a v11 migration only?

Yes, as the migration tool is only expected to be used to migrate from Nuke->Fallout or between major Fallout versions.

This only runs for v11 or later

dennisdoomen

🔧🤖 The PR description still describes inserting a delete-at-v11 marker block into _build.csproj, but the PR now only removes pins. Please rewrite it for the two removal steps and their version gating.

dennisdoomen · 2026-10-10T07:15:19Z

+/// </summary>
+internal sealed class RemoveNugetFrameworkPinStep : IMigrationStep
+{
+    private static readonly Regex explicitPinPattern = new(


🔧 Add a human-friendly explanation to the Regex, e.g. something like

/// <summary> /// Finds a whole line with a self-closing <c><PackageReference></c> /// for <c>NuGet.Frameworks</c> that has a <c>Version</c> attribute. /// </summary> /// <remarks> /// The match includes leading spaces, trailing spaces, and the line break. /// Replace it with an empty string to remove the line. /// The tag must be on one line and must end with <c>/></c>. /// <c>Include</c> and <c>Version</c> can appear in any order. /// Use this with <see cref="RegexOptions.Multiline"/>. /// The match is case-sensitive. /// </remarks>

dennisdoomen · 2026-10-10T07:17:37Z

+
+namespace Fallout.Migrate.Steps;
+
+/// <summary>


🔧🤖 The summary lists Framework, Protocol, Packaging and Resolver, but the regex only removes NuGet.Frameworks. Fix the text.

dennisdoomen · 2026-10-10T07:17:38Z

+        RegexOptions.Compiled | RegexOptions.Multiline);
+
+    /// <inheritdoc />
+    public Task ExecuteAsync(MigrationContext context, Summary summary)


🤔🤖 This step is not version-gated, so migrating to a Fallout version that predates the #677 fix would strip a pin that is still needed. I could not verify which version contains #677.

dennisdoomen · 2026-10-10T07:17:39Z

+    /// <inheritdoc />
+    public Task ExecuteAsync(MigrationContext context, Summary summary)
+    {
+        foreach (var path in MigrationFileOperations.EnumerateFiles(context.RootDirectory, "*.csproj"))


❓🤖 This scans every *.csproj, so a library that uses NuGet.Frameworks directly loses its reference. Is that intended, or should it only touch _build.csproj? Same for RemoveRelatedNugetPinsStep.

dennisdoomen · 2026-10-10T07:17:40Z

+/// </summary>
+internal sealed class RemoveNugetFrameworkPinStep : IMigrationStep
+{
+    private static readonly Regex explicitPinPattern = new(


❓🤖 Under central package management the pin is a <PackageVersion> in Directory.Packages.props, which neither step reads. Is that acceptable, or should it build on #694 (#694), which adds *.props support to the migration?

dennisdoomen · 2026-10-10T07:17:41Z

+        return Task.CompletedTask;
+    }
+
+    private static bool RunsFor(string version)


🔧🤖 RunsFor has no docs. Say what it returns for null or unparseable input. Same for MinimumFalloutMajor.

ITaluone requested a review from a team as a code owner August 29, 2026 15:35

dennisdoomen marked this pull request as draft August 30, 2026 11:21

dennisdoomen requested changes Sep 20, 2026

View reviewed changes

ITaluone added 2 commits September 21, 2026 08:55

Move the explicit nuget framework pin into its own step

9fd02e5

Also match for other NuGet.* packages with a non-range pin

44beaee

ITaluone force-pushed the feat/migration/add-nuget.framework-pin branch from 0750890 to 44beaee Compare September 21, 2026 06:55

ITaluone requested a review from dennisdoomen September 21, 2026 06:56

ITaluone marked this pull request as ready for review September 21, 2026 06:56

Add another migration step to remove explicit other NuGet.* packages

a7f2c17

This only runs for v11 or later

ITaluone changed the title ~~Pin NuGet.Framework for .NET SDK 10.0.400; auto-remove on future major versions~~ Auto-remove manual NuGet.* version pins on future major versions Sep 25, 2026

ChrisonSimtian assigned dennisdoomen and ITaluone Oct 8, 2026

dennisdoomen requested changes Oct 10, 2026

View reviewed changes

Conversation

ITaluone commented Aug 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Why?

Uh oh!

dennisdoomen commented Aug 30, 2026

Uh oh!

IT-VBFK commented Aug 30, 2026

Uh oh!

dennisdoomen commented Aug 31, 2026

Uh oh!

IT-VBFK commented Aug 31, 2026

Uh oh!

dennisdoomen commented Sep 19, 2026

Uh oh!

IT-VBFK commented Sep 19, 2026

Uh oh!

IT-VBFK commented Sep 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dennisdoomen commented Sep 19, 2026

Uh oh!

IT-VBFK commented Sep 19, 2026

Uh oh!

dennisdoomen left a comment

Choose a reason for hiding this comment

Uh oh!

ITaluone commented Sep 21, 2026

Uh oh!

dennisdoomen commented Sep 21, 2026

Uh oh!

ITaluone commented Sep 21, 2026

Uh oh!

dennisdoomen commented Sep 21, 2026

Uh oh!

ITaluone commented Sep 21, 2026

Uh oh!

dennisdoomen commented Sep 21, 2026

Uh oh!

dennisdoomen left a comment

Choose a reason for hiding this comment

Uh oh!

dennisdoomen Oct 10, 2026

Choose a reason for hiding this comment

Uh oh!

dennisdoomen Oct 10, 2026

Choose a reason for hiding this comment

Uh oh!

dennisdoomen Oct 10, 2026

Choose a reason for hiding this comment

Uh oh!

dennisdoomen Oct 10, 2026

Choose a reason for hiding this comment

Uh oh!

dennisdoomen Oct 10, 2026

Choose a reason for hiding this comment

Uh oh!

dennisdoomen Oct 10, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ITaluone commented Aug 29, 2026 •

edited

Loading

IT-VBFK commented Sep 19, 2026 •

edited

Loading