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 :)

[ITaluone]

@avidenic Can you do the final review.. mine isn't worth it (person from IT-VBFK == ITaluone) ;)

[dennisdoomen]

As I'm cleaning up the migration, please wait with the merge after which I've taken a look.

[avidenic]

Good improvements, some small issues to look at. Some should probably go into follow up issues / PRs. Or we can decide we're fine and just add docs about gaps.

[avidenic]

Substantial improvements. There are still some decisions to be made though.

[dennisdoomen]

I'd like to up our game here, even for our migration code, as that is going to be existing for years to come. So I'm going to be a bit more critical on the code review level. Don't get me wrong. We love all these contributions, but Nuke's code hasn't been particularly well factored and documented. So bear with me.

🔧 The PRs should explain what they are trying to do. Just a reference to an old (potentially convoluted) Nuke issue isn't enough anymore.
📝 The new code in this PR is IMO too long, too cryptic and has too little documentation.

[IT-VBFK]

Ok.. I propose to start over with small focused steps

Ok @dennisdoomen?

[dennisdoomen]

Ok.. I propose to start over with small focused steps

Yeah, and base it on #507

[IT-VBFK]

Cool
Will do so

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