Project-system: F5 Working directory for SDK-based Console Apps is different from Desktop Apps

[natidea]

The following program emits different outputs for Desktop Apps and Sdk-based apps with default settings:

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(System.IO.Directory.GetCurrentDirectory());
    }
}

From VSFeedback | 500011

The working directory for projects using the new csproj format is the project directory rather than bin\$(configuration)\$(targetFramework)

This applies to both 15.3 and 15.4 preview.

When you use the new csproj format, the working directory is the root of the csproj file rather than the output directory where the executing binary lives.

If you execute the exe directly from file explorer, the working directory is the directory containing the exe.

This is not intuitive for accessing files which are copied to the output directory for access when the program is executing.

A workaround for this is to add the following code before referencing any files that you expect to be in the output directory:
var exePath = new Uri(Assembly.GetEntryAssembly().CodeBase).LocalPath;
var directory = Path.GetDirectoryName(exePath);
Directory.SetCurrentDirectory(directory);

Workaround is to set the working directory from Project Properties | Debug | Working Directory

[deckertron9000]

Any update here? This completely breaks 'relative path'-based loading of any files that are selected to be copied to output. Setting the Working Directory in debug properties is not a sufficient workaround since that path must be absolute (according to VS), thus every single one of our developers would have to update every single project's settings on their machines and not check that into source control.

[davkean]

This was fixed in 15.6: https://github.com/dotnet/project-system/pull/3073 and is a dupe of https://github.com/dotnet/project-system/issues/2239.

Above outputs:

c:\users\davkean\Source\Repos\ConsoleApp328\ConsoleApp328\bin\Debug\netcoreapp2.0