Alessandro Del Sole's Blog

{ A programming space about Microsoft® .NET® }
posts - 1907, comments - 2047, trackbacks - 352

My Links

News

Your host

This is me! Questo spazio è dedicato a Microsoft® .NET®, di cui sono molto appassionato :-)

Cookie e Privacy

Disabilita cookie ShinyStat

Microsoft MVP

My MVP Profile

Microsoft Certified Professional

Microsoft Specialist

Xamarin Certified Mobile Developer

Il mio libro su VB 2015!

Pre-ordina il mio libro su VB 2015 Pre-ordina il mio libro "Visual Basic 2015 Unleashed". Clicca sulla copertina per informazioni!

Il mio libro su WPF 4.5.1!

Clicca sulla copertina per informazioni! E' uscito il mio libro "Programmare con WPF 4.5.1". Clicca sulla copertina per informazioni!

These postings are provided 'AS IS' for entertainment purposes only with absolutely no warranty expressed or implied and confer no rights.
If you're not an Italian user, please visit my English blog

Le vostre visite

I'm a VB!

Guarda la mia intervista a Seattle

Follow me on Twitter!

Altri spazi

GitHub
I miei progetti open-source su GitHub

Article Categories

Archives

Post Categories

Image Galleries

Privacy Policy

Roslyn e .NET Core: code generation col compilatore C# su Linux, Mac e Windows (con Visual Studio Code)

.NET Core è il runtime modulare, open source e cross-platform che consente di sviluppare applicazioni .NET con C# che girino su Linux, Mac e Windows.

Il fatto che si possa scrivere codice C# (e non solo eseguirlo) su altri sistemi operativi presuppone che il compilatore stesso sia ormai cross-platform. Roslyn, ovvero .NET Compiler Platform, tra le sue mille peculiarità porta i compilatori open source C# e VB con le loro rich code analysis APIs su Linux e Mac, oltre che già su Windows. In realtà, non tutte le librerie di Roslyn sono state ancora rese cross-platform, ma il compilatore e ciò che serve a fare code generation ed emit di assembly, sicuramente si.

L'obiettivo è quindi quello di creare un'applicazione .NET Core e chiamare il compilatore C# per fare code generation e analisi su Linux, Mac e Windows. Come IDE utilizzerò, ovviamente, Visual Studio Code. In un prossimo post vedremo come fare la stessa cosa con Visual Studio for Mac. Su Visual Studio 2017 è troppo facile :-)

Prerequisiti

1. Ubuntu 16.04, o fisico o in virtual machine. Io ho una VM su Hyper-V. Opzionale. Vanno bene anche altre "distro", ovviamente farete attenzione al punto 3.
2. Un Mac, opzionale
3. Un PC con Windows
4. .NET Core SDK con la command line interface. E' necessaria una delle versioni che supporti le solution MSBuild e non più project.json. Userò la v 1.0 preview 4. Da questa pagina potete selezionare l'installazione che fa al caso vostro, che ripeterete su tutti i sistemi su cui intendete provare.
5. Visual Studio Code e un minimo di dimestichezza con esso. Vi rimando agli articoli presenti su VB T&T.

Una raccomandazione: seguite le istruzioni almeno per i prerequisiti per Mac e Linux, poi per il download della versione affidatevi al link di cui sopra.

Windows

Su Windows è tutto più familiare. Con un command prompt all'interno di una cartella, digito la seguente sequenza per creare una directory e all'interno un'applicazione Console C# per .NET Core (dove crossroslyn sarà il nome esemplificativo del progetto):

> md crossroslyn
> cd crossroslyn
> dotnet new


Viene creato un progetto chiamato crossroslyn.csproj (in generale, il progetto prende il nome della cartella). NON chiudo il command prompt, e apro la cartella in Visual Studio Code e, all'interno del file .csproj, vado ad aggiungere i due seguenti riferimenti a pacchetti NuGet che mi servono:
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="2.0.0-rc2" />
<PackageReference Include="System.Runtime.Loader" Version="4.3.0" />
Il primo è il pacchetto NuGet relativo al compilatore C# e alle API di code generation e code analysis. Il secondo servirà poi per fare reflection. Nel frattempo, Code vi chiederà il permesso di creare file che gli servono per gestire la cartella e vi suggerirà di scaricare le estensioni appropriate, se non presenti (es. C# e debugger .NET). Allo stato attuale, Visual Studio Code non va molto d'accordo con le preview di .NET Core e quindi il comando di restore dei pacchetti non va. Ergo, chiudiamo Code, torniamo al command prompt e digitiamo:

> dotnet restore

