blexin

Sviluppo
Consulenza e
Formazione IT


Blog

Evolvi la tua azienda

Vediamo insieme come .NET Core abbia reso Visual Studio solo una delle possibili scelte tra i tool di sviluppo software

Vivere senza Visual Studio: sì, si può!

Mercoledì 11 Marzo 2020

Ogni volta che partecipo ad un evento Microsoft come speaker, vedo ancora persone stranite dal fatto che utilizzo un MacBook Pro. La prima cosa che pensano è che probabilmente faccio sviluppo mobile e che quindi avrò una macchina virtuale Windows, con cui utilizzo Visual Studio. Quantomeno, sono finite le domande esplicite del tipo “che ci fa un microsoftiano con un dispositivo Apple?”. Forse le guerre di religione stanno lasciando il passo al pragmatismo, o forse finalmente comincia a diventare più diffusa la notizia che dal 2016 abbiamo .NET Core, e possiamo sviluppare applicazioni ASP.NET da Mac.

Una delle grandi novità di .NET Core è la Command Line Interface (CLI), che ci permette da riga di comando di creare progetti, compilarli, eseguirli, scaricare librerie e anche pacchettizzare codice da pubblicare su NuGet. Ma si sa, gli sviluppatori Microsoft storicamente evitano come la peste due cose: JavaScript e la riga di comando. E, soprattutto, continuano ad illudersi che una preview di Visual Studio possa sostituire il risultato in esecuzione di un'applicazione. Siamo nel 2020, il mercato è cambiato, il modo di sviluppare le applicazioni è completamente diverso oggi, e non stare al passo può essere fatale.

La prima alternativa cross-platform a Visual Studio è Visual Studio Code. È un editor di codice, non un IDE (Integrated Development Environment), ma ha almeno tre caratteristiche che lo rendono il mio strumento di sviluppo preferito:

  • È gratuito e Open Source;
  • Multipiattaforma;
  • È fortemente personalizzabile grazie alle estensioni che potete scaricare dal marketplace.

Non è un editor qualsiasi, è pensato per lo sviluppo, quindi ha un supporto nativo per la gestione del codice sorgente (Git), un ambiente di debug (configurabile) e lavora sul concetto di cartella. Chi lavora con Visual Studio è abituato al concetto di solution, che è un artefatto strettamente legato al mondo .NET. Con l’utilizzo di altri stack tecnologici, ad esempio NodeJS, il concetto di soluzione non esiste, quindi Visual Studio Code preferisce lavorare su singole cartelle o workspace (insieme di cartelle).

Tecnicamente, parliamo di un’applicazione JavaScript che gira dentro Electron, un progetto molto interessante che permette di “inscatolare” un'applicazione JavaScript, HTML e CSS in un contenitore Desktop multipiattaforma. Se vi interessa approfondire, ho tenuto un talk sull’argomento a varie conferenze in Italia, di cui qualcuna ancora disponible su YouTube.

Mancano, ovviamente, tutti i wizard di creazione di progetti, ma fornisce uno o più terminali integrati nell’applicazione (bash, Powershell, ecc.), da cui possiamo lanciare i comandi che ci servono. Se avete uno schermo molto grande, potete anche affiancare le finestre del terminale in modo da rendere più agevole l’avvio di diversi comandi in contemporanea. 

L’idea è, quindi, di partire dalle vostre esigenze e configurare l’ambiente come preferite. Supponiamo, ad esempio, di essere sviluppatori C# e voler configurare Visual Studio Code per la realizzazione di applicazioni .NET Core, per prima cosa andremo ad installare i seguenti plug-in:

Per vedere in funzione i plug-in, andiamo a crearci un progetto WebAPI con la CLI di .NET Core, e apriamo il progetto in Visual Studio Code:

dotnet new webapi -o backend
code .

Visual Studio Code si accorge che c’è un progetto .NET Core, proprio perché abbiamo installato l’estensione ufficiale C#, e ci chiede se vogliamo configurare l’ambiente per il debug (il file launch.json) e l’automatizzazione dei task (task.json):

Viene quindi creata una cartella .vscode con i file di configurazione:

A questo punto ci basta mettere un punto di interruzione nel codice e lanciare il debug:

Ma spingiamoci oltre:aggiungiamo un client Angular al nostro progetto direttamente dal terminale integrato, lanciando il comando di creazione di un nuovo progetto Angular:

In attesa che il wizard termini il suo lavoro, andiamo ad installare i plugin a supporto dello sviluppo in Angular. Il modo più rapido è installare Angular Essentials, di John Papa, che è a tutti gli effetti un Extension Pack, installa cioè tutti i plug-in che vi possono essere utili nello sviluppo con Angular.

