Bump System.IO.Abstractions from 12.2.19 to 12.2.21 - #46

…differs

A top-level definition spelled with character references (2.0.0) was
rewritten to the same value, and the edit check then rejected it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…differs

A top-level definition spelled with character references (2.0.0) was
rewritten to the same value, and the edit check then rejected it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

PackageVersionMarkup.ReplaceVersion located PackageVersion,
GlobalPackageReference and PackageReference elements with regular
expressions. dotnet-outdated#783 made those expressions handle multi-line elements,
but regex still isn't an XML parser, and it gets valid MSBuild wrong:

- A version written as a <Version> child element, which MSBuild
  accepts like any item metadata, was never found. With --no-restore
  a central package upgrade failed, and an imported
  Directory.Build.props entry couldn't be upgraded at all.
- A package id containing an entity reference (Include="A&dotnet-outdated#46;B")
  didn't match, because the regex compared the raw text.

Locate the elements with XmlReader instead, which decodes entities and
never mistakes comments, CDATA or escaped text for markup, and use its
line information to replace only the version text in the original
string, so the file's layout is kept byte-for-byte (an XDocument save
would reserialize the whole document). Content that isn't well-formed
XML is left unchanged and reported as unmatched.

This covers every caller of ReplaceVersion: central package updates
with --no-restore, the Directory.Packages.props formatting replay after
dotnet add package, GlobalPackageReference updates and imported
PackageReference updates. Restoring variable references
(ReplacePackageVersion) and property edits still use regex.

Refs: dotnet-outdated#561
Refs: dotnet-outdated#301
Refs: dotnet-outdated#602
Refs: dotnet-outdated#316

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dotnet-outdated finds the version to change in Directory.Packages.props,
and the other files it edits directly, with regular expressions. Regex
can't parse XML, so some valid files are silently not updated, or the
upgrade fails with a confusing error. dotnet-outdated#602 was one case: entries spread
over several lines weren't updated. dotnet-outdated#783 fixed that by making the regex
cleverer, but valid MSBuild still defeats it:

- A version written as a <Version> child element, which MSBuild accepts
  like any other item metadata, is never found. Upgrading a central
  package with --no-restore fails, and a Directory.Build.props entry
  can't be upgraded at all.
- A package id containing an XML entity reference (Include="A&dotnet-outdated#46;B")
  doesn't match, because the regex compares the raw text.

Each such case would need another regex special case, and there will
always be another:
https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454

Instead, find the elements with an XML parser (XmlReader), which
understands the file the way MSBuild does, and use its line and column
information to replace only the version text, so the rest of the file
stays byte-for-byte identical. (Loading and saving with XDocument would
reformat the whole file.) A file that isn't well-formed XML is left
unchanged and reported as not updated.

This covers every place that changes a version this way: central
package updates with --no-restore, putting back the
Directory.Packages.props layout after `dotnet add package`,
GlobalPackageReference updates, and the Directory.Build.props updates
from the previous commit. Restoring $(Variable) references
(ReplacePackageVersion) and editing properties still use regex; they're
the next candidates.

One upstream test asserted the old limitation: it used a <Version> child
element as its example of an entry that can't be updated. It now uses
an entry with no version at all.

Refs: dotnet-outdated#561
Refs: dotnet-outdated#301
Refs: dotnet-outdated#602
Refs: dotnet-outdated#316

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The next commit replaces the regular expressions that find a package's
version with an XML parser. These are the valid MSBuild files the
regexes get wrong:

- A version written as a `<Version>` child element, which MSBuild
  accepts like any other item metadata, isn't found. A
  Directory.Build.props entry written that way can't be upgraded, and
  nor can a central package with `--no-restore`; upstream's
  `CpmProjectWithNoRestore_UnmatchedEntry_ReportsFailureAndLeavesFileUnchanged`
  test already shows the latter.
- A package id containing an XML entity reference (`Include="A&dotnet-outdated#46;B"`)
  doesn't match, because the regex compares the raw text.

