[release/7.0] Do not override content root with default

[github-actions]

Backport of #79242 to release/7.0

/cc @halter73

Customer Impact

A customer reported this .NET 7 regression after noticing their ASP.NET Core application using WebApplication stopped respecting the ASPNETCORE_CONTENTROOT environment variable after upgrading. See #78583.

There is a workaround of using the DOTNET_CONTENTROOT environment variable instead, but a lot of existing documentation suggests using the ASPNETCORE_-prefix which has been supported longer than DOTNET_.

This only affects ASPNETCORE_CONTENTROOT. All other ASPNETCORE_-prefixed environment variables are respected. And this also only affects applications using WebApplication. None of the older web hosts are affected.

It might seem odd that an issue specific to ASPNETCORE_-prefixed environment variables requires a runtime fix, but that's because the mechanism that WebApplication is using to pass in this configuration (HostApplicationBuilderSettings.Configuration) incorrectly allows a manually configured content root to be overwritten by the default value which is the root cause of the bug.

Testing

I added regression tests and manually tested the fix with a ASP.NET Core application by adding a Microsoft.Extensions.Hosting 7.0.1 PackageReference with artifacts/packages/Debug/Shipping/ as a NuGet source.

Risk

Low. This is a small, targeted fix that has been well tested.

This does touch code that ships in a NuGet package. I followed the package authoring instructions, but I still need to get the package authorization changes reviewed.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #79242 to release/7.0

/cc @halter73

Customer Impact

Testing

Risk

IMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-Extensions-Hosting
Milestone:	-

[carlossanlop]

@halter73 there's a merge conflict with the base branch. Can you please address it so I can merge this?

[carlossanlop]

Approved by Tactics (7.0.3).
Signed off by area owners.
CI failure is known/unrelated/already fixed: #78778
OOB package changes added correctly.
Pending addressing merge conflict, then I can merge.

[eerhardt]

I've fixed the merge conflict. Letting CI run now to ensure it still builds. 😄

[carlossanlop]

@halter73 @eerhardt the CI failure seems related to the changes in this PR:

artifacts\bin\testPackages\projects\Microsoft.Extensions.Hosting\project.csproj(0,0): error NU1102: (NETCORE_ENGINEERING_TELEMETRY=Build) Unable to find package Microsoft.Extensions.Configuration.Binder with version (>= 7.0.2)
  - Found 1562 version(s) in dotnet7 [ Nearest version: 7.0.0-rtm.22511.4 ]
  - Found 109 version(s) in dotnet-public [ Nearest version: 7.0.1 ]
  - Found 1 version(s) in dotnet7-transport [ Nearest version: 7.0.0-rc.1.22426.10 ]
  - Found 0 version(s) in D:\a\_work\1\s\artifacts\packages\Debug\
  - Found 0 version(s) in richnav
  - Found 0 version(s) in darc-pub-dotnet-emsdk-d71ea7c
  - Found 0 version(s) in dotnet-eng
  - Found 0 version(s) in dotnet-libraries
  - Found 0 version(s) in dotnet-tools

[eerhardt]

Unable to find package Microsoft.Extensions.Configuration.Binder with version (>= 7.0.2)

@ViktorHofer - is this a libraries infrastructure problem? If we are shipping 2 OOB packages, with one depending on the other, in the same release?

[ViktorHofer]

Looking...

[ViktorHofer]

The issue here is that the previous release (7.0.2) is supposed to provide the Microsoft.Extensions.Configuration.Binder/7.0.2 version but apparently hasn't yet shipped to nuget.org. The current release (7.0.3) now already depends on that package but can't find it on nuget.org and neither in the artifacts/packages directory because the project doesn't build in this servicing release.

AFAIK we never had overlapping servicing releases in the same band (i.e. 7.0.2 and 7.0.3 at the same time). I can think of couple of workarounds to unblock the PR:

• Set GeneratePackageOnBuild to true in Microsoft.Extensions.Configuration.Binder.csproj
• Set ServicingVersion back to 7.0.1 in Microsoft.Extensions.Configuration.Binder.csproj
• Add the 7.0.2 feed to our nuget.config that points to the staged packages. That's only possible, if the feed is publicly available but would be my preferred choice as it's the only option that wouldn't need to be reverted before 7.0.3 ships.

cc @ericstj for awareness

[eerhardt]

Thanks for looking into this @ViktorHofer.

It sounds like for both the first 2 workarounds, it would take 2 changes:

1. Make the above change now, until the 7.0.2 package is released
2. Once the 7.0.2 package is released, revert the workaround before we ship 7.0.3

For the 3rd workaround, I'd be concerned about nuget caching the "staged packages" on people's machines. If someone restores this "intermediate" version before the official 7.0.2 version is shipped, they could get the non-official package cached.

I kind of think I like the 1st workaround the best, and then we make a revert before we ship 7.0.3.

[ericstj]

You might even be able to avoid reverting if we have more binder changes coming in servicing this release cc @tarekgh

One generalization here might be to change how we sequence branding changes. We could make the product version changes first, but wait to remove GeneratePackageOnBuild from libraries until the previous release is published.

[carlossanlop]

@halter73 or @eerhardt how's the fix looking?

[ViktorHofer]

You shouldn't need the above mentioned workaround anymore, given that the 7.0.2 nuget packages already got released to nuget.org

[ViktorHofer]

/azp run runtime

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[carlossanlop]

You shouldn't need the above mentioned workaround anymore, given that the 7.0.2 nuget packages already got released to nuget.org

Ok, thanks @ViktorHofer. Just to be clear, I'm still seeing the following failure in the Libraries Build windows allConfigurations x64 Debug job even after your CI re-run:

artifacts\bin\testPackages\packageTest.targets(50,5): error : (NETCORE_ENGINEERING_TELEMETRY=Build) Assembly 'Microsoft.Extensions.Hosting' has insufficient version for dependency 'System.Diagnostics.DiagnosticSource' : 7.0.0.0 < 7.0.0.1.

The rest of the CI failures are a known unrelated issue affecting Apple OSs where openssl fails to install, showing the error message:

Publishing build artifacts failed with an error: Not found PathtoPublish: /Users/runner/work/1/s/artifacts/log/

[ViktorHofer]

@ericstj can you please take a look? I think you know more about package testing.

[ericstj]

artifacts\bin\testPackages\packageTest.targets(50,5): error : (NETCORE_ENGINEERING_TELEMETRY=Build) Assembly 'Microsoft.Extensions.Hosting' has insufficient version for dependency 'System.Diagnostics.DiagnosticSource' : 7.0.0.0 < 7.0.0.1.

That indicates that Microsoft.Extensions.Hosting.dll built here is referencing System.Diagnostics.DiagnosticSource versioned 7.0.0.1, but it restored a DLL versioned 7.0.0.0.

I think that's happening because Microsoft.Extensions.Hosting uses types in DiagnosticSource but doesn't directly reference it.

It ends up getting the transitive reference to DiagnosticSource through the ProjectReference to Microsoft.Extensions.Logging including it's updated assembly version, but since Microsoft.Extensions.Logging is not being serviced it still has the GA package version. As a result, when restoring the packages they still get the GA reference to DiagnosticSource, thus the error.

To fix this can you try adding a ProjectReference to System.Diagnostics.DiagnosticSource in Microsoft.Extensions.Hosting?

[carlossanlop]

CI failures related to this PR are gone. Only a couple of timeout cancellations.
Ready to merge.