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

[dennisdoomen]

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?

Let's collect those issues and then decide which ones are common enough to fix. I'd like the migration to be as smooth for as many people possible.

That being said, this original issue is a very common one.

[ChrisonSimtian]

Do we seek a 100% conversion of every potential mis-configuration
I think we'll go 80/20 here, 80% of the scenarios will be easy to cover and 20% will be either unknown or way too hard. People can migrate the 20% by hand in those rare circumstances.

I like Dennis approach, lets collect those issues and decide how much of an edgecase it is. if its worth it and easy, lets do it.

Long term? I am tempted to say, lets also help people to migrate/upgrade between major versions (if we know we break something we might as well offer guidance on how to migrate no?)

I hope that brought some light into it?

[IT-VBFK]

Long term? I am tempted to say, lets also help people to migrate/upgrade between major versions (if we know we break something we might as well offer guidance on how to migrate no?)

I like this one actually :)