Recognizes version variables and updates the version accordingly

[IT-VBFK]

Summary

Update Fallout.Migrate so that package versions referenced through MSBuild properties are migrated to the target Fallout version.

Previously, the .csproj rewriter handled package references with literal versions:

<PackageReference Include="Nuke.Common" Version="10.3.49" />

However, projects that shared a version through an MSBuild property were only partially migrated:

<PropertyGroup>
  <NukeVersion>10.3.49</NukeVersion>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="Nuke.Common" Version="$(NukeVersion)" />
  <PackageReference Include="Nuke.Components" Version="$(NukeVersion)" />
</ItemGroup>

The package IDs could be renamed to Fallout.*, while the property and its value remained on the old NUKE version.

This left the migrated project in an inconsistent state and could cause package restore or build failures.

Closes #477.

What changed

Distinguish literal versions from property-based versions

The inline package-version rewrite now excludes version values beginning with an MSBuild property expression such as:

Version="$(NukeVersion)"

This prevents the existing literal-version rewrite from replacing the property reference itself with an inline version.

Property-based version management therefore remains property-based after migration.

For example:

<PackageReference Include="Nuke.Common" Version="$(NukeVersion)" />

is processed by the property-aware migration flow instead of being flattened into:

<PackageReference Include="Fallout.Common" Version="11.0.0" />

Detect version properties used by package references

A new rewrite pass discovers MSBuild properties referenced by PackageReference version attributes:

<PackageReference Include="Nuke.Common" Version="$(PropertyName)" />

The referenced property names are deduplicated and used to locate the corresponding property elements in the project file.

Update referenced property values

For each discovered version property, the rewriter updates its value to the requested Fallout version.

A NUKE-specific version property is migrated completely.

Before:

<PropertyGroup>
  <NukeVersion>10.3.49</NukeVersion>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="Nuke.Common" Version="$(NukeVersion)" />
  <PackageReference Include="Nuke.Components" Version="$(NukeVersion)" />
</ItemGroup>

After:

<PropertyGroup>
  <FalloutVersion>11.0.0</FalloutVersion>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="Fallout.Common" Version="$(FalloutVersion)" />
  <PackageReference Include="Fallout.Components" Version="$(FalloutVersion)" />
</ItemGroup>

The existing MSBuild-property migration renames NukeVersion to FalloutVersion, while the new rewrite updates the property's value.

Preserve custom property names

Projects are not required to name their shared version property NukeVersion.

When a custom property is used, its name is preserved and only its value is updated.

Before:

<PropertyGroup>
  <CiProjectVersion>10.3.49</CiProjectVersion>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="Nuke.Common" Version="$(CiProjectVersion)" />
</ItemGroup>

After:

<PropertyGroup>
  <CiProjectVersion>11.0.0</CiProjectVersion>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="Fallout.Common" Version="$(CiProjectVersion)" />
</ItemGroup>

This keeps the project's existing version-management structure intact while ensuring that migrated Fallout packages use the correct version.

Leave unrelated properties untouched

Only properties referenced by a PackageReference version attribute are selected for updating.

Other version-like properties in the same project are left unchanged, avoiding broad replacements based solely on property names or values.

Migration behavior

Input	Result
Literal package version	Package ID and inline version are updated
Package version using $(NukeVersion)	Property and references are renamed to FalloutVersion, and the property value is updated
Package version using a custom property	The property name is preserved and its value is updated
Unreferenced property	Left unchanged
Unrelated package reference	Left unchanged

Tests

Added regression coverage for the scenarios reported in #477:

• A shared NukeVersion property is renamed to FalloutVersion.
• All package references using $(NukeVersion) are updated to use $(FalloutVersion).
• The renamed property receives the requested Fallout version.
• An arbitrary shared version property keeps its original name while its value is updated.
• An unrelated, unreferenced property remains unchanged.
• Multiple NUKE package references sharing the same property are migrated consistently.

Result

Running fallout-migrate now produces a consistent .csproj for projects that manage NUKE package versions through MSBuild properties.

Both the package references and the property supplying their version are migrated automatically, without requiring users to manually repair the project afterward.

🤖 helped out here :D

[Copilot]

Pull request overview

Updates Fallout.Migrate’s .csproj rewrite logic to handle projects that pin Fallout/Nuke package versions via MSBuild properties (e.g., Version="$(NukeVersion)"), aligning with issue #477’s migration expectations.

Changes:

• Refines the “inline literal version” rewrite to avoid consuming Version="$(...)" so variable-based versions can be handled separately.
• Adds a new pass that discovers version variables used by PackageReferences and bumps the corresponding property values to the target Fallout version.
• Extends specs to cover NukeVersion → FalloutVersion renaming and arbitrary version-variable bumping behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/Fallout.Migrate/CsprojRewriter.cs	Adds variable-aware version handling and bumps property-based versions to the target Fallout version.
tests/Fallout.Migrate.Specs/CsprojRewriterSpecs.cs	Adds/adjusts specs to validate migration behavior for version variables.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ITaluone]

@copilot review

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[ITaluone]

Do not merge, please (meaning now).

I rebase the commits later to better commits :)

[IT-VBFK]

Cool
Will do so

I couldn't imagine how far your migration refactoring could go 😂😂

[dennisdoomen]

Nice improvement with a little bit of rework

[dennisdoomen]

Grouped review: three related findings on the new property-variable bump logic.

[IT-VBFK]

Ok.. as I can see this is more or less the version like before, except the verify conversion

[ITaluone]

Can we move forward on that one?

And: can this go into 10.4?

[dennisdoomen]

Can we move forward on that one?

You've marked some of my (and my AI friend's) comments as resolved, but didn't answer nor fix anything. I've reopened those.

[ITaluone]

Can we move forward on that one?

You've marked some of my (and my AI friend's) comments as resolved, but didn't answer nor fix anything. I've reopened those.

Sorry that this went like that..

Added a new test case for the non-PropertyGroup case, and added whitespaces to the version property tags.

[ChrisonSimtian]

im a bit lost with this one @IT-VBFK is this ready for review now? if we wanna get this in into 10.4 I'd say lets try to get this merged in the next few days :-)

[IT-VBFK]

Yes
Ready for review