Fallout.Migrate: Also recognize csproj variables

[IT-VBFK]

Description

When doing fallout-migrate on a project which does have mulitple Fallout.* packages installed, and using a shared variable for the version, like:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <RootNamespace></RootNamespace>
    <NoWarn>CS0649;CS0169</NoWarn>
    <FalloutRootDirectory>..\</FalloutRootDirectory>
    <FalloutScriptDirectory>..\</FalloutScriptDirectory>
    <NukeVersion>10.3.49</NukeVersion >
    <FalloutTelemetryVersion>1</FalloutTelemetryVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageDownload Include="GitVersion.Tool" Version="[6.5.1]" />
    <PackageDownload Include="ReportGenerator" Version="[5.5.0]" />
    <PackageDownload Include="xunit.runner.console" Version="[2.9.2]" />
    <PackageReference Include="LibGit2Sharp" Version="0.31.0" />
    <PackageReference Include="Nuke.Common" Version="$(NukeVersion)" />
    <PackageReference Include="Nuke.Components" Version="$(NukeVersion)" />
    <PackageReference Include="SharpCompress" Version="0.48.0" />
    <!-- Replace the implicitly referenced version 6.12.1, which is defined by the package Fallout.Common and has known vulnerabilities, with a fixed version -->
    <PackageReference Include="Nuget.Packaging" Version="7.3.1" />
  </ItemGroup>
</Project>

Neither the variable "NukeVersion" is converted, nor the version is replaced.

Usage Example

Just doing fallout-migrate and have this automagically done

Alternative

Doing it yourself

Could you help with a pull-request?

Yes

[ChrisonSimtian]

not 100% sure whether I want to support the scenario you constructed there, reason being:
Two packages of the same major version should in theory work. The minor version is additive but that would be resolved via the version requirements within the packages (i.e. nuget handles it)
Last but not least, patch versions should be perfectly fine. No need to version bump the whole set if we only fix something on one end.

Anyway, its a regex enhancement and I'm quite happy for you to have a go at that :-)

[IT-VBFK]

thanks :)

Reason for this change was: i currently switched one project to Fallout where this exact issue applied.. And migrate leaving a non-compilable project behind..
So: easy fix -> let's fix it ;)

[IT-VBFK]

Hi @dennisdoomen @ChrisonSimtian @avidenic

Before I start over with the replacement PR for #478 (because of extended scope of the PR and a few more or less unrelated changes mangled into this PR), I would like to discuss the scope first.

My initial intention only was to upgrade versions referenced by a MSBuild variable. Nothing more, nothing less.

But PR reviews had a few insights of what would be cool fixing as well, like:

• composed version strings
• not touching unrelated msbuild variables
• not renaming msbuild variables (which are referenced by NUKE packages, but not named like NukeVersion)
• etc. pp.

What do we want to achieve with the migration? Do we seek a 100% conversion of every potential mis-configuration (like unordered PackageReference attributes,...) and incompatibility in consumer project (which can be quite extensive, btw), or do we seek a "good enough" solutions and leave to migrate oddities at the users?

Edit: #478 now is focussed only on this one use case