Pin those failures down with characterization tests. The next commit
flips their assertions, so its diff shows the behaviour before and
after. Asserting the bugs, rather than adding tests that fail until the
fix lands, avoids a commit with failing tests, so every commit passes
and `git bisect` keeps working.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Some upgrades write the new version into a file directly rather than
through `dotnet add package`: central package versions in
Directory.Packages.props, `GlobalPackageReference` items, and, since the
dotnet-outdated#301 fix, versions in Directory.Build.props. dotnet-outdated finds the
version to change in those files with regular expressions.

Regex can't reliably parse XML. dotnet-outdated#602 was one case: entries spread over
several lines weren't updated. dotnet-outdated#783 fixed that by making the regex
cleverer, but valid MSBuild still defeats it:

- A version written as a `<Version>` child element, which MSBuild
  accepts like any other item metadata, is never found. Upgrading a
  central package with `--no-restore` fails, and a Directory.Build.props
  entry can't be upgraded at all.
- A package id containing an XML entity reference (`Include="A&dotnet-outdated#46;B"`)
  doesn't match, because the regex compares the raw text.

Each such case would need another regex special case, and there will
always be another:
https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454

Instead, find the elements with an XML parser (`XmlReader`), which can
correctly parse the `.props` xml files, and use its line and column
information to replace only the version text, so the rest of the file
stays byte-for-byte identical. (Loading and saving with `XDocument`
would reformat the whole file.) A file that isn't well-formed XML is
left unchanged and reported as not updated.

No existing library fits for editing .csproj and .props files:

- Microsoft.Build, the MSBuild API, is the "correct" editor and resolves
  import precedence, but needs Microsoft.Build.Locator plus a bound SDK
  toolset: a heavy, fragile dependency for a global tool and a departure
  from this project, which otherwise shells out to `dotnet` and reads
  NuGet libraries.
  https://www.nuget.org/packages/Microsoft.Build
  https://www.nuget.org/packages/Microsoft.Build.Locator
- FubuCsProjFile: dead since 2015, .NET Framework only.
  https://www.nuget.org/packages/FubuCsProjFile
- PackageReferenceEditor: unmaintained since 2021, and pulls in the
  ReactiveUI UI framework.
  https://www.nuget.org/packages/PackageReferenceEditor
  https://www.nuget.org/packages/ReactiveUI
- MvsSln: healthy, but depends on Microsoft.Build and is
  solution-oriented.
  https://www.nuget.org/packages/MvsSln
- SunamoCsproj: missing license text, unclear if it does what we need
  https://www.nuget.org/packages/SunamoCsproj

This covers every place that changes a version this way: central package
updates with `--no-restore`, putting back the Directory.Packages.props
layout after `dotnet add package`, `GlobalPackageReference` updates, and
the Directory.Build.props updates from the dotnet-outdated#301 fix. Restoring
`$(Variable)` references (`ReplacePackageVersion`) and editing
properties still use regex; the next two commits move them onto the XML
reader too.

The characterization tests from the previous commit now expect these
versions to be found and updated.

One upstream test asserted the old limitation: it used a `<Version>`
child element as its example of an entry that can't be updated. It now
uses an entry with no version at all.

Refs: dotnet-outdated#561
Refs: dotnet-outdated#301
Refs: dotnet-outdated#602
Refs: dotnet-outdated#316

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… regexes

Two kinds of edit still find elements with regular expressions:

- Restoring a `$(Variable)` reference after an upgrade
  (`ReplacePackageVersion`).
- Editing properties (`ReplacePropertyValueAt`, `InsertProperty`,
  `InsertPropertyBefore`).

These are the valid MSBuild files they get wrong:

- A `</PropertyGroup>` inside a comment ends the group early. The
  definition or anchor after it isn't found, and `InsertProperty` puts
  the new property inside the comment.
- A package id containing an XML entity reference (`Include="A&dotnet-outdated#46;B"`)
  doesn't match, because the regex compares the raw text.
- A commented-out closing tag inside a property's value, as in
  `<AVersion>1.0.0<!-- </AVersion> --></AVersion>`, makes the edit
  change the wrong text, so the upgrade is refused with a warning.
  Upstream's
  `KnownDefinition_EditWouldChangeOtherDefinitions_DoesNothing` test
  already shows this.

