Working directory for ASP.NET Core WebApplication is set to project folder

[Compufreak345]

Visual Studio Version: 16.1.6

Summary: When I run a newly created empty WebApplication and start Debugging the WorkingDirectory is the projects root folder. When I create an empty console application it is the Output Directory. I expect both to be the same (and am quite sure this was the case some time in the past?).

Steps to Reproduce:

1. Create an empty web application project with .Net Core 2.1 or 2.2.

2. Paste this code:

   Console.WriteLine("CurrentDirectory in Main: {0}", System.IO.Directory.GetCurrentDirectory());

3. Run the project without IIS (IIS will show the same behavior but logging it is a bit more complicated).

Expected Behavior: The output is CurrentDirectory in Main: {ProjectPath}\bin\Debug\netcoreapp2.2

Actual Behavior: The output is CurrentDirectory in Main: {ProjectPath}

User Impact: I can't use a library that expects the WorkingDirectory to be in the output directory without adding some code changing the working directory to where it should have been in the first place.

Other notes This issue seems to have been reappearing and fixed for console applications and now seems to appear for web applications as well.

See #2239 and #589

[pi3k14]

I think Microsoft have to make a clear statement, is working directory for console and web apps supposed to be the same, or are they promoting what @davkean wrote in issue #2239. For console apps it has to be output directory.

[pi3k14]

This websdk #238 might be relevant.

[bricelam]

Issue #3619 is about changing console apps to match the behavior of web apps

[AcellaEDU]

It is actual for netcore 3.1 (AST.NET CORE 3.1 MVC/SPA )

[davkean]

Triage: This needs investigation as to what the right behavior is, please reach out to @BillHiebert on ASP.NET tooling to figure out if there's work for either team to do here.

[davkean]

Please factor in https://github.com/dotnet/project-system/issues/3619 when you look into this.

[bricelam]

What I've been told in the past: ASP.NET uses the project directory as the working directory to avoid copying a significant number of content files to the output directory during build which would degrade the dev "inner loop" experience. Content files are, of course however, copied to the publish directory.

[GondilOndro]

For me the problem is that one of the libs (nuget package RandomPersonLib) is looking for its content files using relative path. In our solution we have 2 ways of execution, one is console and second is WebApp. From console everything is working fine but when we run WebApp exception is thrown because RandomPersonLib can't find required data files. So I manually added folder with data to WebApi project folder, however it is not really nice solution. This required data folder is included in WebApi/bin/Debug (as it is set to Build Action: Content, Copy if newer) but while default directory is WebApi it can't be found by RandomPersonLib package.

[ghost]

The current behaviour is confusing, especially since only ASP.NET has this behaviour. As @thothothotho mentioned in #3619, UNIX users expect the current working directory to be the same as where they're running the command from.

If an ASP.NET project needs the working directory to be different, it should be expected that they set that in their IDE or build tool.

[jjmew]

We have reached out to the Web Tools team for additional input

[tmeschter]

Likely By Design.

[drewnoakes]

ASP.NET applications use the project folder as the process working directory on purpose. This enables a workflow where you can modify resources (CSS, JS, HTML, images, ...) in VS and have those picked up in a browser via hot reload or manual refresh without having to build or publish.

Changing this would break well established workflows.

[jmevel]

ASP.NET applications use the project folder as the process working directory on purpose. This enables a workflow where you can modify resources (CSS, JS, HTML, images, ...) in VS and have those picked up in a browser via hot reload or manual refresh without having to build or publish.

Changing this would break well established workflows.

Well, this is by design for the front then. So I'll continue changing the default directory in all my APIs then...

[peterhirn]

@jmevel Can you elaborate on how you accomplish this?

I tried setting the working directory in the project file

<PropertyGroup>
  <RunWorkingDirectory>$(TargetDir)</RunWorkingDirectory>
<PropertyGroup>

But TargetDir, TargetPath, etc. are returning empty values.

[jmevel]

@jmevel Can you elaborate on how you accomplish this?

I tried setting the working directory in the project file

<PropertyGroup>
  <RunWorkingDirectory>$(TargetDir)</RunWorkingDirectory>
<PropertyGroup>

But TargetDir, TargetPath, etc. are returning empty values.

Sorry maybe my comment wasn't clear enough. I was talking about changing the current directory simply with Directory.SetCurrentDirectory

[dmytroshchotkin]

As nicely described (here), you can use Path.GetDirectoryName(Assembly.GetEntryAssembly().Location)

[panagiotidisc]

ASP.NET applications use the project folder as the process working directory on purpose. This enables a workflow where you can modify resources (CSS, JS, HTML, images, ...) in VS and have those picked up in a browser via hot reload or manual refresh without having to build or publish.

Changing this would break well established workflows.

The real workaround for this """feature""" is to set the "workingDirectory" in launchSettings.json to $(TargetDir). Or from the menu Debug -> Debug Properties -> Launch Profiles -> Working Directory = $(TargetDir)

But I have to note that I find the fact that ASP.NET projects were hardcoded to behave peculiarly in many ways (including this), instead of having a proper template for ASP.NET with an appropriate launchSettings.json frankly, quite ludicrous

[jmevel]

ASP.NET applications use the project folder as the process working directory on purpose. This enables a workflow where you can modify resources (CSS, JS, HTML, images, ...) in VS and have those picked up in a browser via hot reload or manual refresh without having to build or publish. Changing this would break well established workflows.

The real workaround for this """feature""" is to set the "workingDirectory" in launchSettings.json to $(TargetDir). Or from the menu Debug -> Debug Properties -> Launch Profiles -> Working Directory = $(TargetDir)

But I have to note that I find the fact that ASP.NET projects were hardcoded to behave peculiarly in many ways (including this), instead of having a proper template for ASP.NET with an appropriate launchSettings.json frankly, quite ludicrous

Awesome, I didn't know we can set this from the launchSettings.json, I should have checked before.

Thanks for the tips