It is super easy with dotnet core. The new CLI is pretty simple, you use it as a package manager and compiler. Visual Studio also uses the CLI to run and debug dotnet core projects.
https://docs.microsoft.com/en-us/dotnet/core/tools/
Needing to run my programs (which show up as .dll's) using dotnet just feels weird (and it doesn't match my intuition for 'how programs are run' in Windows cmd/etc).
I'd be fine with an .exe that's not self contained but at least I run it like a 'normal' exe. :)
Yes.
It then makes a stub loader "your program.exe" which looks and behaves normally. You can then make it "self contained", which bundles the assemblies for you and transparently unpacks them.
You can have different publish profiles for the different targets.
You can get it down to 8kb by jettisoning all comforts: https://medium.com/@MStrehovsky/building-a-self-contained-ga... but that's not exactly practical.
Also, the whole thing is still a stateful operation revolving a .csproj file, which (again) is XML I have to create (sure, it's just one command) and manage/deal with every time. Even to compile a tiny C# file from my editor now I need to make a project for it. With a normal C# or C++ compiler I can just invoke csc.exe or cl.exe and produce the executable in one command from my editor... no intermediate state or project file management required. That's kind of what I was getting at with it being "simple". I didn't just mean the syntax, I also meant the structure of the solution.
But again, if you use the dotnet CLI you can just dotnet publish to create a AOT version of your exe. Just remember it still has the runtime and GC. You are just reducing the work of the JIT. Also AOT does not guarantee you will not JIT and still contains the MSIL. It's just a performance optimization where pre-compiled code will be used when possible.