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

[ITaluone]

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]

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.