Your link is a great example of what I don't want, though, and this is what I was afraid of. Compare the experience of using `csc.exe` with `cargo`, for example.

I mean, obviously there is some executable that does the work of building your programs, but you wouldn't suggest someone use `gcc` to manage C projects, would you?

Okay, well, glad I didn't down vote the comment, then.

Compare the experience of using `csc.exe` with `cargo`, for example.

But, to my knowledge, Rust doesn't have an IDE (forgive me if my ignorance of Rust is showing), so if Cargo did not exist it would be necessary to invent it. C# has an IDE, it could be argued that something like Cargo is not required. I posit that your problem is solved, just not in the manner you would like.

but you wouldn't suggest someone use `gcc` to manage C projects, would you?

No, I'd suggest that they use the IDE. But I've done it, because I'm not shipping bits to customers that were built by a developer hitting the F5 key and pulling the output from their local drive.

Really few people just call the compiler directly.

before there was the msbuild but was ugly from command line:

- msbuild /t:Build /p:Configuration=Release

That's why the created the .net core sdk (http://github.com/dotnet/cli).

it's always the compiler all the way down.

but you can do

- `dotnet new -t console` for template

- `dotnet build -c Release` to compile

- `dotnet run` to build+run

- `dotnet pack` to build+ create a package

- `dotnet publish -r osx` to build+create standalone version

- `dotnet test` to build+run tests