Accessing class library's content files

[skyflyer]

What is the correct approach in accessing a class library's (not Razor class library!) content files?

For the purpose of this discussion and demonstration, let's have a class library C1 and a simple web app called Runner.

The C1 library contains a file Assets/template.txt that it uses at runtime. This could also be some other binary file that the library uses for its functionality, but let's say that this is not a static web asset (for which the solution exists in the Razor class library).

This library is used in the project Runner. Since the library defines that the Assets/template.txt is copied to output directory and is copied to publish directory, it is possible to access the Assets/template.txt by using IHostEnviornment.ContentRootPath and append Assets/template.txt to it. This only works if you dontet publish the Runner application and run the published binary, but does not work if you dotnet run the runner.

The reason, as I understand, is there is only one IHostEnvironment and so there can be only one ContentRootPath... so accessing the files in the individual class library can be done by using a "workaround":

string assemblyPath = Assembly.GetExecutingAssembly().Location;
string binFolder = Path.GetDirectoryName(assemblyPath)!;

var path = Path.Join(binFolder, "Assets", "template.txt");

The question here is, if this is the correct way to access to these files or is there a better way?

The runnable short demo is provided here: demo.zip

If you dontet publish -o out and cd out and dotnet Runner.dll, you will se that it is working, since Assets folder will be present there. If you just dotnet run it, the Assets/template.txt will not be resolved correctly.

I know there is also the option of EmbeddedResources, but that breaks some other library I'm using which wants to access certain files via regular file system APIs.

[Pilchie]

This is partially an SDK issue question, so also tagging @dsplaisted.

[dotnet-issue-labeler]

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.

[dsplaisted]

The SDK copies the content file from the library project to the output folder for the runner. I think the issue is that when you build a web app but don't publish it, the ContentRootPath is the source root of the project file, not its output path. Is this correct?

If so, I'm not sure what the solution is. Maybe web projects should have a setting where they use the output folder instead of the project file folder (ie skipping the optimization where they don't need to copy content files to the output folder)?

[Pilchie]

Ah, interesting point. Tagging @pranavkm and @javiercn for their thoughts on this.

[skyflyer]

@Pilchie, @dsplaisted - you're correct that it is an SDK issue, sorry for putting it in the wrong place;

The main issue is that the behaviour between dotnet Runner.dll and dotnet run is different, which, IMHO, should not be the case.

The ContentRootPath, as I understand it, should point to the "content" path location and the question for the discussion is how to handle this with dotnet run which has a different bin location and content location. WebRootPath for asp.net core projects is a "similar" issue and is handled.

Perhaps we should first answer the question regarding "bin path" (i.e. debug/net5.0 when dotnet run-ing vs published path): is the ContentRootPath different from "bin path"? Or should they be the same?

[dsplaisted]

@skyflyer Don't worry too much about filing in the exact right repo, we have a lot of them and it's not always obvious where the root cause of an issue is. We'll try to move them as appropriate. :-)

[javiercn]

ContentRootPath points to the project folder when you do dotnet run. If you are not using static web assets (which as you mentions takes care of this) the best way to do this is to make sure the assets end up in the build output folder and to resolve them relative to the app entry point assembly location.

[skyflyer]

So, @javiercn, you're essentially saying that Assembly.GetExecutingAssembly().Location is the correct approach (since it works for dotnet run as well as dotnet assembly.dll?