.NET rules for Bazel
License: Apache License 2.0
This ruleset is a alternative to using MSBuild with .Net
By using this ruleset instead of MSBuild you gain the Bazel promise of {Fast, Correct} - Choose two
This document will not enumerate all the possible gains that Bazel can bring and instead it's recommended to take a look at the Bazel documentation for a primer on Bazel.
See the documentation in the docs
See examples in the examples folder.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
I'd like to be able to build rules_dotnet with --all_incompatible_changes:
cd rules_dotnet && bazel build //... --all_incompatible_changes
It may not be possible to fix every issue now due to transitive dependencies, but we should try to fix the issues from this repository.
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html
The commit 30c1c31 broke our CI tests for both HEAD and latest versions of Bazel.
Are there plans for a new release (0.0.3 or above?) anytime soon? It seems that there's been some change since 0.0.2. Is that still the best version to use or is there a more recent commit that's pretty stable.
Thanks
Bazel 0.25 implements the ability to run bazel test rules without using Bash by including a flag, --incompatible_windows_native_test_wrapper. According to this Bazel issue, this flag will become the default behavior in 0.27. When attempting to run an NUnit test using bazel test and the --incompatible_windows_native_test_wrapper flag in Bazel 0.25 or 0.26, the target fails with %1 is not a valid Win32 application.
I'm unable to use these rules with bazel 0.21.0 due to an invalid registered toolchain '@io_bazel_rules_dotnet//dotnet/toolchain:dotnet_net_linux_amd64': Analysis failed issue. I'm not sure of the underlying cause at the moment.
dotnet build have been red from the begining because there is no mono on the machine. Even installing mono did not fix the build.
Can someone have a real look at this?
Hi. Thanks for updating the .net rules!
I gave it a try, and was able to put together a working sample relatively quickly. The only issue I had was with the nuget rule.
I am wondering if it would be possible to clarify the nuget rules a bit more. I am curious why we have to specify so many details about the dlls in the package. In regular .Net, all you have to specify is the name of the package.
Here is a quick write up of the sample that I did: http://www.syntaxsuccess.com/viewarticle/building-dotnet-with-bazel
I am trying to build a .NET Core binary using Bazel.
WORKSPACE:
load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
git_repository(
name = "io_bazel_rules_dotnet",
remote = "https://github.com/bazelbuild/rules_dotnet",
branch = "master",
)
load(
"@io_bazel_rules_dotnet//dotnet:defs.bzl",
"core_register_sdk",
"net_register_sdk",
"dotnet_register_toolchains",
"dotnet_repositories",
)
dotnet_register_toolchains()
dotnet_repositories()
core_register_sdk("v2.1.502", name = "core_sdk")BUILD.bazel:
load(
"@io_bazel_rules_dotnet//dotnet:defs.bzl",
"dotnet_binary",
)
dotnet_binary(
name = "hello",
srcs = [
"Hello.cs",
],
)Error message:
/BUILD.bazel:6:1: every rule of type dotnet_binary implicitly depends upon the target '@dotnet_sdk//:native_deps', but this target could not be found because of: no such package '@dotnet_sdk//': The repository could not be resolved
ERROR: Analysis of target '//:hello' failed; build aborted: no such package '@dotnet_sdk//': The repository could not be resolved
INFO: Elapsed time: 0.214s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (9 packages loaded, 42 targets configured)
FAILED: Build did NOT complete successfully (9 packages loaded, 42 targets configured)
Perhaps I have missed something simple?
$ bazel version
Build label: 0.23.1
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Mar 4 10:37:56 2019 (1551695876)
Build timestamp: 1551695876
Build timestamp as int: 1551695876Some nuget packages support multiple frameworks using the following convention in their directory structure.
lib/net{40,45}/...
Unfortunately the nuget package manager doesn't really support handling this for you. Which means we need to intelligently detect when there is a net* directory and handle it correctly. If we don't then the dotnet compiler will complain about multiple definitions for symbols as it pulls in all the assemblies at once.
Getting this error when trying to use RestSharp (or any library) from NuGet.
Here is my nuget_package:
nuget_package(
name = "rest_sharp_102_7_0_0",
package = "RestSharp",
version = "102.7.0.0",
)
And here is the error:
/opt/app/client/dotnet/BUILD:3:1: no such package '@rest_sharp_102_7_0_0//':
Nuget command failed: The type initializer for 'NuGet.ProxyCache' threw an exception.
libc
Any thoughts here? I also get that same error when I run nuget.exe directly. I installed mono on ubuntu by installing the default mono_devel package.
I'm trying to build a very simple project that outputs a .dll. This project has one file with a single method that returns a string. My WORSPACE is right from the README as follows:
git_repository(
name = "io_bazel_rules_dotnet",
remote = "https://github.com/bazelbuild/rules_dotnet",
commit = "4a255eefbe099e2b3cd665baa407617fa27b6ad9",
)
load("@io_bazel_rules_dotnet//dotnet:defs.bzl", "core_register_sdk", "net_register_sdk", "mono_register_sdk", "dotnet_register_toolchains", "dotnet_repositories", "nuget_package")
dotnet_register_toolchains()
dotnet_repositories()
core_register_sdk("v2.1.502", name = "core_sdk")
net_register_sdk("net471", name = "net_sdk")
mono_register_sdk()
My BUILD file is also very simple:
load("@io_bazel_rules_dotnet//dotnet:defs.bzl", "dotnet_library")
dotnet_library(
name = "api",
srcs = ["HelloWorld.cs"],
)
When I try to build this target I get:
external/io_bazel_rules_dotnet/BUILD:6:1: every rule of type dotnet_context_data implicitly depends upon the target '@dotnet_sdk//:mcs_bin', but this target could not be found because of: no such package '@dotnet_sdk//'
My understanding was that the calls to dotnet_register_toolchains(), dotnet_repositories(), etc... should have set everything up by having Bazel download all the required libraries.
Am I misunderstanding this?
I'm running on MacOS.
Thanks in advance.
...should be non-mandatory as nuget.org itself does not servestable sha256 values for artifacts over time.
It works if you use it inside this repositories workspace but if you include this repository in a different workspace it can't find the build file. It looks for it in the current workspace instead.
/private/var/tmp/_bazel_jwall/a4f05aced329c5d1ca55a18062777a02/external/io_bazel_rules_dotnet/bazel-bazel_rules_dotnet/examples/example_test/BUILD:3:1: every rule of type csharp_nunit_test implicitly depends upon the target '@nunit//:nunit_exe_libs', but this target could not be found because of: no such package '@nunit//': In new_http_archive rule //external:nunit the 'build_file' attribute does not specify an existing file (/Users/jwall/Downloads/csharp_tests/dotnet/nunit.BUILD does not exist).
With the cfg parameter update, consider cutting 0.0.3 release as this requires bazel 0.3.1 or above.
pretty please...
When I change a unit test and run bazel test, the test is not getting rebuilt - it simply runs the old version.
Bazel version: 0.22.0
OS: Linux
C# DLLs can have embedded resources (files that are stuffed into the DLL). In msbuild/csproj when you embed a resources with file type .resx it is first passed to resgen.exe along with all the referenced DLLs to be compiled into a .resource file (which is then embedded in the DLL).
Currently, the rules_dotnet rules accept .resx files (along with .cs files) in the srcs attribute of csharp_library (etc.) but don't specially handle them (my testing indicates if you pass a resx file to the rules the compile will actually fail).
In PR #50 I added support for resources via a resource attribute.
I'd like to support emitting actions to call resgen.exe but I'm not sure what the best/idiomatic design for the rules would look like. I've outlined two major options below:
csharp_library(
name = "mylib",
srcs = [ "foo.cs" ],
resources = [
"foo.bmp",
"foo.resx"
],
deps = [
"//othercsharplibs:A",
"//othercsharplibs:B",
],
)How this works: everything in resources that isn't a .resx file is passed to csc.exe directly with /resource:%s. .resx files are first passed (in a separate action) to resgen.exe along with deps to generate a .resource file which is passed via /resource:%s.
Why this is nice: It just works™: developers probably don't want to know the gory details here. This matches the behavior of msbuild+csproj where msbuild figures out that it needs to call resgen for you (.resx files look the same as vanilla resources inside a csproj).
A variation: Include .resx files in srcs: this is maybe more explicit. If this option were chosen it might be nice to ban .resx from resources to avoid confusion. .resx is currently allowed in the srcs attribute so maybe that was the original intent.
csharp_library(
name = "mylib",
srcs = [
"foo.cs"
"foo.resx"
],
resources = [ "foo.bmp" ],
deps = [
"//othercsharplibs:A",
"//othercsharplibs:B",
],
)In either case, the actions look like:
ctx.actions.run(
inputs = ["foo.resx", "//othersharplibs:A.dll", "//othercsharplibs:B.dll" ],
outputs = [ "foo.resource" ],
executable = "resgen.exe",
...
)
ctx.actions.run(
inputs = [ "foo.cs", "foo.bmp", "foo.resource", "//othercsharplibs:A.dll", "//othercsharplibs:B.dll", ],
outputs = "mylib.dll",
executable = "csc.exe",
...
)resource_library rule:resource_library(
name = "rlib",
srcs = [
"foo.bmp",
"bar.resx",
],
deps = [ "//othercsharplibs:A" ],
)
csharp_library(
name = "mylib",
srcs = [ "foo.cs" ],
resources = [ "other.txt" ],
deps = [
"//othercsharplibs:B",
":resourcelib",
],
)How this works: rlib has an action to call resgen.exe on bar.resx to generate bar.resource. When mylib depends on :resourcelib it picks up foo.bmp and bar.resource which get passed with other.txt to csc.exe via a /resource:%s argument. mylib also picks up the transitive dep on //othercsharplibs:A.
Why this is nice: the deps on rlib can be explicitly listed, rather than using all deps from mylib. This would improve caching and make it easier to share compiled resx resources between different DLLs. It is less magic.
The actions look something like this (note that the resgen.exe action has fewer inputs):
ctx.actions.run(
inputs = ["foo.resx", "//othersharplibs:A.dll" ],
outputs = [ "foo.resource" ],
executable = "resgen.exe",
...
)
ctx.actions.run(
inputs = [ "foo.cs", "foo.bmp", "other.txt", "foo.resource", "//othercsharplibs:A.dll", "//othercsharplibs:B.dll", ],
outputs = "mylib.dll",
executable = "csc.exe",
...
)Support (A) and (B) at the BUILD authors choice.
I'm slightly inclined to (C), starting with (A) first implementation-wise. At the action level there isn't much difference (other than (B) allowing more control (but the benefits may be minimal.)) I don't have strong opinions though.
(thanks @cpacey for proof-reading this.)
This is fixed on https://github.com/pcj/rules_dotnet/tree/fix_nunit_extra_refs but will await resolution of #27 before sending another PR.
Many monorepo enthusiasts insist that dependencies are checked into the source control system. The .NET ecosystem supports this by use of a custom NuGet feed. In Visual Studio, this can be achieved by creating a file called NuGet.config XML file and adding a <packageSources> element that contains a reference to the directory on disk containing the .nupkg files. In the IDE, this shows up as an entry in the Package Sources list of the NuGet Package Manager window.
Additionally, this would allow users to use internal packages not published to nuget.org, as there is currently no way to do this. The use case here is a version of a package where the maintainer either has not or will not accept bug fixes, and the development team maintains a forked version of the dependency project. There may not be any need for the development team to build this dependency as part of the target project, and the dependency code should not be a part of the target project.
This is a tracking issue to document the work remaining to support Windows and .NET Framework in these rules.
High-priority:
:dylibs target falls apart pretty fast and may be a blocker if we depend on NuGet packages in the impl of these rules/noconfig, /nostdlib (I think), /deterministic, /pathmap ...)Low-priority:
http_repository) might be nice: https://github.com/dotnet/roslyn/tree/master/src/Compilers/Server/VBCSCompilerSince the implementation for the unit test rules calls dotnet.assembly, just as the implementations for binaries and libraries, and the data attribute for the latter two implementations allow files, the unit test rules should likewise allow files. The use case is that there is currently no way to add non .cs files to the runlist for the rule, so things like test data files, configuration files, and so on are unavailable to the tests.
Hello,
I'm currently trying to set up a Bazel build for a .net core (2.2) webapp project (references Microsoft.AspNetCore.App).
I figured out how to configure/declare all dependencies, however when I try to add Remotion.Linq (2.2.0) Bazel quits with an IOException.
The lib itself seems to download just fine, but during extraction an exception is thrown.
My setup is macOS 10.14.3, rules_dotnet master branch, and Bazel 0.23.1.
INFO: SHA256 (https://www.nuget.org/api/v2/package/Remotion.Linq/2.2.0) = ae93e9db1c878f626c4f2ea4dc5021963be5f393cd6b747d8eb572dd41b486f8
java.io.IOException: Error extracting /private/var/tmp/_bazel_d072124/0817235a9f3a8096f1bb2947ce5da081/external/remotion-linq/2.2.0.zip to /private/var/tmp/_bazel_d072124/0817235a9f3a8096f1bb2947ce5da081/external/remotion-linq: Unrecognized file mode for [Content_Types].xml: 0x80 and referenced by '//modules/csharp-endpoint/CSharp.Project:csharp-endpoint'
Thanks & Regards
We should set up CI to run for each pull request.
I have a dotnet_binary built and it runs locally (Mac OS). I would like to use bazel to build and distribute to other servers. Other than the actual .exe file, what other directories do I need to include? I need the external dlls as well but I'm not sure where the correct place to pull them from is.
I've noticed the following issues with the instructions in the README.md to get started:
If the nuget_package part is meant as an example, please move it to some other place and mark it as an example (a poor one at that); prefer using an example that the user can see working -- i.e. let it reference a real nuget package.
NB: I still haven't made this work and I'm currently relying on a custom genrule where I have a hardcoded path to csc compile on windows and rely on a system installed mcs on other platforms (hardly ideal).
Any plans to support xunit?
Hi there, I might have missed something somewhere. How could I easily add assemblies bundled with mono easily, such as System.Data.dll?
This seems to be full .NET Framework with Mono.
The future of .NET seems to be .NET Core. Is there an intent to support .NET Core?
The launcher script for a csharp_binary currently cd's into its runfiles directory. But this means it can't be used as a tool (i.e. in a genrule) because Bazel passes file arguments as relative paths. Console output works, but named srcs and outs don't.
The current working directory needs to be preserved when running a csharp_binary as a tool.
In sdk_net.bzl, the SDK tools version is tagged off of the .NET Framework version. However, it's possible to compile a project of a given .NET Framework version (say, .NET Framework 4.5) with tools for a different SDK (say, NETFX 4.6.2 Tools). Moreover, current versions of Visual Studio do not provide down-level framework tools, so this is an ordinary state of affairs. This produces issues when using dotnet_register_toolchains with an appropriate .NET Framework version to compile against.
I'm trying to set up dotnet_nunit_test with moq. I have the following in my WORKSPACE
dotnet_nuget_new(
name = "moq",
package = "moq",
version = "4.10.0",
source = "https://www.nuget.org/api/v2/package",
build_file_content = """
package(default_visibility = [ "//visibility:public" ])
load("@io_bazel_rules_dotnet//dotnet:defs.bzl", "dotnet_import_library")
dotnet_import_library(
name = "lib",
src = "lib/net45/Moq.dll",
)
"""
)
I refer to this by adding the following line to test dependency
"@moq//:lib",
However, I'm getting the following message:
error CS0009: Metadata file `/private/var/tmp/_bazel_byang/2fc73dc3f7e41d43b739acd65e005cdf/execroot/grail/external/moq/lib/net45/Moq.dll' does not contain valid metadata
The contents of moq/net45 include a Moq.dll, Moq.xml and Moq.pdb. Do these other files need to be referenced?
Any insight would be greatly appreciated. Thanks!
In the net_library rule, when specifying to compile against a legacy framework version like .NET 3.5, the reference assemblies get resolved properly, but the build fails when executing the C# compiler. This is because there is a response file in the directory with the compiler itself (csc.rsp) which specifies framework references already. However, these specified references are not the correct versions, as those references get resolved to a different framework version.
There is a command line switch for the C# compiler that allows the user to bypass the built-in response file in favor of explicitly specifying framework assembly references. This is the same thing Visual Studio does when it calls the compiler, using the /noconfig command line switch to avoid the automatic resolution of framework assembly references.
Note carefully that this command line switch cannot be added to the parameters file that gets created by the current rule, as it gets ignored when present in a parameters file. It must be part of the actual command line executing csc.exe.
I get an error: The user's home directory could not be determined. Set the 'DOTNET_CLI_HOME' environment variable to specify the directory to use.
What is the canonical way of solving this? If it were my own rule I could add an env dict to the run_shell command but here I'm not sure.
Running a csharp_binary fails to find mono:
pcj:~/github/rules_protobuf/examples/helloworld/csharp$ bazel run GreeterClient
INFO: Found 1 target...
Target //examples/helloworld/csharp/GreeterClient:GreeterClient up-to-date:
bazel-bin/examples/helloworld/csharp/GreeterClient/GreeterClient.exe
bazel-bin/examples/helloworld/csharp/GreeterClient/GreeterClient
INFO: Elapsed time: 0.084s, Critical Path: 0.00s
INFO: Running command line: bazel-bin/examples/helloworld/csharp/GreeterClient/GreeterClient
/private/var/tmp/_bazel_pcj/63330772b4917b139280caef8bb81867/execroot/rules_protobuf/bazel-out/local-fastbuild/bin/examples/helloworld/csharp/GreeterClient/GreeterClient: line 14: org_pubref_rules_protobuf/external/mono/bin/mono: No such file or directory#!/bin/bash
if [[ -e "$0.runfiles" ]]; then
cd $0.runfiles/org_pubref_rules_protobuf
fi
# TODO(jeremy): This is a gross and fragile hack.
# We should be able to do better than this.
ln -s -f org_pubref_rules_protobuf/examples/helloworld/csharp/GreeterClient/GreeterClient.exe $(basename examples/helloworld/csharp/GreeterClient/GreeterClient.exe)
for l in ../nuget_google_protobuf/Google.Protobuf.3.0.0/lib/net45/Google.Protobuf.dll ../nuget_google_protobuf/Google.Protobuf.3.0.0/lib/netstandard1.0/Google.Protobuf.dll ../nuget_grpc/Grpc.Core.1.0.0/lib/net45/Grpc.Core.dll examples/helloworld/csharp/Greeter/Greeter.dll ../nuget_google_protobuf/Google.Protobuf.3.0.0/lib/net45/Google.Protobuf.dll ../nuget_google_protobuf/Google.Protobuf.3.0.0/lib/netstandard1.0/Google.Protobuf.dll ../nuget_grpc/Grpc.Core.1.0.0/lib/net45/Grpc.Core.dll; do
ln -s -f org_pubref_rules_protobuf/$l $(basename org_pubref_rules_protobuf/$l)
done
org_pubref_rules_protobuf/external/mono/bin/mono $(basename examples/helloworld/csharp/GreeterClient/GreeterClient.exe) "$@"When building a .NET Core project, .NET Framework 4.7.2 seems to be required on Windows. I have not try on another OS.
I believe it is related to this line. If I use @core_sdk//:lib instead I am able to build a simple .NET Core project. As I am not familiar with the details of the dotnet rules, I am not sure if this modification is a suitable fix.
Here is the content of my WORKSPACE:
workspace(name = "test_rules_dotnet")
load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
git_repository(
name = "io_bazel_rules_dotnet",
remote = "https://github.com/bazelbuild/rules_dotnet",
commit = "b0783136d724a23f36221c195872b8ce224cd34b",
)
load("@io_bazel_rules_dotnet//dotnet:defs.bzl", "dotnet_register_toolchains", "dotnet_repositories")
dotnet_register_toolchains(dotnet_version = None, net_version=None, net_roslyn_version=None)
dotnet_repositories()Then, when using the core rule such as core_binary I get the following error from Bazel:
ERROR: C:/users/xxxx/_bazel_xxxx/63x74dcf/external/io_bazel_rules_dotnet/BUILD:8:1: every rule of type core_context_data implicitly depends upon the target '@net_sdk//:lib', but this target could not be found because of: no such package '@net_sdk//': The repository could not be resolved
ERROR: Analysis of target '//MyProject:my_project' failed; build aborted: no such package '@net_sdk//': The repository could not be resolved
I believe roslyn is already part of the .NET Core package but even if I let the default value for net_roslyn_version, I get:
ERROR: C:/users/xxxx/_bazel_xxxx/63x74dcf/external/io_bazel_rules_dotnet/BUILD:8:1: every rule of type core_context_data implicitly depends upon the target '@net_sdk//:lib', but this target could not be found because of: no such package '@net_sdk//': Traceback (most recent call last):
File "C:/users/xxxx/_bazel_xxxx/63x74dcf/external/io_bazel_rules_dotnet/dotnet/private/sdk_net.bzl", line 34
_detect_net_framework(ctx, ctx.attr.version)
File "C:/users/xxxx/_bazel_xxxx/63x74dcf/external/io_bazel_rules_dotnet/dotnet/private/sdk_net.bzl", line 7, in _detect_net_framework
fail(((("Failed to find .net " + vers...)))
Failed to find .net in default location C:/Program Files (x86)/Reference Assemblies/Microsoft/Framework/.NETFramework/v
ERROR: Analysis of target '//MyProject:my_project' failed; build aborted: no such package '@net_sdk//': Traceback (most recent call last):
File "C:/users/xxxx/_bazel_xxxx/63x74dcf/external/io_bazel_rules_dotnet/dotnet/private/sdk_net.bzl", line 34
_detect_net_framework(ctx, ctx.attr.version)
File "C:/users/xxxx/_bazel_xxxx/63x74dcf/external/io_bazel_rules_dotnet/dotnet/private/sdk_net.bzl", line 7, in _detect_net_framework
fail(((("Failed to find .net " + vers...)))
Failed to find .net in default location C:/Program Files (x86)/Reference Assemblies/Microsoft/Framework/.NETFramework/v
An error happens during the download of the .net core sdk version v2.1.502. It looks like this version is not available. I fix it by using the version v2.1.503.
I can suggest my fix .
In the WORKSPACE
I had to fix two issue about xunit
I would like to propose the new implementation:
https://github.com/tomaszstrejczek/rules_dotnet/tree/toolchain
(branch toolchain).
It is heavily influenced by rules_go (toolchains, context, providers) and the current implementation of rules_dotnet.
It also works on Windows.
❯❯❯ bazel test //examples/example_test:MyTest --verbose_failures
INFO: Found 1 test target...
INFO: From Compiling examples/example_test:MyTest:
Compilation succeeded - 3 warning(s)
/private/var/tmp/_bazel_dzc/9d5835329f2557545b1fe29ae53eddd7/rules_dotnet/examples/example_test/MyTest.cs(10,18): warning CS1591: Missing XML comment for publicly visible type or member `example_test.MyTest'
/private/var/tmp/_bazel_dzc/9d5835329f2557545b1fe29ae53eddd7/rules_dotnet/examples/example_test/MyTest.cs(13,21): warning CS1591: Missing XML comment for publicly visible type or member `example_test.MyTest.MyTest1()'
/private/var/tmp/_bazel_dzc/9d5835329f2557545b1fe29ae53eddd7/rules_dotnet/examples/example_test/MyTest.cs(19,21): warning CS1591: Missing XML comment for publicly visible type or member `example_test.MyTest.MyTest2()'
FAIL: //examples/example_test:MyTest (see /private/var/tmp/_bazel_dzc/9d5835329f2557545b1fe29ae53eddd7/rules_dotnet/bazel-out/local_darwin-fastbuild/testlogs/examples/example_test/MyTest/test.log).
Target //examples/example_test:MyTest up-to-date:
bazel-bin/examples/example_test/MyTest.dll
bazel-bin/examples/example_test/MyTest.xml
bazel-bin/examples/example_test/MyTest
INFO: Elapsed time: 0.476s, Critical Path: 0.28s
//examples/example_test:MyTest FAILED in 0.1s
/private/var/tmp/_bazel_dzc/9d5835329f2557545b1fe29ae53eddd7/rules_dotnet/bazel-out/local_darwin-fastbuild/testlogs/examples/example_test/MyTest/test.log
Executed 1 out of 1 tests: 1 fails locally.
I've been trying to use bazel to build C# libraries on Windows 10, with no success. I'm trying to build rules_dotnet as an initial test.
Initially, bazel says that mono isn't supported on Windows 10. Following that, I set an environment variable RULES_DOTNET_USE_LOCAL_MONO equal to 1. After that, bazel said that MONO needed to be set; after reading through csharp.bzl, I set MONO to the path to Mono, e.g. C:\Program Files\Mono\. I'm not really sure if this is the correct location to set it to. I also set CSC as an environment variable pointing to a variety of locations for mcs and csc (C:\Program Files\Mono\bin\mcs.bat, C:\Program Files\Mono\lib\mono\4.5\csc.exe, C:\Program Files\Mono\lib\mono\4.5\mcs.exe). None of these work. When I run bazel build ..., I get a message:
ERROR: missing input file '@mono//bin:mono'
ERROR: C:/meta/rules_dotnet/examples/example_tool/BUILD:13:1: //examples/example_tool:hello_single_output: missing input file '@mono//bin:mono'
ERROR: C:/meta/rules_dotnet/examples/example_tool/BUILD:13:1 1 input file(s) do not exist
This led me to add a print statement to see the path to mcs. In csharp.bzl, in _csc_compile_action, I've tried printing out ctx.file.csc.path, and get external/mono/bin/mcs. Since this didn't seem correct, I looked into how the location of csc is set and saw that I can set it in the BUILD files for the library. I added a csc = line to the example library's BUILD, but that doesn't fix the issue.
I've tried setting MONO to csc (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe), as well as pointing CSC to the same location, but that didn't work either.
Can you provide any guidance? Is it just not possible?
manifest_prep on Linux attempts to create hardlinks across filesystem boundaries. Windows code has the branch that falls back to symlinks, while Linux code doesn't.
It results in errors:
Error 18 on linking /xxxxx/System.Collections.Specialized.dll to /yyyyy/output-base/external/dotnet_sdk/lib/4.5/Facades/System.Collections.Specialized.dll
The mnemonic attribute for ctx.actions.run and ctx.actions.run_shell (https://docs.bazel.build/versions/master/skylark/lib/actions.html#run) is important to be able to attach custom sandbox strategies to that action type. Please add these so end-users can selectively disable sandboxing for core_library if needed.
If these do have mnemonics and I missed it, please document them. Thanks!
dotnet_download_sdk looks like was copy-pasted from rules_go directly as it demonstrates download of the go sdk.
On an osx machine without mono, csharp_repositories() did install mono, but did not install nunit (or at least it did not on my machine). As nuget_package does not check for return_code, failure is silent. Also, since glob(["**/*.dll"]) in a nuget BUILD file happily accepts no matching files, adding a dependency on a nuget_package is also a silent failure.
I'm having trouble getting the csharp_binary rule to work. I'm on OS X 10.12.
The rule seems to build OK, but when I run it I get this error:
$ bazel run :inklecate
INFO: Found 1 target...
Target //:inklecate up-to-date:
bazel-bin/inklecate.exe
bazel-bin/inklecate
INFO: Elapsed time: 0.066s, Critical Path: 0.00s
INFO: Running command line: bazel-bin/inklecate
Cannot open assembly 'inklecate.exe': Too many levels of symbolic links.
ERROR: Non-zero return code '2' from command: Process exited with status 2.
The rule looks like this:
csharp_binary(
name = "inklecate",
main_class = "Ink.CommandLineTool",
srcs = glob([
"inklecate/*.cs",
"inklecate/**/*.cs",
"ink-engine-runtime/*.cs",
]),
warn = 3, # Suppress documentation warnings
)
I've tried both use_local_mono = True and False but that doesn't seem to make a difference.
Full code is here: https://github.com/iainmerrick/ink
Further discussion on the Bazel mailing list: https://groups.google.com/forum/#!msg/bazel-discuss/M-qFbm0x6mY/KOy_ljc4AAAJ
bazel run examples/example_binary:hello reports an error finding the path for mono.
private/var/tmp/_bazel_jwall/a4f05aced329c5d1ca55a18062777a02/csharp_tests/bazel-out/local-fastbuild/bin/examples/example_binary/hello: line 12: external/local_config_csharp/mono: No such file or directory
This is because the actual path for the mono executable is csharp_tests/external/local_config_csharp/mono inside the runfiles directory. where csharp_tests is the name of the current workspace.
http://bazel-mirror.storage.googleapis.com/github.com/nunit/nunitv2/releases/download/2.6.4/NUnit-2.6.4.zip has ambiguous architecture. Looks like a windows binary package? I had expected it to be osx, maybe I missed it in the docs...
pcj:/private/var/tmp/_bazel_pcj/63330772b4917b139280caef8bb81867/external/nunit$ ls -al NUnit-2.6.4/bin/nunit-console.exe
-rwxr-xr-x 1 pcj wheel 5120 Sep 19 18:41 NUnit-2.6.4/bin/nunit-console.exe
pcj:/private/var/tmp/_bazel_pcj/63330772b4917b139280caef8bb81867/external/nunit$ NUnit-2.6.4/bin/nunit-console.exe
-bash: NUnit-2.6.4/bin/nunit-console.exe: cannot execute binary file
pcj:/private/var/tmp/_bazel_pcj/63330772b4917b139280caef8bb81867/external/nunit$ file NUnit-2.6.4/bin/nunit-console.exe
NUnit-2.6.4/bin/nunit-console.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit Mono/.Net assemblySee http://ci.bazel.io/job/rules_dotnet/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/3/console:
____[7 / 11] Compiling examples/example_transitive_lib:TransitiveClass
ERROR: /home/ci/workspace/rules_dotnet/BAZEL_VERSION/HEAD/PLATFORM_NAME/linux-x86_64/examples/example_transitive_lib/BUILD:3:1: error executing shell command: '/usr/local/bin/mcs -out:bazel-out/local_linux-fastbuild/bin/examples/example_transitive_lib/TransitiveClass.dll -target:library -fullpaths -warn:4 -nologo -doc:bazel-out/local_linux-fastbuild/bin/e...' failed: namespace-sandbox failed: error executing command
(cd /home/ci/.cache/bazel/_bazel_ci/1471c2a9e7dce6d4e1d950b43de46d01/linux-x86_64 && \
exec env - \
/home/ci/.cache/bazel/_bazel_ci/1471c2a9e7dce6d4e1d950b43de46d01/linux-x86_64/_bin/namespace-sandbox @/home/ci/.cache/bazel/_bazel_ci/1471c2a9e7dce6d4e1d950b43de46d01/linux-x86_64/bazel-sandbox/e5591ace-6edb-42f2-b6ab-9581eb783b26-0.params -- /bin/bash -c '/usr/local/bin/mcs -out:bazel-out/local_linux-fastbuild/bin/examples/example_transitive_lib/TransitiveClass.dll -target:library -fullpaths -warn:4 -nologo -doc:bazel-out/local_linux-fastbuild/bin/examples/example_transitive_lib/TransitiveClass.xml -debug examples/example_transitive_lib/Properties/AssemblyInfo.cs examples/example_transitive_lib/TransitiveClass.cs' '' -out:bazel-out/local_linux-fastbuild/bin/examples/example_transitive_lib/TransitiveClass.dll -target:library -fullpaths -warn:4 -nologo -doc:bazel-out/local_linux-fastbuild/bin/examples/example_transitive_lib/TransitiveClass.xml -debug).
: /usr/local/bin/mcs: No such file or directory
Right now /usr/local/bin/mcs is hardcoded and I'm not sure it's included in the sandbox.
This is going to require platform specific repositories probably.
On OS-X we can probably reuse some of this code: https://github.com/mono/release/blob/master/defs/managed-components#L52
For Linux we can probably unpack one of the distro packages.
For MS I'm not sure what we should do but that can probably wait till bazel windows support is stabilized.
It would be nice if a csharp_binary or csharp_library target could be used to generate csprob files for the IDE users out there. It would go a long way to making this usable by MonoDevelop users.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.