HotChocolateImplicitUsings does not work in Directory.Build.props

[seangwright]

Is there an existing issue for this?

• I have searched the existing issues

Product

Hot Chocolate

Describe the bug

When I add Hot Chocolate to my project I get all of the global usings configured in the library.

These are disabled by adding <HotChocolateImplicitUsings>disable</HotChocolateImplicitUsings> to my .csproj.
If I have several projects in a solution that reference Hot Chocolate, I have to add <HotChocolateImplicitUsings>disable</HotChocolateImplicitUsings> to every single project because this setting doesn't appear to work when I add it to my solutions' Directory.Build.props.

I would appreciate being able to not have to disable global usings that I never asked for. I'm glad I can disable them when including Hot Chocolate, but I wish I could disable them globally with Directory.Build.props to make project maintenance easier.

Steps to reproduce

1. Create a C# .NET solution with multiple projects all referencing the HotChocolate NuGet package
2. Add <HotChocolateImplicitUsings>disable</HotChocolateImplicitUsings> to the Directory.Build.props for the solution
3. See that the global usings are still added

Relevant log output

No response

Additional Context?

I found this setting in a GitHub issue after adding Hot Chocolate caused my project to stop building because Hot Chocolate types conflicted with types already in my application!

I wish adding a NuGet package (without using any of it's types in my code) didn't cause my project to stop compiling 😔.

In my case, it's the GreenDonut.Result type that is conflicting with a Result type I have in my project.

Version

13.7.0

[tobias-tengler]

@michaelstaib your response doesn't seem to match the problem. Did you perhaps comment on the wrong issue / linked the wrong PR for resolution?

I'm running into the same original problem integrating Hot Chocolate into our Monolith, where each usage of System.IO.Path is now ambiguous with HotChocolate.Path. We're on 13.9.0.
I'd love to be able to disable the the global usings without having to touch hundreds of places. I agree with the issue author that global usings should be opt-in.

[michaelstaib]

This HotChocolateImplicitUsings>disable</HotChocolateImplicitUsings does not work?

[michaelstaib]

It is opt-in. There is a global opt-in in .Net and a package by package opt-out.

[tobias-tengler]

Yes. <HotChocolateImplicitUsings>disable</HotChocolateImplicitUsings> doesn't seem to have any effect in our Directory.Build.props. If I add it in a <PropertyGroup> inside of a .csproj it works though.

What do you mean by global opt-in in .NET? I can't remember opting in at one point.

[seangwright]

Yes. <HotChocolateImplicitUsings>disable</HotChocolateImplicitUsings> doesn't seem to have any effect in our Directory.Build.props. If I add it in a <PropertyGroup> inside of a .csproj it works though.

Currently (13.x) you need to add this MSBuild prop to each .csproj file for projects with this using/name conflict.
The improvement to use Directory.Build.props is part of v14.0.0 (not yet released).

What do you mean by global opt-in in .NET? I can't remember opting in at one point.

It's a little confusing, but <ImplicitUsings>enable</ImplicitUsings> doesn't just enable the ability to use implicit usings, it enables it for all of .NET, which has predefined implicit usings in SDK style projects, and enables it for all NuGet packages that are part of the project.

This is why @michaelstaib said there's a "global opt-in" and a package by package opt-out.

You can't enable implicit usings for only 1 package and then have it disabled for all other packages and sources - including .NET framework.

[michaelstaib]

I think I can fix this ... I will report back.

[tobias-tengler]

Awesome. Thanks Michael!

[michaelstaib]

https://github.com/ChilliCream/graphql-platform/releases/tag/13.9.1-p.1

[michaelstaib]

Please test and give feedback

[tobias-tengler]

Can confirm that it works in Directory.Build.props with13.9.1.-p.1 :)