Recommended way to find content root path

[Timovzl]

I have been looking for some documentation on a way to find the content root path that works reliably: in production, from test runners, when running locally from VS, and so on.

By the content root path, I mean the place where we can find files marked with CopyToOutputDirectory. The path should be the directory where the binaries can find their top-level files marked with CopyToOutputDirectory.

All I could find were a lot of StackOverflow posts with non-definitive answers, as well as some semi-related issues on GitHub.

1. What is the recommended way?

IHostEnvironment.ContentRootPath seems to almost get it right. However, when running from Visual Studio, it points to the source project directory rather than to the bin directory. This keeps it from being the one solution that works reliably.

The simplest solution I have found so far is to manually correct IHostEnvironment.ContentRootPath from Program.cs:

// Fix ContentRootPath for runs from VS
.ConfigureWebHostDefaults(webBuilder =>
{
	webBuilder.UseContentRoot(Path.GetDirectoryName(typeof(Program).Assembly.Location));
	// Snip
}

Still, this is not exactly elegant. Is there a better way? Reliably reaching the content root path seems like a basic requirement.

2. Would it be useful to document the recommended way?

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I have been looking for some documentation on a way to find the content root path that works reliably: in production, from test runners, when running locally from VS, and so on.

By the content root path, I mean the place where we can find files marked with CopyToOutputDirectory. The path should be the directory where the binaries can find their top-level files marked with CopyToOutputDirectory.

All I could find were a lot of StackOverflow posts with non-definitive answers, as well as some semi-related issues on GitHub.

1. What is the recommended way?

IHostEnvironment.ContentRootPath seems to almost get it right. However, when running from Visual Studio, it points to the source project directory rather than to the bin directory. This keeps it from being the one solution that works reliably.

The simplest solution I have found so far is to manually correct IHostEnvironment.ContentRootPath from Program.cs:

// Fix ContentRootPath for runs from VS
.ConfigureWebHostDefaults(webBuilder =>
{
	webBuilder.UseContentRoot(Path.GetDirectoryName(typeof(Program).Assembly.Location));
	// Snip
}

Still, this is not exactly elegant. Is there a better way? Reliably reaching the content root path seems like a basic requirement.

2. Would it be useful to document the recommended way?

Author:	Timovzl
Assignees:	-
Labels:	area-Extensions-Hosting, untriaged
Milestone:	-

[eerhardt]

By the content root path, I mean the place where we can find files marked with CopyToOutputDirectory

Have you tried AppContext.BaseDirectory? https://docs.microsoft.com/en-us/dotnet/api/system.appcontext.basedirectory

See also #41341

[Timovzl]

@eerhardt I will give it a shot.

Are you not expecting AppContext.BaseDirectory to hold the same value as IHostEnvironment.ContentRootPath?

According to your comment here:

The reason this affects you is because by default the hostingContext.HostingEnvironment.ContentRootPath gets its value from AppContext.BaseDirectory.

Does this no longer apply?

[eerhardt]

Are you not expecting AppContext.BaseDirectory to hold the same value as IHostEnvironment.ContentRootPath?

See this code, which defaults the Content root to the current working directory, which is different than AppContext.BaseDirectory:

runtime/src/libraries/Microsoft.Extensions.Hosting/src/HostingHostBuilderExtensions.cs

Lines 190 to 192 in 8671908

	public static IHostBuilder ConfigureDefaults(this IHostBuilder builder, string[] args)
	{
	builder.UseContentRoot(Directory.GetCurrentDirectory());

The reason this affects you is because by default the hostingContext.HostingEnvironment.ContentRootPath gets its value from AppContext.BaseDirectory.

Does this no longer apply?

It no longer applies in .NET 5+. AppContext.BaseDirectory is only wrong for "PublishSingleFile" in .NET Core 3.x apps. We fixed that issue in 5.

[Timovzl]

@eerhardt, AppContext.BaseDirectory is working perfectly. Thanks!

I have used webBuilder.UseContentRoot(AppContext.BaseDirectory) in order to correct IHostEnvironment.ContentRootPath as well, although the state of things makes a strong case for using AppContext.BaseDirectory exclusively, and forgetting about ContentRootPath altogether.

Do you have any information on what the respective intended use of these two is, and why they differ the way they do?

[eerhardt]

https://docs.microsoft.com/en-us/dotnet/api/system.appcontext.basedirectory says:

Gets the file path of the base directory that the assembly resolver uses to probe for assemblies.

This means, for pretty much all scenarios, AppContext.BaseDirectory points to the folder where your app is running. That is where the runtime will look for assemblies to load.

https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.hosting.ihostenvironment.contentrootpath says:

Gets or sets the absolute path to the directory that contains the application content files.

This is where things like ASP.NET look for static files to serve to users.

These are different because you can imagine a web application where the static web files are in a different location than where your app's .dll files are located.

[Timovzl]

Thanks @eerhardt.

One more question:

https://docs.microsoft.com/en-us/dotnet/api/system.appcontext.basedirectory?view=net-5.0:

In .NET 5.0 and later versions, for bundled assemblies, the value returned is the containing directory of the host executable.

Doesn't this pose a problem when running in a test runner, where the executable is located elsewhere? Or is the documentation mistaken?

[eerhardt]

I believe the part you missed was

for bundled assemblies

i.e. "PublishSingleFile". The executable can't be located elsewhere, because by definition "single file" apps are contained in a "single file".