Auto-remove manual NuGet.* version pins on future major versions

[ITaluone]

Removes obsolete explicit NuGet package pins from project files during migration.

What changed

• Removes versioned NuGet.Frameworks references from every *.csproj file.
• For Fallout 11 or later, also removes versioned NuGet.Protocol, NuGet.Packaging, and NuGet.Resolver references.
• Keeps those three related package pins when migrating to Fallout 10.x.
• Leaves unversioned references and unrelated packages unchanged.

Why

Fallout now aligns its NuGet dependencies with the versions loaded by the .NET SDK. Explicit project-level pins are no longer needed and can cause version conflicts. The related NuGet pins remain in place for Fallout 10.x and are removed when migrating to Fallout 11 or later.

Addresses #638 (the NuGet package workaround). Follow-up to #677 (the SDK NuGet version alignment).

[dennisdoomen]

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]

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]

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]

😆

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]

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]

Line 331-336 adds the pin with a descriptive comment

[IT-VBFK]

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]

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]

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]

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]

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]

Why would they break compilation?

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

[dennisdoomen]

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]

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

[dennisdoomen]

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.

[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]

❓🤖 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?

[ITaluone]

I think when #694 is merged this should work out of the box, doesn't it?