Current working directory for dotnet run3 should be project directory

Steps to reproduce

Create a netcoreapp that does this:

using System;
using System.IO;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("cwd = " + Directory.GetCurrentDirectory());
    }
}

dotnet run3

Expected behavior

App prints

cwd = C:\dev\MyProjectFolder

Actual behavior

App prints

cwd = C:\dev\MyProjectFolder\bin\Debug\netcoreapp1.0

Environment data

dotnet --info output:

Product Information: Version: 1.0.0-preview3-003857 Commit SHA-1 hash: 060762090d

SDK version: microsoft.net.sdk/1.0.0-alpha-20161021-1

[davidfowl]

BTW we (ASP.NET) spent weeks on designing this experience when we did the DNX -> dotnet CLI shift. We think we ended up with the best compromise… (all things considered)

[eerhardt]

Alright @natemcmaster, I’ve thought about it more and I think you’ve convinced me. By default, dotnet run should use the current working directory of your console/terminal, just like it did for project.json based projects.

However, dotnet run will respect <StartWorkingDirectory> if it is explicitly set in the .csproj. So the rules for dotnet run are as follows:

1. Ask the project for its <RunWorkingDirectory>, if it returns something, use that value as the working directory.
2. If <RunWorkingDirectory> is empty, it will use the cwd of the console/terminal.

In the https://github.com/dotnet/sdk the rules for defaulting RunWorkingDirectory are:

1. If <StartWorkingDirectory> is set, use it.
2. For .NETFramework and .NETCoreApp, leave RunWorkingDirectory blank by default. (and for all other TFMs for now).

This only requires removing 2 lines in the dotnet/sdk:

https://github.com/dotnet/sdk/blob/c1a276fb456606e2b19d4646f8239d2546790d42/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.targets#L146 https://github.com/dotnet/sdk/blob/c1a276fb456606e2b19d4646f8239d2546790d42/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.targets#L154

The CLI already works correctly with this change. If RunWorkingDirectory is blank, the current working directory is used.

The only problem is Visual Studio. @BillHiebert - VS will need to uptake this change. If RunWorkingDirectory comes back blank, VS will need to default the working directory during F5.

NOTE: The reason there are 2 properties <StartWorkingDirectory> and <RunWorkingDirectory> is because <StartWorkingDirectory> already exists, and users and VS set that property already. The reason we made a new property <RunWorkingDirectory> is to align it with the other “run” properties: <RunCommand> and <RunArguments>. The public contract between the dotnet/sdk and the “clients” are these <RunXXX> properties. Also, with debug profiles coming, the debug profile might want a different working directory than what <StartWorkingDirectory> is set to. So creating a new property for the contract made sense.