dotnet build
  dotnet run
  dotnet test

Or maybe they deprecated this deprecation later? It's all very confusing.

   dotnet build
   dotnet run

  $ dotnet build
  Couldn't find 'project.json' in current directory

  $ xbuild
  XBuild Engine Version 14.0
  Mono, Version 4.6.1.0
  Copyright (C) 2005-2013 Various Mono authors

  Build started 17.11.2016 18:08:11.
   ...

  Build succeeded.

the .net core sdk (tooling, the cli command line) is 1.0.0-preview2 and use `project.json`

your xbuild is from mono installed on your system, not .net core

if you download and use the .net core sdk `1.0.0-preview3` you will see the msbuild based csproj in preview3 (run `dotnet new`). msbuild based mean `dotnet build` is calling the msbuild library with `/t:Build` argument.

To explicity run msbuild, you can do `dotnet msbuild`

So, yeah, you can create .NET applications without an IDE, and you've been able to for a long time. Was there something specific you wanted to know?

EDIT: in giving the benefit of the doubt, I considered that maybe things had changed since I last written anything for .NET. Maybe the obvious search doesn't return anything. So I tried .NET command line build. I got a full page of what looked to be useful results, including the top result: https://msdn.microsoft.com/en-us/library/78f4aasd.aspx. Now I wish I hadn't wasted the keystrokes on a rhetorical question that I surmise was asked just to be snarky.

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

There's also tools called Paket and Fake which look like .NET counterparts of Ruby's Bundler and Rake, created by F# community. Paket patches .fsproj/.csproj files and it looks like hack but still better than putting absolute paths to preinstalled dependencies.

For creating new projects from template, Yeoman (installable from npm) is quite popular.

Build process in .NET looks like is in transitional state from Visual Studio-first to build tools-first and is still painful and confusing. I didn't try project.json / dotnet tooling yet, because F# website doesn't mention it. I tried only F# and Monogame.

That's f# and .NET Core console app (who host suave web), published in a docker container and run on k8 on google cloud

http://blog.2mas.xyz/fsharp-suave-app-on-dotnet-core-on-kube...

you'll see the experience about cli and sdk. All docs about .net core sdk works.

- `dotnet new -l fsharp`

- `dotnet run`

or

- `dotnet new -l fsharp -t lib`

- `dotnet build`

- `dotnet pack` for nuget packages

Ide works in vs code works with Ionide plugin, if you open it after first `dotnet build`

There were .csproj files and other XML files to deal with, but you can edit those by hand if you feel the need to.

I wouldn't want to have to do things that way though.