Pin those failures down with characterization tests. The next commit
flips their assertions, so its diff shows the behaviour before and
after. Asserting the bugs, rather than adding tests that fail until the
fix lands, avoids a commit with failing tests, so every commit passes
and `git bisect` keeps working.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`ProjectSdkReferenceHelper` finds a project's SDKs by reading the file
as XML (`GetDeclarations`), but updates their versions by finding the
tags with regular expressions (`TryUpdate`). The two disagree on valid
MSBuild:

- An entity reference in the SDK's name or version, such as
  `Name="X&dotnet-outdated#46;Sdk"` or `Version="1&dotnet-outdated#46;0&dotnet-outdated#46;0"`, is decoded by
  discovery, so the SDK is found and reported when a newer version
  exists. The update compares the raw text, finds nothing to change and
  returns false, and `DotNetPackageService.UpdateProjectSdk` then fails
  with "Failed to update the version of SDK".
- Only an `<Sdk>` element directly under `<Project>` declares an SDK,
  and discovery ignores one anywhere else, such as an `Sdk` item in an
  `ItemGroup`. The update rewrites that item's `Version` anyway.

These files are unlikely in practice. The tests are here to show that
the regexes have edge cases they don't handle, and that an XML parser
makes dotnet-outdated more robust against XML structured in ways it
doesn't expect. XML is not a regular language, so regular expressions
can't parse it.

Pin those failures down with characterization tests. The next commit
flips their assertions, so its diff shows the behaviour before and
after. Asserting the bugs, rather than adding tests that fail until the
fix lands, avoids a commit with failing tests, so every commit passes
and `git bisect` keeps working.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The next commit replaces the regular expressions that find a package's
version with an XML parser. These are the valid MSBuild files the
regexes get wrong:

- A version written as a `<Version>` child element, which MSBuild
  accepts like any other item metadata, isn't found. A
  Directory.Build.props entry written that way can't be upgraded, and
  nor can a central package with `--no-restore`; upstream's
  `CpmProjectWithNoRestore_UnmatchedEntry_ReportsFailureAndLeavesFileUnchanged`
  test already shows the latter.
- A package id containing an XML entity reference (`Include="A&dotnet-outdated#46;B"`)
  doesn't match, because the regex compares the raw text.

Pin those failures down with characterization tests. The next commit
flips their assertions, so its diff shows the behaviour before and
after. Asserting the bugs, rather than adding tests that fail until the
fix lands, avoids a commit with failing tests, so every commit passes
and `git bisect` keeps working.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Some upgrades write the new version into a file directly rather than
through `dotnet add package`: central package versions in
Directory.Packages.props, `GlobalPackageReference` items, and, since the
dotnet-outdated#301 fix, versions in Directory.Build.props. dotnet-outdated finds the
version to change in those files with regular expressions.

Regex can't reliably parse XML. dotnet-outdated#602 was one case: entries spread over
several lines weren't updated. dotnet-outdated#783 fixed that by making the regex
cleverer, but valid MSBuild still defeats it:

- A version written as a `<Version>` child element, which MSBuild
  accepts like any other item metadata, is never found. Upgrading a
  central package with `--no-restore` fails, and a Directory.Build.props
  entry can't be upgraded at all.
- A package id containing an XML entity reference (`Include="A&dotnet-outdated#46;B"`)
  doesn't match, because the regex compares the raw text.

Each such case would need another regex special case, and there will
always be another:
https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454

Instead, find the elements with an XML parser (`XmlReader`), which can
correctly parse the `.props` xml files, and use its line and column
information to replace only the version text, so the rest of the file
stays byte-for-byte identical. (Loading and saving with `XDocument`
would reformat the whole file.) A file that isn't well-formed XML is
left unchanged and reported as not updated.

No existing library fits for editing .csproj and .props files:

- Microsoft.Build, the MSBuild API, is the "correct" editor and resolves
  import precedence, but needs Microsoft.Build.Locator plus a bound SDK
  toolset: a heavy, fragile dependency for a global tool and a departure
  from this project, which otherwise shells out to `dotnet` and reads
  NuGet libraries.
  https://www.nuget.org/packages/Microsoft.Build
  https://www.nuget.org/packages/Microsoft.Build.Locator
