Towards full build generation

[hsyed-dojo]

Hello Folks.

We at Paymentsense/Dojo are considering moving to Bazel for production builds. We operate poly repos and they are in the hundreds.

I'm wondering if full project workspace / build generation is on the horizon. Something akin to gazelle. We would need something like this otherwise we would need to change the way we organise code to make hand managed builds worth it.

I haven't done any dotnet in a decade but totally happy to get my hands dirty with some guidance.

[tomaszstrejczek]

I don't think anybody is working on it. For the next couple of months, I will not have the bandwidth to tackle this problem :(.

[tomdegoede]

Hi @hsyed-dojo . We are using Bazel to build a 500+ project dotnet (core) mono-repo. We have forked rules_dotnet and only kept bare minimum for our scenario. Take a look at https://github.com/AFASResearch/rules_dotnet if you are interested. We do for example generate BUILD files based on csproj files, and also restore the nuget packages on the fly in a single external_repository. Do keep in mind that it's heavily tailored towards our single-consumer use case, but I'm happy to collaborate on making it more re-usable.

[purkhusid]

@tomdegoede Many of the features listed in your fork would be very beneficial to rules_dotnet, do you think some of the features could be upstreamed to this repo to consolidate the Bazel/.Net effort?

@tomdegoede Could you list up the things that would be required for you being able to use the upstream rules_dotnet? I would be willing to help with migrating the features if you think it's a worthy endeavor.

[hsyed-dojo]

We are motivated to make Bazel work for our mass polyrepo scenario, specifically to get to remote builds. Simple and reliable full build generation is needed for us to be able to commit. We'd like developers to be able to regenerate their bazel build without knowing anything about bazel.

I have the cycles to work on this. My dotnet experience is quite of date though so I would need help on how to collaborate on this.

@purkhusid @tomdegoede if you guys have the time perhaps we can set up a call or a chat on a way forward ? You can reach me on Linkedin or Twitter.

[tomdegoede]

Apologies @purkhusid. I must have missed a notification email for your comment. I have a busy weekend planned but will look into formulating a list coming week. I must say that it won't be so trivial as bringing features over since we have deliberately diverged on quite a few decisions. To give an example we did not want to rely on a C toolchain and thus use a different approach to launchers.

@hsyed-dojo sounds good! I'm very up to having a call and devoting time to bring the setup to a higher level.

With regards to upstreaming, I think @tomaszstrejczek should be included in the call as well since he has been very active here. Are you up for that @tomaszstrejczek?

[purkhusid]

I would love to be part of the discussion since we are also using rules_dotnet in production and the F# part is my contribution.
There is a dotnet channel on the Bazel slack and I'm available on the Bazel slack under the name Daniel

If you haven't already signed up for the Bazel slack you can do so here: https://slack.bazel.build/

[samhowes]

We'd like developers to be able to regenerate their bazel build without knowing anything about bazel.

@hsyed-dojo This has been precisely my focus over in rules_msbuild. I'm still polishing the rules and developing docs for it, but I currently use gazelle to generate all the build files for rules_msbuild from the csproj files.

We are discussing the future of bazel .net rules over in #260, but just figured I'd mention that here.

Right now, you can dotnet tool install -g SamHowes.Bzl, then run samhowes.bzl in the root of your workspace. That will create template IDE integration files and a template Build.bazel file that allows you to bazel run //:gazelle to generate the rest of your build files.

I'd be happy to work with people on getting that to work with rules_dotnet if people are interested.

[Place1]

I wrote this tool based on the AFAS nuget repo codegen: https://github.com/Place1/dotnet2bazel

by tool also adds a "skaffold" command that can generate binary/library bazel targets from msbuild files.

# this command generates a nuget_repo from csproj PackageReferences
$ dotnet run -- repository --framework net6.0 /my/project//**/*.csproj > /my/project/nuget.bzl

# this command generates BUILD.bazel files next to each csproj 
$ dotnet run -- skaffold --framework net6.0 --write /my/project/**/*.csproj

Edit: WIP integration into rules_dotnet on a branch here: https://github.com/Place1/rules_dotnet/tree/dotnet2bazel/tools/dotnet2bazel

[tomdegoede]

Very nice @Place1 ! I would love to get the checked in version in here on a higher level but unfortunately its far down on my priority list. Feel free to open up a pull request when your changes may prove useful for others. There also is a BUILD file generator, Afas.BazelDotnet.Project, but I suspect it to be quite outdated from the current rule implementations. Maybe you skaffold command is a good replacement?