Additional C# global imports

@DamianEdwards

There were some additional discussions on what global imports should or should not be included in the base .NET SDK. Specifically, there were concerns about:

✅ = currently included
❌ = not currently included

✅ System.Net.Http: The contention is that this is used for web concerns so maybe it belongs in the Web SDK instead. However, it's also very frequently used in general, even console apps.
❌ System.Net: This is often used in combination with System.Net.Http. We should put this in where-ever we end up putting System.Net.Http
❌ System.Diagnostics: This has been used in some of the Web templates. Is this a common enough concern to be included in an SDK, be it the base .NET SDK or Web SDK?
❌ System.Text: This is another commonly used namespace that we can consider for the base .NET SDK. Historically, this has been used

In the interest of ensuring all discussion is happening in the same place, let's use this issue as much as possible to track discussions. @DamianEdwards @RussKie.

FYI @davidfowl @halter73 @KathleenDollard @pranavkm @terrajobst

Feel free to tag anyone else who would be interested in this dicsussion. I've only included folks who have had additional input on the current import list.

Here's the PR that removes using statements from the web templates based on what's implicitly added by the SDK now. The namespaces that are left are a potential place to start WRT to what to consider for further inclusion.

Also, as a reference here's the currently included list:

Base .NET SDK

    <Import Include="System" />
    <Import Include="System.Collections.Generic" />
    <Import Include="System.IO" />
    <Import Include="System.Linq" />
    <Import Include="System.Net.Http" />
    <Import Include="System.Threading" />
    <Import Include="System.Threading.Tasks" />

Web SDK (also includes everying in the base .NET SDK)

    <Import Include="System.Net.Http.Json" />
    <Import Include="Microsoft.AspNetCore.Builder" />
    <Import Include="Microsoft.AspNetCore.Hosting" />
    <Import Include="Microsoft.AspNetCore.Http" />
    <Import Include="Microsoft.AspNetCore.Routing" />
    <Import Include="Microsoft.Extensions.Configuration" />
    <Import Include="Microsoft.Extensions.DependencyInjection" />
    <Import Include="Microsoft.Extensions.Hosting" />
    <Import Include="Microsoft.Extensions.Logging" />

Worker SDK (also includes everying in the base .NET SDK)

    <Import Include="Microsoft.Extensions.Configuration" />
    <Import Include="Microsoft.Extensions.DependencyInjection" />
    <Import Include="Microsoft.Extensions.Hosting" />
    <Import Include="Microsoft.Extensions.Logging" />

@danroth27

Seems like we missed the Blazor SDK for default usings. This change removed usings from the blazorwasm template (Microsoft.Extensions.*) but we didn't do the default usings there. I think we should fix it in the sdk instead of putting the usings back and additionally add more default usings for blazor wasm.

This currently is blocking SDK merges into the installer dotnet/installer#11100

PS: I've sent a PR to add Microsoft.Extensions only. I'm sure we'll want to add more

cc @danroth27 @SteveSandersonMS @pranavkm @javiercn

I think we should fix it in the sdk instead of putting the usings back and additionally add more default usings for blazor wasm.

That creates some inconsistently between Server and WASM. Would we feel ok adding things to the Server's csproj to make them more consistent?

@pranavkm

@pranavkm can you clarify? Blazor server uses the web sdk no? Which has these usings and more...

Do you have a list in mind that would go in the WebAssembly SDK? I'd think most of these would be from the Microsoft.AspNetCore.Components.* namepace?

Do you have a list in mind that would go in the WebAssembly SDK? I'd think most of these would be from the Microsoft.AspNetCore.Components.* namepace?

I think that's better determined by the Blazor team. Also it seems like most of those things come from the package so maybe it doesn't make sense in the sdk?

For reference, a quick GH search revealed 3M, 6M, 9M, and 9M results for items 1, 2, 3, and 4 in the original descriptions, respectively. For reference, Generic, IO, and Linq have 56M, 14M, and 36M, respectively.

Example query: https://github.com/search?q=%22System.Collections.Generic%22

The implicit namespace import caused a build break in crossgen2 because it has a low level implementation of LINQ (that has better perf characteristics than LINQ for people who don't do things like Where().Where().Select().Min()).

It was very much not obvious what caused it, even for a bunch of seasoned .NET devs. dotnet/runtime#55855

Please consider all the current (and future!) names of types in all of the discussed namespaces, especially for things that go into the base SDK. I don't particularly care about the special-purpose SDKs - just for the base SDK. We market .NET as "A developer platform for building all your apps.". Does System.Net.Http make sense in a game? An IoT app? The default-included namespaces better make sense there or they just limit the number of available identifiers.

The prosed namespaces have some very common names in them that are going to conflict with existing things in the ecosystem (and if the conflicts happens to be in a type name within a NuGet package, the break is going to cascade out of that). People will no longer be able to use the common names because .NET essentially "reserves" them (causing extra friction if someone wants to use the common word in their own namespace going forward).

We have namespaces exactly because of this - to avoid conflicts.

E.g. System.Diagnostics has a Process class. So does Chocolatey, or Microsoft Terminal, or azure pipelines agent. The name Process makes sense there.

System.IO has a File class. Well so does Microsoft IIS Administration and countless others.

Basically, going overboard with the number of default-included namespaces we're making it hard to use common words as class names, while lacking any context whatsoever (base SDK is included for any app any developer any platform).

Frankly I'm finding it hard to justify including anything besides System in the base SDK. Even System is problematic as Jared would tell you, but I'm much less sympathetic to developers who name their classes String or Int32 than to those having their own Directory, Activity, Monitor, Timeout, or Task (that one is already hurting us).

@RussKie

@RussKie Glancing at your winforms PR, it looks like most of the updates were removing using statements for the same namespaces that were included in implicit global usings. As I understand it, you should not have needed to make those changes. I think you were probably using an older version of the Roslyn compilers. With more recent versions, those usings would not have caused errors and you wouldn't have needed to make most of those changes.

As I understand it, you should not have needed to make those changes. I think you were probably using an older version of the Roslyn compilers. With more recent versions, those usings would not have caused errors and you wouldn't have needed to make most of those changes.

Yep see #18459 (comment)

We're planning to make some changes to the implicit usings feature in rc.1 based on the feedback we've received here and elsewhere. Check out #19521 for details.

Those namespaces shouldn't be accessed if not asked for. IntelliSense currently propose all classes from those namespaces in empty class file. VS marks System.IO reference as to be removed. This is really confusing.

VS marks System.IO reference as to be removed

Can you elaborate here?

VS marks System.IO reference as to be removed

Can you elaborate here?

System.IO (as an example) is globally accessible after update to net6-preview7. So all those using directives are marked as unnecessary. Sorry, I should've been more specific.

Ah yes, that's by design when this feature is on.

I'm gonna close this issue as there were major updates made and it doesn't reflect the current state of things. Use this issue to give more feedback:

#19521

It is but I would read it first then open another issue with more details if that isn't satisfying

The potential for abuse should be more than enough to limit this to an opt in feature, if this is something that you feel this strongly about

Starting in rc1, it is a opt-in feature. The other issue goes over some of the implementation details about this.

Navigation Menu

Repository navigation

Additional C# global imports #18825

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Additional C# global imports #18825

Description

Activity

DamianEdwards commented on Jul 9, 2021

JunTaoLuo commented on Jul 9, 2021

davidfowl commented on Jul 10, 2021

pranavkm commented on Jul 12, 2021

davidfowl commented on Jul 12, 2021

pranavkm commented on Jul 12, 2021

davidfowl commented on Jul 12, 2021

marcpopMSFT commented on Jul 19, 2021

19 remaining items

MichalStrehovsky commented on Aug 2, 2021

MichalStrehovsky commented on Aug 3, 2021

dsplaisted commented on Aug 3, 2021

davidfowl commented on Aug 3, 2021

DamianEdwards commented on Aug 5, 2021

SimonDD7 commented on Aug 26, 2021

davidfowl commented on Aug 26, 2021

SimonDD7 commented on Aug 26, 2021

davidfowl commented on Aug 26, 2021

davidfowl commented on Sep 13, 2021

davidfowl commented on Sep 13, 2021

pranavkm commented on Sep 13, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions