Additional C# global imports

[JunTaoLuo]

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

1. ✅ 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.
2. ❌ 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
3. ❌ 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?
4. ❌ 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.

[DamianEdwards]

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.

[JunTaoLuo]

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

1. 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" />

2. 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" />

3. 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" />

[davidfowl]

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

[pranavkm]

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?

[davidfowl]

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

[pranavkm]

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?

[davidfowl]

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?