Di solito, preferisco debuggare la parte Angular direttamente nel browser, ma possiamo configurare Visual Studio Code per agganciare il debugger di Chrome. Installiamo l’estensione ufficiale di Microsoft e nel pannello di Debug aggiungiamo una configurazione (launch.json) di tipo Launch Chrome:

A questo punto, ci basta cambiare la porta in 4200 e impostare la webroot sulla cartella frontend. Mettiamo un punto di interruzione, lanciamo il front-end dal terminale con il comando ng serve e agganciamo il debugger del browser dalla sezione debug:

Possiamo anche chiedere a Visual Studio Code di lanciare per noi il front-end, utilizzando lo script npm start da un apposito task nel file tasks.json:

{
    "version": "2.0.0",
    "tasks": [
          …
          {
              "label": "start-frontend",
              "type": "npm",
              "script": "start",
              "path": "frontend/",
              "isBackground": true,
              "problemMatcher": {
                  "owner": "typescript",
                  "source": "ts",
                  "pattern": "$tsc",
                  "background": {
                      "activeOnStart": true,
                      "beginsPattern": {
                          "regexp": "(.*?)"
                      },
                      "endsPattern": {
                          "regexp": "Compiled"
                     }
                 }
             }
         }
     ]
}

La sezione problemMatcher ci permette di capire quando un task è finito anche se, in realtà, resta in attesa, nel nostro caso quando l’output contiene “Compiled”. A quel punto, possiamo aprire il browser e agganciare il debugger utilizzando la configurazione precedente, a cui aggiungiamo il preLaunchTask con il nome del task appena creato:

{
   "type": "chrome",
   "request": "launch",
   "preLaunchTask": "start-frontend",
   "name": "Launch Chrome",
   "url": "http://localhost:4200",
   "webRoot": "${workspaceFolder}/frontend"
},

Una volta ultimata la nostra applicazione arriva il momento di distribuirla. Utilizzate Azure? Niente di più semplice: installiamo il plug-in Azure Tools, che aggiunge un’intera nuova sezione al nostro editor:

Posso continuare all’infinito, aggiungendo il supporto per Docker e Kubernetes per esempio, ma penso di aver reso l’idea. Finiamo con altre due funzionalità senza le quali ormai la mia vita da sviluppatore, docente e speaker non sarebbe la stessa. La prima è la possibilità di crearci i nostri snippet, semplicemente cliccando sul menu principale, sezione Preferences > Users Snippets: vi sarà richiesto di scegliere il linguaggio per il quale volete creare degli snippet, in modo da aprire per voi il corrispondente file JSON di configurazione:

Creiamo ad esempio uno snippet C# che aggiunge la configurazione di un DbContext EntityFramework che usa SqlServer come database:

"DbContext Sql Server": {
   "prefix": "demo-add-dbcontext-sqlserver",
   "body": [
      "var connection = @\"Server=$1;Database=$2;User=$3;Password=$4\";",
      "",
      "services.AddDbContext<$5>(",
      "\topt => opt.UseSqlServer(connection));"
    ],
   "description": "DbContext Sql Server"
}

Diamo un nome allo snippet, specifichiamo il prefisso (nel nostro caso demo-add-dbcontext-sqlserver) con cui vogliamo richiamarlo, scriviamo sotto forma di stringa il corpo dello snippet, aggiungiamo una descrizione che verrà riportata dall’IntelliSense e il gioco è fatto. Molto utile la possibilità di usare i segnaposto numerati sfruttando il simbolo $: ci permette di aggiungere nel body i punti che vogliamo rendere personalizzabili e l’ordine delle tabulazioni con cui spostarci tra le modifiche:

Se mi avete visto a qualche evento fare live code, adesso conoscete il mio segreto!

Ultimo, ma non per importanza, è il Live Share: la possibilità di lavorare con un vostro collega sullo stesso sorgente in Pair Programming a distanza, una delle ragioni che ha portato Facebook a scegliere Visual Studio Code come tool di sviluppo. Installando l’estensione e cliccando sull’icona del live share nella barra di stato nel footer, vi verrà richiesto di autenticarvi con un account Microsoft o GitHub, a quel punto sarete connessi alla piattaforma e verrà copiato negli appunti il link da inviare al vostro collega per cominciare la sessione di condivisione:

Ci tengo a concludere, chiarendo che questo modo di sviluppare non è per tutti, richiede una buona conoscenza della riga di comando e di cosa avviene dietro le quinte. In un ambiente di lavoro, la produttività è fondamentale, quindi se Visual Studio vi rende più produttivi che ben venga, anche se, a mio parare, non è una scusa per ignorare quello che succede dietro le quinte!

Happy coding!

Autore

ISCRIVITI ALLA NEWSLETTER

Servizi

Evolvi la tua azienda