Open sin-ack opened 5 months ago
I'm not sure how this list is generated so It's hard to tell if it would be worth the maintenance cost to add this feature to rules_dotnet. This can be worked around by the end user by using a bazel macro around the csharp_library/binary
fairly easily.
If you have any further information on how this list is generated then that would help with making the decision.
I actually looked into it a little bit. The way it works is as follows:
ImplicitUsings
is set to enabled
here, which enables it for everyone using Microsoft.NET.Sdk
and its children:.props
file which contains a conditional ItemGroup
that adds the Using
statements:{AssemblyName}.GlobalUsings.g.cs
file:https://github.com/dotnet/sdk/blob/f48021c3202146e8ba6c8364fc619b31bef84d89/src/Tasks/Microsoft.NET.Build.Tasks/GenerateGlobalUsings.cs#L8 https://github.com/dotnet/sdk/blob/f48021c3202146e8ba6c8364fc619b31bef84d89/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateGlobalUsings.targets#L23
I might be incorrect, but from what I can understand, the only "proper" ways to get these Using
targets is:
rules_dotnet
, and updating them with new .NET releases<Using />
tags (brittle)I've just hit this too, my build is failing. I'm not quite sure what to do.
@peakschris You wrap the rules with your own macro where you provide a source file with the global imports. But I think I would also accept an contribution that adds the global imports in a maintainable way.
What I did at work for now:
GlobalUsings
at the top level, containing files like Microsoft.NET.SDK.cs
.GlobalUsings.g.cs
contents that would be generated for that SDK, along with a link to which .props
file in https://github.com/dotnet/sdk they are generated from.GlobalUsings
folder, and relatively symlinks the SDKs they use, i.e. a project using the Microsoft.NET.SDK.Web
SDK will symlink both Microsoft.NET.SDK.cs
and Microsoft.NET.SDK.Web.cs
.(Make sure to add <ImplicitUsings>false</ImplicitUsings>
to your csproj
files to avoid duplicates in the MSBuild workflow, if you intend to have one.)
Want this feature to simplify the migration. Almost all of my projects used this feature.
It works fine to create an extra .GlobalUsings.g.cs file and add to the project that contains the using statements. This can be added explicitly or in a wrapped rule:
MyLibrary.GlobalUsings.g.cs:
global using global::System;
global using global::System.Collections.Generic;
global using global::System.IO;
global using global::System.Linq;
But it would be far better if this file was auto-generated in the same way that msbuild does.
I know this issue is a little old, but the team I work with implemented support for this as suggested by @purkhusid - we intend to contribute it, but it needs some tidying to make it more generally manageable. In particular, we want to provide a better way to manage the namespaces across multiple SDKs and framework versions.
However it isn't super complicated to implement, so an outline for what we did might be helpful:
We also added an attribute to allow other global usings to be supplied (like the <Using>
msbuild element), simply adding them to the list of implicit namespaces.
The code for the genrule isn't especially complex either:
def _create_global_usings_file(filename, namespaces):
content = "\n".join(["global using global::%s;" % ns for ns in namespaces])
native.genrule(
name = filename.replace(".cs", ""),
outs = [filename],
cmd = "echo '" + content + "' > $@",
)
Since
rules_dotnet
doesn't run MSBuild, theUsing
directives added by the Task files in the .NET SDK are not handled, causing the build to fail unless the auto-generated{Assembly}.GlobalUsings.g.cs
is included insrcs
.For the time being, I'm hand-maintaining the following file:
But obviously this isn't very nice. Would there be anyway to generate this file through Bazel somehow?