Questo eseguirà il corretto ripristino dei pacchetti. Riapriamo Code sulla cartella (non è casuale farvi chiudere e riaprire l'IDE). Su GitHub si parla del fatto che Code supporterà presto le solution MSBuild e questi salti non saranno più necessari.

Ora consideriamo il seguente, lungo listato relativo al file Program.cs. In sintesi, parto da una stringa che contiene una rappresentazione di una classe statica con un metodo che calcola l'area di un cerchio, dato un raggio hard-coded. Il codice viene trasformato in SyntaxTree dal metodo SyntaxFactory.ParseSyntaxTree affinché il nostro testo diventi codice sorgente comprensibile al compilatore. Viene chiamato un metodo PrintDiagnostics che si occupa di analizzare eventuali errori/warning all'interno del codice. Dopo il listato mi soffermerò su questo metodo e sulla parte di code generation.

using System;
using Microsoft.CodeAnalysis.CSharp;
using Microsoft.CodeAnalysis;
using System.Linq;
using System.Runtime.Loader;
using System.Reflection;
using System.IO;

class Program
{
    public static void Main(string[] args)
    {
        const string code = @"using System; 
using System.IO; 

namespace MathFunctions 

 public static class MathHelper
 { 
    public static void CalculateCircleArea() 
    { 
        double radius = 10;
        double result = radius * radius * System.Math.PI;
        Console.WriteLine(result.ToString()); 
    } 
  } 
}"
;

        // Ottiene un SyntaxTree
        var tree = SyntaxFactory.ParseSyntaxTree(code);
        Console.WriteLine(tree);
        PrintDiagnostics(tree);

        var compilation = CSharpCompilation.Create("mylib.dll").
            WithOptions(
                new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary)).
            AddReferences(MetadataReference.CreateFromFile(typeof(object).
            GetTypeInfo().Assembly.Location)).
            AddSyntaxTrees(tree);

        var fileName = "mylib.dll";
        var path = Path.Combine(Directory.GetCurrentDirectory(), fileName);
        compilation.Emit(path);

        // Non ancora totalmente supportato su Mono
        var asm = AssemblyLoadContext.Default.LoadFromAssemblyPath(path);
        asm.GetType("MathHelper").GetMethod("CalculateCircleArea").Invoke(nullnew object[] { "" });
        Console.ReadLine();
    }

    private static void PrintDiagnostics(SyntaxTree tree)
    {
        var diagnostics = tree.GetDiagnostics();

        if (diagnostics.Any())
        {
            foreach (var diag in diagnostics)
            {
                Console.WriteLine($"{diag.GetMessage()} {diag.Location.GetLineSpan()}");
            }
        }
    }
}
PrintDiagnostics ottiene eventuali oggetti diagnostici dal SyntaxTree, come errori e warning. Se presenti, per ciascuno mostra il messaggio completo e la relativa posizione riga/colonna all'interno del nostro codice. Sono informazioni che ci da il compilatore. Notevole, no?

L'oggetto CSharpCompilation viene usato per creare un assembly con una serie di opzioni, come il fatto che si tratti di una dll, aggiungendo un riferimento al namespace che definisce object (System, quindi) e a cui viene aggiunto il SyntaxTree generato. Il metodo Emit di CSharpCompilation genera fisicamente la .dll. Per caricarla, usiamo l'oggetto AssemblyLoadContext, classe singleton, e il suo metodo LoadFromAssembly. Infine ricorriamo a classiche tecniche di reflection come GetType, GetMethod e Invoke per eseguire il codice recuperato dall'assembly.

Se ora avviamo l'applicazione, nella finestra di output vedremo dapprima il testo del codice tramutato in SyntaxTree, da ultimo il calcolo matematico richiesto, ottenuto invocando un oggetto generato a partire dalla compilazione del nostro codice/testo C#, sfruttando Roslyn:




Con un breakpoint potrete anche facilmente esaminare il contenuto delle variabili locali, tra cui quella che contiene il SyntaxTree e tutte le relative informazioni. Ora proviamo a vedere che succede se dal codice/testo tolgo un ; e una }:



Due cose interessanti: la prima è che il compilatore riporta i suoi messaggi diagnostici e la posizione in cui l'issue si verifica, come potete vedere dalla figura sopra. La seconda è che, nonostante nel codice ci siano degli errori, il compilatore ha comunque generato un syntax tree. Non verrà di fatto compilato, ma questo ci da l'idea di come il compilatore rappresenti con estrema fedeltà il sorgente/testo.

Nota bene, anzi benissimo: quella vista è la più essenziale e semplice dimostrazione di code generation che si possa fare. Con Roslyn possiamo ottenere SyntaxNode di un certo tipo, elaborarli, riscriverli, iniettare refactoring, ecc. ecc. Ok? Ok!

Mac OS

Il bello di .NET Core è che si comporta analogamente su tutti i sistemi. Su Mac OS, creata una cartella, la apriamo nel Terminal. Digitiamo semplicemente:

> dotnet new

Apriamo Visual Studio Code e ripetiamo gli stessi passaggi visti per Windows per l'aggiunta dei due pacchetti NuGet, quindi torniamo nel terminal e digitiamo:

> dotnet restore

Apriamo la cartella con VS Code. E' probabile che, oltre a suggerirvi le estensioni richieste tra cui il debugger Mono, la prima volta Code debba scaricarsi le librerie di Mono. Ad ambiente pronto, riscriviamo esattamente lo stesso codice visto prima e avviamo il debug esattamente allo stesso modo:




In questo caso si vede sia il syntax tree che i diagnostics. Signore e signori, avete appena usato il compilatore C# su Mac!

Linux/Ubuntu

Provate a indovinare? Esatto... stessi passaggi. Tramite il File Manager di Ubuntu creiamo una cartella, la apriamo col Terminal e digitiamo:

> dotnet new

Apriamo la cartella con Visual Studio Code, aggiungiamo i due pacchetti NuGet, torniamo al Terminal e digitiamo:

> dotnet restore

Stesso codice di cui sopra, né più né meno. Eseguiamo, et voilà:



In questo caso vediamo il risultato del calcolo ottenuto chiamando il codice compilato nella .dll. Signore e signori, avete appena invocato il compilatore C# su Ubuntu!

Conclusioni

Occhio che come dicevo all'inizio alcune librerie di Roslyn non sono state ancora portate su Mac e Linux, ma la strada è buona. Potete comunque invocare il compilatore, generare e compilare codice, eseguirlo e caricare assembly. Oltre alle operazioni di code analysis e refactoring da implementare. 

Alessandro

Print | posted on giovedì 29 dicembre 2016 23:26 | Filed Under [ .NET Framework ]

Powered by:
Powered By Subtext Powered By ASP.NET