Pin NuGet.Framework for .NET SDK 10.0.400; auto-remove 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. -->
<PackageReferenceInclude="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..