Collaboration with rules_dotnet?

[purkhusid]

Have there been any previous conversations about merging the rules_dotnet effort and this one? I think it would be a tremendous gain for the already tiny . NET/Bazel community to combine these 2 rulesets.
There are features that both rulesets can gain from each other and users of both rulesets could benefit from buildfile generators for example.

I'm not a maintainer of rules_dotnet so I can't speak with any authority but maybe @tomaszstrejczek can chime in?

[j3parker]

There haven't been any conversation so far. These rules started as an internal (to D2L) fork of rules_dotnet before it was rewritten. As it stands their APIs are quite different. I'll try to summarize things at a high-level as I see it:

The main things we need that I think were gaps with rules_dotnet:

• Correct support for target frameworks: It should behave like MSBuild, e.g. you should be able to build a DLL for multiple target frameworks, and when choosing dependencies to compile/run against it should choose the same ones that MSBuild would. It looks like this. rules_dotnet by contrast (if I remember correctly) expects the user to wire things up manually in BUILD files like the example here.
• .NET Framework support, using the .NET-core SDK for compilation on Linux/Mac (we support builds of .NET Framework on Linux/Mac, even if the output can only be run on Windows.)
• Usage of reference-only assemblies for incremental build performance: we support this in the usual way (we use -refout: to the compiler), but we also have first-class support with an internals_visible_to attribute on e.g. csharp_library (we will generate 3 DLLs: the real one (changes most frequently) the ref-only version for friend assemblies (changes less frequently) and the general ref-only version (changes much less frequently.) See this example.

The things that are a "priority" (we haven't worked on this much lately, but when we pick it up its our next steps) for us, some of this rules_dotnet has and some it doesn't:

• Get bazel test/bazel run working (bazel run/bazel test only work in specific circumstances #9 , bazel run doesn't work for .NET Core on Linux and MacOS #71 , Meta issue: get C# test rules working #128 , The CLR fails sporadically in the Linux sandbox, likely due to a race condition in /tmp #45)
• Get packaging/publishing rules (Rule to create a nupkg #30 , Creation of .NET executable file broken with .NET 5 SDK #148)
• More flexible resource specification (Need a data structure for resources that allow different display name than file name #77)
• Persistent workers using a shim on top of vbcscompiler (Support persistent workers #12)
• Aspect-based csproj generation

Things that are not a priority for D2L (the owners of this repo) but we have no objections to/think are cool:

• F#, VB support (we don't use these)
• Mono support (we don't use Mono)

[j3parker]

So -- we would be happy to collaborate in any way that works. We've made this code open source on GitHub (under a permissive license) partly so that it's available to be copied from. My impression is that both sets of rules are a bit far from feature complete (especially this repo).

I would recommend people use rules_dotnet if it works for them. If, in the future, we could delete this repo and use rules_dotnet for our codebase we will. Our current plans are to expand these rules until they are relatively feature complete, in step with usage of the rules in our internal code base. We have specific (if not terribly unique) needs and at this point we think having these separate rules is working best for us.

We're also happy to take external contributions if people find these rules fit their use-cases better.

[purkhusid]

Ok, it sounds then like these rules are still very much a work in progress? It might then be premature to combine the efforts but I think once these rules have run and test working properly it might be a good time to look into this.

E.g. I contributed the F# support to rules_dotnet and it could pretty much use 95% of the .Net plumbing that existed there since the only step that is different is the compilation task.

It's also on my radar to look into .fsproj/.csproj generation from the Bazel targets and generation of 3rdparty Bazel targets via Paket(https://fsprojects.github.io/Paket/) since it can generate a lockfile which fits well with Bazel's determinism.

I would love for these efforts to benefit as many .Net/Bazel users as possible since we are very few at the moment. But I really do think that Bazel can be a huge benefit for shops with large .Net codebases.

[j3parker]

Ok, it sounds then like these rules are still very much a work in progress? It might then be premature to combine the efforts but I think once these rules have run and test working properly it might be a good time to look into this.

Absolutely. We (D2L) use them, and I think at least one other org uses them (Selenium), but only in a limited capacity.

I'll update our README today to make sure that it's clear that people should check rules_dotnet first.

E.g. I contributed the F# support to rules_dotnet and it could pretty much use 95% of the .Net plumbing that existed there since the only step that is different is the compilation task.

Neat!

It's also on my radar to look into .fsproj/.csproj generation from the Bazel targets and generation of 3rdparty Bazel targets via Paket(https://fsprojects.github.io/Paket/) since it can generate a lockfile which fits well with Bazel's determinism.

Cool! Check out the docs for aspects. I haven't used it personally, but the idea is to teach Bazel how to generate things like IDE files from targets (aside: this is partly why having csharp_library support multi-targeting is important to us; it makes the targets one-to-one which probably makes this simpler).

A related thing is going the other way: generating BUILD files from csproj. We do this because we're not (even close to) ready to have our BUILD files be "the source of truth". We have a .NET library for constructing and serializing Starlark (with idiomatic formatting) but it's currently very coupled to our internal build system. Having the core part of that (the Starlark library and the conversion from csproj to Starlark) could be really helpful for people. I think rules_dotnet has this but only for NuGet/WORKSPACE.

I would love for these efforts to benefit as many .Net/Bazel users as possible since we are very few at the moment. But I really do think that Bazel can be a huge benefit for shops with large .Net codebases.

Yeah, I agree. 😄