> Trying to integrate C# into a Unix-style build pipeline (make/Bazel) doesn't seem straightforward in the current SDK.

Basically, don't do that. "dotnet build" invokes "msbuild" which is a build system analogous to make. If you want a remotely peaceful life, just lay out the project the way Microsoft expect you to and let it do its thing.

You can invoke Roslyn "csc" from the command line, but some of the more obscure bits of tooling (e.g. building "self contained" executables) are only implemented as .dlls that are msbuild Task objects.

Msbuild isn't too bad once you've got over the culture shock that (a) everything is XML rather than tab-delimited makefiles and (b) you've got a glossary of terms that maps to things you know https://learn.microsoft.com/en-us/visualstudio/msbuild/msbui... and (c) you get the binary log viewer https://msbuildlog.com/, which is a fantastic tool that gives you total observability of every detail of the build process. Of which there is a lot.

Separate thought: .net AOT is still very much experimental. All sorts of things are silently incompatible with it, either in the "refuses to build" or the "crash at runtime" way. I'd only use it for small projects built from the ground up to be AOT.

> I couldn't find any compile-to-obj command with flags and such, instead there's a `dotnet` command that takes its input via a monolithic `.csproj` XML file and spits out a fully-formed binary

FYI I'm the lead of the Native AOT team at MSFT.

The key thing about .NET AOT is that it compiles the whole framework together, so right now the `dotnet` command is the top-level tool that connects all the pieces together. If you wanted to integrate with other native code, you can use `dotnet` to output a static library, which could then be linked with the rest of your native code.

You're right that this can be complicated to integrate with other build tooling. It's something we can work on, but there's a bit of inherent friction around the .NET side, where it needs to find all the appropriate libraries, NuGet packages, etc, and a make/bazel world.

Definitely something we can work on as we go forward.

Self-contained single-file assemblies do not require this. Simply specify corresponding properties in .csproj or as arguments to dotnet publish (-p:PublishSingleFile=true --self-contained -r {RID}) and for pure C# projects you will get exactly a single executable file that does not require any dependencies to run except what is expected to have on the average target system (glibc, openssl, etc.).

Other than that, it seems that due to other languages, there is misconception that Native AOT is a panacea that is superior in all areas to normal single-file executables that use JIT. In fact, on average, JIT produces faster code because some optimizations are only possible with tiered and dynamic PGO compilation.

Loved Banshee. There was a short period of time during the mid 00s where it looked like Mono/C# had a chance to become the dominate platform for gnome apps. Banshee, F-Spot, Beagle, Docky.

And some really good stuff came out of the Mono as well. Like Mono.Cecil

I compile F# to a stand-alone executable that runs on a Linux box without any additional .NET installs:

  dotnet publish /property:PublishSingleFile=true --configuration=Release --self-contained=true

You don't even need native AOT for that, you can already create self-contained binaries with .NET Core. Those have fewer restrictions than native AOT, they bundle the necessary runtime.

I've been wondering how to integrate modern .NET Core into a custom build system (buck2) and was wondering similar things. There's this project I think is cool called bflat[1] that basically makes the C# compiler more like the Go compiler in the sense it's a one-shot single-use tool that can cross compile binaries natively. It's done by one of the people on the .NET Runtime team as a side project, and quite neat.

I mostly use Visual Studio but I think in practice you're supposed to compile whole .dll's or assemblies all at once, which acts as the unit of compilation; I don't think the csharp compiler generates native object-files-for-every-.cs or translation unit, the kind of approach you'd expect from javac or g++. Someone please correct me if I'm wrong though! I'd like to learn more if there's a more granular/incremental unit of compilation.

Since Roslyn and the compiler itself are mostly a library, maybe you could also write your own custom "csc-for-bazel" compiler or something to sort of bootstrap the whole thing and offer tighter integration...

.NET 8 will support Native AOT on macOS, I think.

[1] https://github.com/bflattened/bflat

The .NET SDK has some options to integrate NativeAOT with a larger application. You can reference libraries (static or dynamic) and object files during the build to link into the final executable. You can also configure NativeAOT to generate a static or dynamic library that you can link into another executable.

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

Fellow Banshee contributor, ex-F-spot maintainer here. Those were good days.

> annoying aspects was requiring the .NET runtime ... OpenJDK is a blessed implementation in a way that Mono never was

Which is unjustified, because Mono CLR is just a single executable less than 5 MB which you can download and run without a complicated installation process (see e.g. https://github.com/rochus-keller/Oberon/#binary-versions ). AOT compilation on the other hand is a huge and complex installation depending on a lot of stuff including LLVM, and the resulting executables are not really smaller than the CLR + mscorlib + app.

well nowadays you dont need to add each .cs file separately into the csproj file anymore which means you can pretty much just use the same file for your projects and the only difference are the package references. It's not that far away from a barebones folder but I really agree that the default build should allow me to omit csproj files entirely

and then maybe even change the default build to always use AOT and you're precisely where golang is

If you want to be on the bleeding edge, the .NET 8 previews supports AOT for macOS.

A change to support macOS just barely missed the snap to get in .NET 7 but has been available since early pre-preview builds of .NET 8. Its support is really good in 8 and there will be even a feature to use NativeAOT for 'net8.0-ios' targets meaning you could write components in C# and integrate them into Swift binaries via C bindings (maybe there are better interop options? my knowledge is very limited on this topic).

There are efforts to ensure that important workloads like ASP.NET Core work with it well. Due to AOT nature it's often not possible to make it require just a build argument switch, but it is still fairly easy nonetheless, in 90% of situations having to do with switching from reflection to source generation (like in the case of System.Text.Json) or solving statically not-analyzable patters of reflection (AOT supports reflection, just not emitting new code in runtime since there's no JIT!).

Well-written libraries that do not use reflection to generate new code in runtime do not require any changes and "just work". A lot of new code shipped is now written with Native AOT in mind to be compatible (with some exceptions, looking at you, SemanticKernel).

The current way to compile Java AOT is GraalVM's native-image... that actually works pretty well... do you find that awful??

None of those are working yet. I'm hoping to get things going with MAUI.

But I've made some progress with Avalonia.

Here's a sample using Native AOT and Avalonia, with a projection to Rust:

https://github.com/sourcegear/bridge-info/tree/main/samples/...

And here's (basically) the same sample projected to TypeScript:

https://github.com/sourcegear/bridge-info/tree/main/samples/...

These are built using the binding generator I mentioned elsewhere in the comments here. All this stuff is just raw tech, not a ready-to-use solution.

That path has been done multiple times, at the end of the day it isn't worth it.

https://en.m.wikipedia.org/wiki/Java_processor

There has been a push for using Source Generators to move stuff that relies on reflection to compile time code generation. JSON serialization is (mostly) supported in this mode with perf advantages as well.

This does not address pre-existing packages obviously. To make them work with AOT you might need to include an XML file (rd.xml) that indicates all the types that could be dynamically generated in your code. It is quite brittle and AFAIK everything might work until you get a runtime failure if something you did not include ends up being constructed.

With Unity/IL2CPP stuff: For general-purpose serialization libraries like JSON, you sometimes need to provide hints to make sure types are included: https://github.com/jilleJr/Newtonsoft.Json-for-Unity/wiki/Fi...

For schema serialization on known types, there are codegen tools (i.e. moc for MessagePack): https://github.com/neuecc/MessagePack-CSharp

MessagePack is migrating to Rosalyn code generators, so basically invisible codegen. Cysharp's newer serialization library, MessagePack, already uses this: https://github.com/Cysharp/MemoryPack

I was able to use aot and System.Text.Json in a test app. You only need to put an attribute on a class to specifying the type info, and then pass a type enum when you serialize/deserialize. I was surprised how easy it was because I had been really concerned about reflection based stuff like json.

As I understand it, Mono supports reflection when compiling AOT, so serializing using reflection would work.

With a newish .NET they don't need reflection for AOT code, as JSON libraries can use source generators instead.

It can get really tricky: using reflection you could read a string from any input and create a generic type instantiation that never happens in the source code. How would the code for that type be present in an AOT scenario?

There are also several optimizations that can be made in AOT compiled code that are not allowed when you enable unrestricted reflection or dynamically loading code. As an example, suppose an interface is implemented by just one type in your code. If you AOT compile it, the compiler can safely assume that all calls to methods on that interface actually go to that single type implementing it, thus it can replace interface dispatches with direct calls.

You can get serialization to work, but you have to use a serialization framework that is trimming compatible. For example, to use System.Text.Json, you have to opt-in the types you want to serialize.

https://learn.microsoft.com/en-us/dotnet/standard/serializat...

An explanation of the problem: https://github.com/dotnet/corert/blob/master/Documentation/u...

The default XML (de)serializer does a lot of code generation at runtime. Which doesn't work with AOT.