Repository navigation
Fallout.Migrate: Also recognize csproj variables #477
Description
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
Activity
ChrisonSimtian commentedon Jul 12, 2026
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 commentedon Jul 12, 2026
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 commentedon Jul 19, 2026
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:
What do we want to achieve with the migration? Do we seek a 100% conversion of every potential mis-configuration (like unordered
PackageReferenceattributes,...) 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 commentedon Jul 20, 2026
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 commentedon Jul 20, 2026
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 commentedon Jul 20, 2026
I like this one actually :)