Skip to content

[release/2.3] Fix net46x test builds broken by Microsoft.Extensions.Configuration.Binder buildTransitive targets - #68144

Open
wtgodbe wants to merge 4 commits into
dotnet:release/2.3from
wtgodbe:wtgodbe/fix-net462-test-binder
Open

[release/2.3] Fix net46x test builds broken by Microsoft.Extensions.Configuration.Binder buildTransitive targets#68144
wtgodbe wants to merge 4 commits into
dotnet:release/2.3from
wtgodbe:wtgodbe/fix-net462-test-binder

Conversation

@wtgodbe

@wtgodbe wtgodbe commented Jul 31, 2026

Copy link
Copy Markdown
Member

The pinned 8.x Microsoft.Extensions.Configuration.Binder ships buildTransitive targets that use MSBuild static-method syntax (IsTargetFrameworkCompatible) unsupported by the legacy MSBuild used to build/run net46x test apps at test time. This causes MSB4186 and downstream test failures (e.g. OutOfProcessWebSite, ServerComparison.TestSites, and likely other net46x-hosted functional tests failing to launch with Win32Exception: file not found).

This excludes buildTransitive assets from that package for net461/net462-targeted projects so they keep using the pinned 8.x package (no downgrade) without hitting the parse error.

Verified locally that this approach (explicit PackageReference + ExcludeAssets="buildTransitive" for a transitively-flowed package) removes the offending targets import from the generated .nuget.g.targets, while compile/runtime assets remain unaffected.

Copilot AI review requested due to automatic review settings July 31, 2026 20:29

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR addresses .NET Framework 4.6x (net46x) test-site build failures caused by Microsoft.Extensions.Configuration.Binder 8.x buildTransitive targets using MSBuild functionality that isn’t supported by the legacy MSBuild invoked for those test builds.

Changes:

  • Adds a conditional PackageReference for Microsoft.Extensions.Configuration.Binder on net461/net462 that excludes buildTransitive assets to avoid importing the problematic targets during test-site builds.

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

Comment thread Directory.Build.targets Outdated
Comment on lines +16 to +18
<ItemGroup Condition=" '$(TargetFramework)' == 'net461' OR '$(TargetFramework)' == 'net462' ">
<PackageReference Include="Microsoft.Extensions.Configuration.Binder" Version="$(MicrosoftExtensionsConfigurationBinderPackageVersion)" ExcludeAssets="buildTransitive" PrivateAssets="all" />
</ItemGroup>
…figuration.Binder

The pinned 8.x Microsoft.Extensions.Configuration.Binder ships
buildTransitive targets using MSBuild static-method syntax
(IsTargetFrameworkCompatible) and a Roslyn source-generator analyzer,
neither of which the legacy MSBuild/Roslyn used to build/run net46x
test apps at test time supports (MSB4186 / CS8032), breaking test
apps that transitively reference Kestrel or HttpsPolicy.

Excluding these assets at the two source references (rather than on
downstream consumers) is sufficient: ExcludeAssets metadata flows
through this repo's Reference->PackageReference JoinItems resolution
and propagates correctly to all transitive project-reference
consumers, since there's no longer a conflicting unrestricted
declaration elsewhere in the graph.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@wtgodbe
wtgodbe force-pushed the wtgodbe/fix-net462-test-binder branch from 9758a2e to 79f6149 Compare July 31, 2026 21:21
…ead of NuGet asset flags

NuGet's analyzer resolution (ResolveLockFileAnalyzers/ResolvePackageAssets)
reads the package's physical file listing directly and ignores
IncludeAssets/ExcludeAssets/PrivateAssets metadata entirely, so excluding
'analyzers' on the source Reference (previous commit) had no effect -
confirmed both in a local repro and in CI, where CS8032 now appeared even
in Kestrel.Core/HttpsPolicy's own compilation.

buildTransitive exclusion on the Reference items IS honored by NuGet (kept),
but analyzers must be removed from the resolved @(Analyzer) item directly,
which is universal and toolchain-version independent.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
wtgodbe and others added 2 commits July 31, 2026 16:08
…ldWarnings

CI (build 1535387) showed the ExcludeAssets=buildTransitive Reference
metadata did not actually prevent the buildTransitive targets file from
being imported for net46x test-asset projects reached transitively via
Kestrel.Core/HttpsPolicy - MSB4186 still occurred once the analyzer fix
let the build reach the test-execution phase.

Microsoft.Extensions.Configuration.Binder's buildTransitive targets file
gates its entire TFM-compatibility-check target (the one using the
unsupported [MSBuild]::IsTargetFrameworkCompatible calls) behind
SuppressTfmSupportBuildWarnings. Setting that property globally skips the
incompatible logic outright, which is simpler and deterministic (plain
MSBuild Condition evaluation) rather than depending on NuGet asset
selection working a particular way across multi-hop P2P chains.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Test asset projects (ServerComparison.TestSites, Hosting.TestSites,
Mvc ViewCompilation test apps, IIS OutOfProcess test sites) were
retargeted from net461 to net462 in dotnet#59509, but several test files
still hardcode "net461" when launching the Clr-flavored test app via
'dotnet run --framework net461'. Since the app was only ever restored/
built for net462, this fails with NETSDK1005 (no target for net461),
which surfaces as a misleading Win32Exception (file not found) when
dotnet run's internal Process.Start can't find the never-built output.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@wtgodbe
wtgodbe requested a review from javiercn as a code owner August 1, 2026 00:17
Comment thread Directory.Build.targets
analyzer resolution ignores IncludeAssets/ExcludeAssets/PrivateAssets, so the only reliable way to suppress
it is to strip it directly from the resolved @(Analyzer) items before compilation.
-->
<Target Name="RemoveIncompatibleConfigurationBinderAnalyzer" BeforeTargets="CoreCompile">

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's generally safer to have this as BeforeTargets="BeforeCompile".

Using BeforeTargets=CoreCompile might mean that this target runs after the other target that caches the compilation input, and the cache will then incorrectly include the removed analyzer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants