Nuget package injects global usings

[kemsky]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Nuget package (https://www.nuget.org/packages/Telegram.Bot 22.1.3) adds dependency :

<FrameworkReference Include="Microsoft.AspNetCore.App" >

then after upgrade the following code stops compiling:

using Google.Apis.Http;

namespace Gmail.Services;

internal interface IGoogleHttpClientFactory : IHttpClientFactory // Ambiguous reference: IHttpClientFactory
{
}

Is there any way to disable transitive global usings (#32451)?

Expected Behavior

Expected no errors.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[martincostello]

The usings are added by the web SDK by design since .NET 6.

You say they're being added by a NuGet package, but not which package you're referring to.

You should be able to remove them like this in your project file:

<ItemGroup>
  <Using Remove="Microsoft.AspNetCore.Whatever" />
</ItemGroup>

[kemsky]

@martincostello, I've added package link and version.

I have the following structure:

• Project A (depends on offending Nuget package)
• Project B (depends on Project A)

Project B stops compiling after I update dependency of Project A.

<ItemGroup>
  <Using Remove="Microsoft.AspNetCore.Whatever" />
</ItemGroup>

Sure this makes code compile again but I have to put that into Project B (?!) and potentially to every other project in the solution.

This situation seems completely wrong to me. Project B has nothing to do with the offending Nuget package and its code should remain intact. The author of the Nuget package has no intention to ship transitive (in this case any) global usings. I tried different options from #32451 to disable default global asp usings but none of them worked.

It is mentioned in #32451 that adding global usings is a non-breaking change but it is 100% a breaking change. Previously Sentry SDK did the same thing: getsentry/sentry-dotnet#3105.

There should be an option to disable/override importing global usings in package reference or in the Nuget package or disable defaults in asp.

[martincostello]

As far as I'm aware, if you use <Project Sdk="Microsoft.NET.Sdk.Web"> in your project file, then you will get the default global usings included in the .NET SDK if implicit using statements are enabled. This has been the case since .NET 6 was released just over 3 years ago. It's not clear if this is the case from your issue description or not.

Ways I can think of to remove them are:

1. As I've described (which you can do in a Directory.Build.props file in the root of your solution to apply it to all the projects, rather than having to do it in each .csproj file) by removing the MSBuild <Using> items you don't want;
2. Not using implicit using statements.

Otherwise you'll need to fully-qualify whatever identifiers are causing build-breaks with the ambiguity caused by the additional usings being in scope in your code files.

using Google.Apis.Http;

namespace Gmail.Services;

- internal interface IGoogleHttpClientFactory : IHttpClientFactory
+ internal interface IGoogleHttpClientFactory : Google.Apis.Http.IHttpClientFactory
{
}

or:

using Google.Apis.Http;
+ using IHttpClientFactory = Google.Apis.Http.IHttpClientFactory;

namespace Gmail.Services;

internal interface IGoogleHttpClientFactory : IHttpClientFactory
{
}

[kemsky]

@martincostello, I don't have any references to Microsoft.NET.Sdk.Web, the only reference I have is Telegram.Bot Nuget package. Recently, it added a new dependency - <FrameworkReference Include="Microsoft.AspNetCore.App" /> and this became a breaking change today.

<Using Remove="Microsoft.AspNetCore.Whatever" /> is a temporary solution - code will break next time ASP (in this case) adds a new namespace to global usings.

Fully-qualify whatever identifiers are causing build-breaks
Not using implicit using statements

Why fix something that was not broken?

Anyway, I think the problem is clear at this point, you may close this if you want.

[martincostello]

I think your main gripe here is with Telegram.Bot - they added something to their package which brought in this by-design and expected behaviour from an ASP.NET Core perspective, which then created issues for you. They broke you by bringing a intentional change in behaviour for ASP.NET Core to your project.

[kemsky]

@martincostello, that is why I opened this issue: by-design behavior has a flaw. While it is documented and by-design I think it is unrealistic to call it "expected". Also, it is impossible to control on either side, library author simply has no choice but to introduce a breaking change even when he is aware of this issue.

[martincostello]

I'll leave the ASP.NET Core team to respond to your concerns.