Coding Dojo: .NET Core op macOS en Linux - de basics (#2)

In deel 1 van deze blogserie deden we verslag over onze Coding Dojo. In deel 2 beloofden we in te gaan op de basics van de cross-platform ontwikkelervaring van .NET Core. Belofte maakt schuld, dus pak een kopje koffie erbij ga er maar even lekker voor zitten.

Deze post is er eentje uit drie delen:

De verschillende IDE’s

Er is een aantal IDE’s waar je uit kan kiezen om met .NET Core te werken:

Ten eerste is er uiteraard Microsoft Visual Studio – ten minste, voor de Windowsgebruikers. Voor MacOS is er óók een Visual Studio, maar dat is een compleet ander product (gebaseerd op Xamarin Studio), wat je dan weer niet op Windows vindt. Vergeleken met de grote broer op Windows is het vrij beperkt, maar nog altijd stukken volwassener dan Visual Studio Code.

Met het gratis Visual Studio Code, ook van Microsoft, kan je echter wel uit de voeten op Windows, MacOS én Linux. Het is meer een fancy text-editor dan een echte IDE: je kan het enigszins vergelijken met bijvoorbeeld Sublime of Atom. Het zou me overigens niet verbazen als voor die twee ook plugins beschikbaar zijn of komen die je .NET Core applicaties laat debuggen.

Eveneens op alle drie de platformen vind je Rider van JetBrains, een volwaardige IDE die zich prima kan meten met Visual Studio op Windows. Het is wel een premium product, met flinke jaarlijkse kosten in tegenstelling tot de Microsoft-producten (de Community Editions van Visual Studio zijn gratis beschikbaar). Als je echter serieus .NET wil ontwikkelen op een andere omgeving dan Windows is dit eigenlijk je enige optie.

Navigeren in je nieuwe IDE

Bij Stap 2 beginnen we met het verkennen van de IDE, dus hier zien we dan ook veel verschillen tussen de verschillende omgevingen.

We beginnen met het project te openen. In de Visual Studio’s en Rider open je InfiCoreDojo.sln, maar Visual Studio Code is een uitzondering: hier open je geen projecten, maar directory’s, een eerste teken hoe dit programma verschilt. Je zal ook snel genoeg merken dat hij een C# extension wil installeren, als je dat nog niet gedaan hebt. Zodra je dat gedaan hebt, zal hij wel de NuGet packages gaan restoren, net zoals de andere IDEs dat doen.

Laten we eens kijken naar wat van de voorbeeld-oefeningen om je nieuwe IDE te gebruiken. Alle classes met “Player” vinden? Gaan we doen!

In Rider vind je die functionaliteit in het menu onder Navigate > Class…, in Visual Studio Code heet dat Quick Open, of in het menu: Go > Go to file…. In de Visual Studio for Mac hoef je daar geen venster voor te openen, het zoekveld staat rechtsboven in beeld. De bijbehorende keyboard shortcut staat in het zoekveld vermeld. In Visual Studio 2017 kun je ofwel in de solution explorer rechtsboven in beeld zoeken of de Edit > Go To > Type feature gebruiken zoals in het screenshot.

De Go to definition-feature is dan juist weer volledig gelijk bij alle omgevingen: met een control- of command-click op IPlayerDal heb je die interface in een oogwenk geopend.

De andere kant op, Find implementations, werkt echter weer heel erg anders! Bij Rider klik je op het icon in de gutter. Als dat al het i’tje van implementation is, zal hij hem direct openen als er maar één is, of een lijstje tonen als er meer keus is. Als er meerdere opties beschikbaar zijn (omdat je cursor op die regel staat), is er een hamertje en krijg je naast de andere opties een lijstje met implementaties.

In Visual Studio 2017 is het een kwestie van rechtsklikken en kiezen voor Go To Implementation.

Visual Studio Code en Visual Studio for Mac hebben geen Find implementations-feature – daar moet je gebruik maken van Find references, te vinden met een rechtsklik op IPlayerDal.

NuGet packages

In Stap 3 kijken we naar het installeren van nieuwe NuGet packages.

Dit verschilt aanzienlijk tussen de verschillende applicaties, omdat ze blijkbaar allemaal een eigen idee hebben over wat handig is.

We beginnen in de thuishaven: Visual Studio. Rechtsklik op de Solution in de Solution Explorer rechts in beeld en selecteer Manage NuGet Packages…. Kies vervolgens voor de Browse tab en zoek naar je package. Vervolgens kun je in de detail view een versie selecteren en op Install klikken.

In Visual Studio voor Mac is het iets anders. Onder het menu Project vind je Add NuGet Packages…, waar je de packages kan toevoegen. Het is op deze manier echter niet zo duidelijk aan welk project je het geselecteerde package toevoegt – dat doet hij aan het project wat je links in de solution browser hebt geselecteerd. Handiger is om in de solution browser Dependencies > NuGet open te klappen, dan heb je gelijk een overzicht welke packages je hebt geïnstalleerd in je project. Met een rechtsklik op NuGet kan je kiezen voor Add Packages….

Rider heeft van alle IDE’s naar mijn mening de meest overzichtelijke implementatie. Middels Tools > NuGet > Show NuGet Tool Window open je de NuGet manager. Daar kan je vervolgens zoeken naar packages en deze voor je specifieke projecten toevoegen.

Als je Visual Studio Code gebruikt, zal je eerst nog een extentie moeten installeren. Er zijn er verschillende, maar geen van Microsoft zelf. Hier kies ik voor de meest gebruikte, van jmrog.

Nadat je deze extension hebt geïnstalleerd, kan je het Command Palette (View > Command Palette…) gebruiken om NuGet packages te installeren middels het Add NuGet Package commando. Vervolgens kan je zoeken, en met wat enters voor de juiste versie en project-selectie wordt de package toegevoegd.

Vervolgens ziet Visual Studio Code dat er een nieuwe package is toegevoegd en vraagt of je je packages wil restoren. Het is dus allemaal wat minder vloeiend dan de andere oplossingen.

Testen

Nu je wat code hebt getypt in je nieuwe IDE, wil je die natuurlijk ook testen. Ook dat gaat natuurlijk een beetje anders, afhankelijk van welke IDE je gebruikt. Om de screenshots een beetje interessant te houden heb ik een falende test toegevoegd. In Visual Studio Code is het vrij gemakkelijk om de tests in een enkele testclass te runnen: je klikt simpelweg op Run All Tests boven je class definitie en hij gaat los.

Als je echter een gemakkelijke manier wil om alle testclasses te runnen: die is er niet. In het Command Panel kan je het commando Tasks: Run Test Task vinden, maar zodra je die probeert te runnen, krijg je de foutmelding dat je geen testtaak hebt gedefiniëerd, met de optie om je tasks te configureren. Doe dat want dan opent hij meteen de tasks.json. Daar moet je nu een nieuwe test task toevoegen, die ziet er zo uit:

    "label": "test",
    "command": "dotnet",
    "type": "process",
    "args": [
        "test",
        "${workspaceFolder}/src/InfiCoreDojo.Api.Tests/InfiCoreDojo.Api.Tests.csproj"
    ],
    "problemMatcher": "$msCompile",
    "group": {
        "kind": "test",
        "isDefault": true
    }

Als je dit opslaat, kan je nogmaals proberen de test task te runnen en je zal zien dat het dan wel goed gaat:

Overigens is er een interessant verschil tussen de output van beide methoden: de eerste heeft duidelijk een betere integratie want middels een control/command-click kan je daar in een keer naar de falende assert springen. Bij het gebruik van de test task wordt wel met rood duidelijk gemaakt dat er iets fout gaat, maar je kan daar verder niet op klikken.

In Visual Studio for Mac vind je aan de rechterkant van het scherm een knop Unit Tests, dat de Unit Tests “Pad” opent. Als je hem daar niet vindt, kan je hem ook vinden via View > Pads > Unit Tests. Hier toont hij de tests die hij voor je heeft gevonden en kan je op Run All klikken om alle tests te runnen.

De integratie hier is gewoon goed: dubbelklik op de testnaam en je springt er meteen naar toe.

In Rider is het ook een peuleschil: rechtsklik op je testproject en kies voor Run Unit Tests. Niet veel later krijg je overzichtelijk de uitkomst medegedeeld:

Zoals je mag verwachten, is de integratie hier ook heel goed. De weergave van de resultaten is duidelijk, evenals de details van een specifieke test.

In Visual Studio is er de Test Explorer. Als die nog niet zichtbaar is, kun je via het menu Test > Windows > Test Explorer hem openen. Klik daarna op Run All om alle tests te draaien en je krijgt dit resultaat:

Ook hier is de integratie zo goed als je mag verwachten van de primaire .NET ontwikkelomgeving.

Debuggen

Fijn, je hebt die falende test gefixt (het bleek dat True toch niet False is) en nu is het tijd om je applicatie te runnen. Natuurlijk doen we dat in debug-modus, zodat we het meteen zien als er iets fout gaat (bijvoobeeld omdat je even snel een exception hebt toegevoegd voor de demonstratie).

Er zitten zeker verschillen tussen de verschillende IDE’s, maar ze laten allemaal vrij duidelijk zien waar en waarom de code is onderbroken.

Ook hebben ze allemaal een call stack, een overzicht van variabelen in de scope en de mogelijkheden om door de code te steppen. Natuurlijk kan je eenzelfde overzicht verwachten als je een normaal breakpoint zet (bij allemaal, zoals je waarschijnlijk al had verwacht: klikken in de gutter), maar dan zonder zo’n interessante exception.

Fin

Zoals je ziet, zijn er naast grote verschillen ook best grote overeenkomsten te vinden tussen de verschillende IDE’s. Natuurlijk is dit niet alles wat erover te vertellen valt, maar dit zijn toch een paar van de meest gebruikte features. Ik hoop dat deze blik je helpt met het maken van een keuze, of je misschien prikkelt een ander product te gebruiken.

Binnenkort gaan we in deel 3 nog even wat dieper in op een aantal geavanceerde onderwerpen, dus houdt onze website in de gaten! 

Op de hoogte blijven van onze updates over techniek, toffe projecten of een kijkje achter de schermen? Meld je dan aan voor onze nieuwsbrief! 

Wil je met ons je droom waarmaken?

› Kom vooral eens langs voor een kop koffie!

Wil je iets waarmaken met Infi?

Wil jij een eigen webapplicatie of mobiele app waarmee jij het bij anderen maakt?

Waargemaakt door de nerds van Infi.
Nerds met liefde voor softwareontwikkeling en die kunnen communiceren. En heel belangrijk: wat we doen, doen we met veel lol!

Wij willen het fixen. Laat jij van je horen?

Voor wie heb je een vraag?