Driving a .NET build with something other than MSBuild

[ghuntley]

overview

Assume that Visual Studio in it's current formation is not constraining you in innovation and the community could draw a line on the topic of backcompat (ie optimise for cloud native/azure scenarios)

Topics of:

• source binary substitution
• hermetic, reproducible, correct, incremental and caching
• observations of cool things other programming languages are doing and conversations about bringing them to .NET
• backcompat considerations
• tooling considerations

options

• bazel
• cmake+ninja
• domino/buildxl
• something new (w/inspiration from https://opam.ocaml.org/packages/dune/)

additional material

• https://cachix.org
• https://nixbuild.net
• https://nixos.wiki/wiki/Overlays
• https://opam.ocaml.org/packages/dune/

related issues

• Instantly make and keep fixes to .NET dependencies from an IDE (everything, including the runtime itself) #25

discussions

As @jaredpar mentions, one key-part is the integration in VS, and so I would prefer that we fix msbuild on several issues that are fixable - xoofx

I know that it's a bad idea (because it would be a huge amount of work, and doesn't provide much incremental value) but I can't stop thinking about driving a .NET build with Bazel - agocke

sure would be nice to have a build system that you can trust. I still compulsively git clean with MSBuild because I know left over files can wreak havoc. With BuildXL no need to clean, it will be correct by construction. Hermetic, reproducible, correct, incremental, caching. - KirillOsenkov

We generate C# client libraries with Bazel, but I haven't looked into the infrastructure much to be honest. (It was all done before I had to start messing with the scripts.) - jonskeet

For @IonideProject we support a plugin based project metadata model, and there's a community member working on parsing bazel files specifically to enable them to use VS Code. Pretty inspiring stuff - chethusk

What we need is a Build/Project Server Protocol, similar to LSP + a MSBuild server (out-of-process, full state of projects, live sync with disk changes...), so that VS could interact with or actually any other build/prj systems - xoof

I would add: I like what SwiftPM has done for dependencies and targets. But it also shows that a replacement is measured in years, even with best intentions and staffing. - migueldeicaza

Disagree. Project generation is a failed approach. It’s not “can we do it” it’s “it breaks the basically rythym of VS”. Can’t round trip with generation. - @jaredpar

You have no idea how long I have DREAMED of just including C# code inside larger C/C++ CMake projects. Imagine how much easier it would be to build native components and the managed code wrappers to go with it. We would have probably got first-class C# support in FreeRDP by now - awakecoding

There's also notably a lot more to a build system than just what the CLI experience offers. Things like what they provide out of the box and the integration with IDEs and project systems is very important as well. Out of all of the ones I've used, MSBuild despite its downsides/flaws, is one of the better ones out there. Partially because it is so well-integrated into all the IDEs/project systems that support it (not just MSFT ones) and because it provides so many things that medium to large projects need out of the box. 800 csproj projects exist. 3-6000 projects exist. 80 csprojs is a medium sized project. Roslyn alone is 200+ you can have small projects that are improperly managed as much as big projects. Medium sized projects typically need things like flowing and copying dependencies, managing where artifacts are published, etc These are all things that MSBuild gives you for "free" (because it has the infrastructure and manages it all for you) but other systems are notably missing or have fairly poor experiences around themIt's also very easy in MSBuild to customize and modify this and to integrate it with other build steps, tasks, targets, etc Notably, if you've ever tried to work with CMake; many of these things only recently became possible or are still quite difficult to do/manage. It also has problems where you move folders, update tooling, or do just about anything else and the entire world has to be rebuilt and its not just automatic, etc - tannergooding and 333fred.

It would probably be more helpful if you could draw a parallel between what [new things] provide vs what MSBuild does not - tannergooding