- FubuCsProjFile: dead since 2015, .NET Framework only.
  https://www.nuget.org/packages/FubuCsProjFile
- PackageReferenceEditor: unmaintained since 2021, and pulls in the
  ReactiveUI UI framework.
  https://www.nuget.org/packages/PackageReferenceEditor
  https://www.nuget.org/packages/ReactiveUI
- MvsSln: healthy, but depends on Microsoft.Build and is
  solution-oriented.
  https://www.nuget.org/packages/MvsSln
- SunamoCsproj: missing license text, unclear if it does what we need
  https://www.nuget.org/packages/SunamoCsproj

This covers every place that changes a version this way: central package
updates with `--no-restore`, putting back the Directory.Packages.props
layout after `dotnet add package`, `GlobalPackageReference` updates, and
the Directory.Build.props updates from the dotnet-outdated#301 fix. Restoring
`$(Variable)` references (`ReplacePackageVersion`) and editing
properties still use regex; the next two commits move them onto the XML
reader too.

The characterization tests from the previous commit now expect these
versions to be found and updated.

One upstream test asserted the old limitation: it used a `<Version>`
child element as its example of an entry that can't be updated. It now
uses an entry with no version at all.

Refs: dotnet-outdated#561
Refs: dotnet-outdated#301
Refs: dotnet-outdated#602
Refs: dotnet-outdated#316

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… regexes

Two kinds of edit still find elements with regular expressions:

- Restoring a `$(Variable)` reference after an upgrade
  (`ReplacePackageVersion`).
- Editing properties (`ReplacePropertyValueAt`, `InsertProperty`,
  `InsertPropertyBefore`).

These are the valid MSBuild files they get wrong:

- A `</PropertyGroup>` inside a comment ends the group early. The
  definition or anchor after it isn't found, and `InsertProperty` puts
  the new property inside the comment.
- A package id containing an XML entity reference (`Include="A&dotnet-outdated#46;B"`)
  doesn't match, because the regex compares the raw text.
- A commented-out closing tag inside a property's value, as in
  `<AVersion>1.0.0<!-- </AVersion> --></AVersion>`, makes the edit
  change the wrong text, so the upgrade is refused with a warning.
  Upstream's
  `KnownDefinition_EditWouldChangeOtherDefinitions_DoesNothing` test
  already shows this.

Pin those failures down with characterization tests. The next commit
flips their assertions, so its diff shows the behaviour before and
after. Asserting the bugs, rather than adding tests that fail until the
fix lands, avoids a commit with failing tests, so every commit passes
and `git bisect` keeps working.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`ProjectSdkReferenceHelper` finds a project's SDKs by reading the file
as XML (`GetDeclarations`), but updates their versions by finding the
tags with regular expressions (`TryUpdate`). The two disagree on valid
MSBuild:

- An entity reference in the SDK's name or version, such as
  `Name="X&dotnet-outdated#46;Sdk"` or `Version="1&dotnet-outdated#46;0&dotnet-outdated#46;0"`, is decoded by
  discovery, so the SDK is found and reported when a newer version
  exists. The update compares the raw text, finds nothing to change and
  returns false, and `DotNetPackageService.UpdateProjectSdk` then fails
  with "Failed to update the version of SDK".
- Only an `<Sdk>` element directly under `<Project>` declares an SDK,
  and discovery ignores one anywhere else, such as an `Sdk` item in an
  `ItemGroup`. The update rewrites that item's `Version` anyway.

These files are unlikely in practice. The tests are here to show that
the regexes have edge cases they don't handle, and that an XML parser
makes dotnet-outdated more robust against XML structured in ways it
doesn't expect. XML is not a regular language, so regular expressions
can't parse it.

Pin those failures down with characterization tests. The next commit
flips their assertions, so its diff shows the behaviour before and
after. Asserting the bugs, rather than adding tests that fail until the
fix lands, avoids a commit with failing tests, so every commit passes
and `git bisect` keeps working.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>