Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Breaking change]: Microsoft.Extensions.Hosting ContentRootPath no longer uses CWD when C:\Windows\system32 #29945

Closed
1 of 2 tasks
eerhardt opened this issue Jun 20, 2022 · 0 comments · Fixed by #29971
Closed
1 of 2 tasks
Assignees
Labels
binary incompatible Existing binaries may encounter a breaking change in behavior. breaking-change Indicates a .NET Core breaking change 🏁 Release: .NET 7 Work items for the .NET 7 release

Comments

@eerhardt
Copy link
Member

eerhardt commented Jun 20, 2022

Description

IHostEnvironment.ContentRootPath is the default directory where appsettings.json and other content files are loaded in a hosted application, including ASP.NET apps. This value defaults to Environment.CurrentDirectory, the current working directory of the application. This allows the same app to be executed under different working directories and use the content from each directory.

When a Windows process (either application or service) is launched without specifying a working directory, the working directory of the process that created it is used. See CreateProcess. When the process is launched by Windows Shell or services.exe, the current directory is set to %windir%\system32 or the "System" special folder. This is because that is the current directory of the Windows Shell and services.exe processes.

This behavior is confusing and causes hosted applications to fail when the ContentRootPath is %windir%\system32 because the application tries loading files from that directory, which do not exist. For example, the appsettings.json file is not found at runtime and the settings aren't applied.

Starting with .NET 7 Preview 6, when a hosted application is launched with the current directory set to the "System" special folder, it defaults the ContentRootPath to AppContext.BaseDirectory.

See dotnet/runtime#68580 (comment) for the full context.

Version

.NET 7 Preview 6

Previous behavior

Host.CreateDefaultBuilder defaulted the ContentRootPath to Environment.CurrentDirectory regardless of the value of the current directory.

New behavior

Host.CreateDefaultBuilder will no longer default the ContentRootPath property to the current directory if it is the System special folder on Windows. Instead the base directory of the application is used.

Type of breaking change

  • Binary incompatible: Existing binaries may encounter a breaking change in behavior, such as failure to load/execute or different run-time behavior.
  • Source incompatible: Source code may encounter a breaking change in behavior when targeting the new runtime/component/SDK, such as compile errors or different run-time behavior.

Reason for change

App developers were not expecting the ContentRootPath to be C:\Windows\system32 when their application was launched by Windows in certain cases (for example when the app was packaged as an MSIX or started by the Start Menu). In these cases it was better to default the ContentRootPath to be the base directory of the application.

Recommended action

If you want to use the previous behavior, you can set the ContentRootPath explicitly when creating the IHostBuilder:

Host
    .CreateDefaultBuilder()
    .UseContentRoot(Environment.CurrentDirectory)
    ....

Feature area

Core .NET libraries, Extensions

Affected APIs

https://docs.microsoft.com/dotnet/api/microsoft.extensions.hosting.host.createdefaultbuilder - all overloads

@eerhardt eerhardt changed the title Microsoft.Extensions.Hosting ContentRootPath no longer uses CWD when C:\Windows\system32 [Breaking change]: Microsoft.Extensions.Hosting ContentRootPath no longer uses CWD when C:\Windows\system32 Jun 20, 2022
@eerhardt eerhardt added doc-idea breaking-change Indicates a .NET Core breaking change labels Jun 20, 2022
@PRMerger9 PRMerger9 added the Pri3 label Jun 20, 2022
@dotnet-bot dotnet-bot added ⌚ Not Triaged Not triaged 🏁 Release: .NET 7 Work items for the .NET 7 release binary incompatible Existing binaries may encounter a breaking change in behavior. labels Jun 20, 2022
@gewarren gewarren removed the ⌚ Not Triaged Not triaged label Jun 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
binary incompatible Existing binaries may encounter a breaking change in behavior. breaking-change Indicates a .NET Core breaking change 🏁 Release: .NET 7 Work items for the .NET 7 release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants