These rules try their best to follow the conventions that are used in the project files that MSBuild uses. MSBuild is not used behind the scenes but the compilers and tools that are part of the .Net toolchain are used directly instead.
The biggest change compared to MSBuild out of the box is that by default
these rules do not propagate transitive dependencies to compilation actions.
This is similar to setting <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>
in MSBuild.
This behaviour can be overridden by using the following flag when invoking bazel:
--@rules_dotnet//dotnet/settings:strict_deps=false
You can add this flag to your .bazelrc
file to make it the default.
These rules follow the Bazel idiomatic way of handling compilation modes by reading the --compilation_mode
flag.
If the flag is set to either dbg
or fastbuild
the rules will compile with relase optimizations disabled.
If the flag is set to opt
the rules will compile with the release optimizations enabled.
By default Bazel sets the compilation mode to fastbuild
.
If you want to e.g. enable optimizations in CI you can add common --compilation_mode=opt
to your CI .bazelrc
file.
The following workloads are not supported by these rules at this given time:
- VisualBasic
- Razor
- Blazor/WebAssembly
- Workloads that require Mono
Contributions to add the missing workloads are welcomed and the maintainers will do their best to guide if needed.
The minimal supported Bazel version is 7.0.0 and bzlmod has to enabled.
From the release you wish to use: https://github.com/bazel-contrib/rules_dotnet/releases copy the WORKSPACE snippet into your WORKSPACE file.
If you are using Windows you need to make sure that symlinks and runfiles are enabled.
You can do that by adding the following snippet to your .bazelrc
file:
startup --windows_enable_symlinks
build --enable_runfiles
More information on these flags can be found here:
Various examples of how each rule can be used are in the examples folder.
Currently the rules do not support IDE support out of the box so for proper IDE support the MSBuild project files need to be manually maintained.
NuGet packages are fully supported by the rules in two ways
Paket is a great choice for managing dependencies in .Net and one of the reasons for Paket being a great fit with Bazel is that it supports a lock file out of the box.
See the paket2bazel docs for instructions on how to set Paket up with Bazel.
The rules support remote execution out of the box. The remote runners do need to have the required .Net
system dependencies installed though. A common missing system dependency in existing RBE images is libicu
.