Global Usings Met Dotnet 6.0

Deze blogpost is een onderdeel van blogs over de nieuwe features die eraan komen voor .Net 6 en C# 10. Om gebruik te maken van deze features zul je de dotnet 6.0 SDK Release Candidate moeten installeren. Deze kun je hier vinden.

Global Usings is een concept om automatisch usings toe te voegen aan alle sourcefiles binnen een project. Het gebruik van global usings zorgt ervoor dat usings die we in veel van onze sourcefiles nodig hebben niet meer handmatig hoeven toe te voegen afhankelijk van de context van het project. Bijvoorbeeld als we een web-api project hebben en gebruik maken van het async en await patroon dan is het handig om de namespace System.Threading.Task aan je project toe te voegen als Global Namespace aangezien we dit bijna overal nodig hebben.

 

Gebruikte Setup

  • Visual studio 2022 preview 4.1
  • .Net 6.0.100-rc.1.21463.6

Auteur:

Jeroen de Knegt

Lead Cloud Software Engineering

Project aanmaken</>

In deze blog maken we gebruik van een console applicatie, deze maken we aan met .Net versie 6. Wanneer je het project aanmaakt in Visual Studio, selecteer bij framework versie “.Net 6.0” om de feature te gebruiken.

Het is ook mogelijk om via de commandline tools een project aan te maken.

dotnet new console -o "{ProjectNaam}" --Framework "net6.0

Zorg er dan voor dat je de --framework flag toevoegt met daarin net6.0

Nadat het project aangemaakt is staat er een nieuwe feature aan genaamd implicit usings. Hierover meer in een andere blog. Deze feature kan je makkelijk uitzetten door je project file te openen. En de regel  <ImplicitUsings>enable</ImplicitUsings> weg te halen.

Vervolgens is het noodzakelijk om in program.cs “using System;”toe te voegen om ervoor te zorgen dat het project correct compileert.

 

<Gebruik van de Feature>

Om Global Usings te gebruiken zet je het keyword global voor jouw using statement: “global using System;”

Er wordt niet afgedwongen in welke file je de global using plaatst en of je de global using meerdere keren toevoegt. En zoals in de screenshot te zien is hoef ik in een andere class de using niet meer te gebruiken.

Wanneer je de using wel neerzet of dezelfde global using in een andere file ook gebruikt, zal intellisense een indicatie geven dat de using of usings niet nodig zijn zoals we ook al gewend waren.

Je kan Global Usings ook combineren met de in C# 6 geintroduceerd static usings. Waardoor je bijvoorbeeld de WriteLine functie van console overal kan gebruiken.

 

<Mening>

Deze C# 10 feature zorgt ervoor dat de code files weer wat kleiner worden door het beperken van de hoeveelheid usings. Dit maakt de files leesbaarder, zeker in combinatie met andere features.

Ik zou willen adviseren om geen static Global Usings te gebruiken. Dit kan namelijk naming conflicts opleveren en verbergt voor de lezer van de code waar een functie gedefinieerd is.

Daarnaast kan dit ook nog eens onduidelijkheid geven of een method een framework methode is of een door gebruikers gedefinieerde methode, doordat ze dezelfde naam hebben.

Mijn advies zou daarnaast zijn om met je development team richtlijnen op te stellen omtrent het gebruik van Global Usings. Voorstel zou bijvoorbeeld kunnen zijn om één file aan te maken waarin je Global Usings zet bijvoorbeeld GlobalUsings.cs. Op deze manier kan je beter controleren welke Global Usings er zijn toegevoegd in plaats van dat je door de hele source code moet gaan zoeken.

 

Hierbij kan je ook nog extra regels maken omtrent welke namespaces je wilt toevoegen als Global Usings. Simpel gezegd alle namespaces toevoegen heeft geen consequenties voor de snelheid van je applicatie maar kan wel eerder voor naming conflicts zorgen.

Daarnaast krijg je ook een noemenswaardige vertraging van je builds maar met name tooling als intellisense zal het een stuk zwaarder krijgen omdat er nu bij elke file meer mogelijke afhankelijkheden bij komen. Ook de applicatie structuur zal minder makkelijk te doorgronden zijn en de kans op spaghetti code doordat er met groter gemak meer dependencies gemaakt worden tussen classes onderling kan daardoor slechter zijn voor de onderhoudbaarheid.

Advies zou dus zijn enkel gebruik te maken van Global Usings voor dotnet framework namespaces die je veel gebruikt en daarnaast misschien de namespace die je binnen een visual studio project zelf veel ondersteunt.