> 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.
> 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.
I've only had to interact with it for C[++], but based on that, I'd do a lot to not use it for projects I work on. No-action-needed builds are orders of magnitude slower than with any other tool, the determination of what needs to be rebuilt is ... not accurate, understanding the build rules is hard, there is very little useful documentation, there are a lot of bugs.
I'm satisfied with Bazel as a build system, and some of its functionality that is important to me (sandboxed remote execution) works best when it's not used to delegate to recursively nested sub-builds. To the extent I wish anything different about Bazel, it's to move even further away from integrated language-specific logic[0].
The idea of trying to learn some new ecosystem-specific build tool (in this case msbuild) is unappealing. Done that too many times, and I'm tired of fighting with tools written for/by people who think projects are written in a single language.
I’ve been burned by using the original Buck in an app which is now a pain to maintain. It looks like Bazel is the best path for me to get free of it.
I looked briefly at Buck2 but it doesn’t work yet (for my purposes, at least). Facebook have copied the old Google cliche, “you can use the old version that’s deprecated, or the new version that doesn’t work yet”.
Edit to add: a million times yes to your general point! Language-specific build systems are bad.
> 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.
It's certainly true that most things aren't AOT-compatible out of the box -- this is basically due to the heavy ecosystem reliance on reflection.
If there's some incompatibility, a warning should be generated. If there isn't that's likely a bug on us (https://github.com/dotnet/runtime). But conversely, if there are no warnings, you should be guaranteed that the app should be AOT-compatible.
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.