3 ms·

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

by aseipp 3y ago

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 https://github.com/bflattened/bflat

MarkSweep 3y ago
For more incrementalism, you can tell csc to generate reference assemblies. These assemblies contain only the public surface area of the assembly. You can use them to avoid recompiling downstream assemblies when the public API surface does not change. They are similar to ijars in Java. https://learn.microsoft.com/en-us/dotnet/standard/assembly/reference-assemblies https://learn.microsoft.com/en-us/dotnet/standard/assembly/r... I’ve been thinking a lot about what a good intervention of .NET and tools like Buck would look like. I think both Buck 1 and Bazel’s rules_dotnet directly target the csc compiler. Given how much logic is written in MSBuild files and how many steps are part of the build (analyzers, illink, ilcompiler), I think it makes sense to target the dotnet executable directly. Having a way to set arbitrary MSBuild properties and items would be nice. It would be nice if you could generate Visual Studio projects from the Buck targets. Lastly, it would be nice if these rules supported Bazel-style persistent workers. Both MSBuild and csc support a client server architecture, but rules_dotnet does not take advantage of that currently. Performance suffers accordingly.
andygocke 3y ago
.NET 8 will support macOS, and yeah I think your approach of basically re-implementing much of the SDK logic in bazel is probably your best bet for a reliable experience. At the same time, it's obvious that that's a considerable chunk of work. Also, IDEs like VS and VS Code are reliant on MSBuild APIs to construct a semantic understanding of the projects, so without MSBuild files, they won't properly function. This is an unfortunate problem, which I don't have a simple solution for.

by aseipp 3y ago

MarkSweep 3y ago

For more incrementalism, you can tell csc to generate reference assemblies. These assemblies contain only the public surface area of the assembly. You can use them to avoid recompiling downstream assemblies when the public API surface does not change. They are similar to ijars in Java. https://learn.microsoft.com/en-us/dotnet/standard/assembly/reference-assemblies https://learn.microsoft.com/en-us/dotnet/standard/assembly/r... I’ve been thinking a lot about what a good intervention of .NET and tools like Buck would look like. I think both Buck 1 and Bazel’s rules_dotnet directly target the csc compiler. Given how much logic is written in MSBuild files and how many steps are part of the build (analyzers, illink, ilcompiler), I think it makes sense to target the dotnet executable directly. Having a way to set arbitrary MSBuild properties and items would be nice. It would be nice if you could generate Visual Studio projects from the Buck targets. Lastly, it would be nice if these rules supported Bazel-style persistent workers. Both MSBuild and csc support a client server architecture, but rules_dotnet does not take advantage of that currently. Performance suffers accordingly.

andygocke 3y ago

.NET 8 will support macOS, and yeah I think your approach of basically re-implementing much of the SDK logic in bazel is probably your best bet for a reliable experience. At the same time, it's obvious that that's a considerable chunk of work. Also, IDEs like VS and VS Code are reliant on MSBuild APIs to construct a semantic understanding of the projects, so without MSBuild files, they won't properly function. This is an unfortunate problem, which I don't have a simple solution for.