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 t

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.