Update and fix issues around xdocument get attribute - #367
Merged
Conversation
…rder-agnostic
DotnetNugetHelper.GetAllPackageReferences looked up PackageReference
elements with Descendants("PackageReference"), a namespace-qualified
lookup. Any project file declaring the legacy MSBuild namespace
(<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">)
therefore yielded zero package references instead of its actual ones.
Element and attribute lookups now match on local name, so both
SDK-style and legacy-namespace files are handled.
The same method also rejected content with a leading blank line or
indentation, throwing DataException("Expect xml content") for perfectly
valid XML. Leading whitespace is now trimmed before the guard, matching
what VisualStudioSolutionFileHelper.TryParseSlnx already does. Genuinely
non-XML input still throws.
DotnetCsProjFileHelper resolved the project SDK through
XElement.FirstAttribute, which is only the Sdk attribute when it happens
to be written first. Both an attribute ordered ahead of it
(<Project ToolsVersion="15.0" Sdk="Microsoft.NET.Sdk">) and an xmlns
declaration - which LINQ to XML also exposes as an attribute - made
every SDK comparison fail and GetProjectType silently return
DotnetProjectType.None. The Sdk attribute is now looked up by name via
GetSdk/IsSdk. A missing Sdk attribute is still treated as
not disqualifying, preserving the previous semantics.
…n-US for the test runner
perkops
approved these changes
Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Dependency refresh (including a major bump of ICSharpCode.Decompiler), a fix in Atc.DotNet for parsing project files with the legacy MSBuild namespace, and hardening of culture-sensitive unit tests so they no longer depend on the developer's Windows regional settings.
fix(Atc.DotNet): project file parsing
DotnetCsProjFileHelper and DotnetNugetHelper relied on exact XName matching when reading elements/attributes (e.g. Sdk on and package-reference metadata). That fails for project files declaring the legacy MSBuild namespace (http://schemas.microsoft.com/developer/msbuild/2003) and was sensitive to attribute ordering.
chore(deps): NuGet updates
fix(Atc.XUnit): adapt to ICSharpCode.Decompiler 11
Compile-time changes:
Behavioral regression (found via failing CodeComplianceTests):
test: make culture-sensitive tests OS-settings agnostic
new CultureInfo(lcid) applies the user's Windows regional overrides whenever the requested culture matches the OS culture. On a machine with a customized en-GB format this changed the long-date pattern from dddd, d MMMM yyyy to dd MMMM yyyy, breaking several date tests locally while passing in CI.
All culture-sensitive tests now use new CultureInfo(lcid, useUserOverride: false):
The CultureInfo JSON converter tests are unchanged — they assert on the CultureInfo object, not on formatting.