Un articolo per gli Absolute Beginners, che risponde alla domanda: Da dove comincio? per chi si avvicina per la prima volta a .NET e per chi non ha mai scritto un programma in vita sua. Gli Argomenti: Cos’è il Framework .NET, Cosa c’è dentro, Cos’è un Namespace, Come creare il vostro primo progetto, Qualche nozione sull’interfaccia di Visual Studio .NET, Creare una Soluzione, Creare un progetto Console, Il primo programma.
Che cos’è .NET:
Sostanzialmente, .NET è un infrastruttura per la creazione di programmi, non per nulla il componente fondamentale su cui si basa si chiama .NET Framework (framework=infrastruttura). Ha iniziato a prendere corpo alla fine degli anni novanta, è stato pubblicato nella versione 1.0 in beta a fine 2000, rilasciato in versione definitiva nel gennaio 2002. La versione 3.0 è stata pubblicata da alcuni mesi ed è installata automaticamente sulle macchine con sistema operativo Windows Vista, la sua versione 3.5 (o forse 4.0) uscirà nel 2008.
Il sistema di sviluppo fornito da Microsoft, che utilizzeremo per gli esempi in tutti gli articoli pubblicati da chi scrive, è Microsoft Visual Studio 2005 cui seguirà Microsoft Visual Studio 2008 (Orcas) nella versione Professional. E’ possibile scaricare gratuitamente dal sito Microsoft le versioni Express del sistema di sviluppo per tutti i linguaggi di programmazione Microsoft, questa versione gratuita di Visual Studio fornisce la stessa infrastruttura della versione Professional con meno gadget, ma è già sufficientemente avanzata da permettervi di imparare ad usare VB o C# e realizzare i vostri primi programmi.
Per coloro che volessero provare con uno strumento open source, esiste SharpDevelop, ambiente di sviluppo per .NET in solo linguaggio C#.
Inoltre, se voleste utilizzare .NET con Linux, il .NET Framework è una specifica pubblica ed è stata tradotta per buona parte dal gruppo del progetto Open Source MONO.
Cosa c’è dentro al .NET Framework
Il .NET Framework è una ricchissima e bene organizzata serie di librerie in codice Managed (e in parte anche Unmanaged per questioni di interoperabilità) che fornisce ai programmatori una estesa serie di classi che permettono di far dialogare i propri programmi con il sistema operativo e con l’hardware installato.
Ho sottolineato la parola classi, perché .NET è un sistema Object Oriented, al contrario del sistema Event Driven fornito dagli antichi VB6 e VBA.
Essendo il .NET Framework in grado di fornire classi per ogni genere di uso, la parola ricchissimo lo descrive piuttosto bene. Nonostante io lo usi ormai da 5 anni, infatti, ogni giorno scopro nuove classi e nuovi oggetti al suo interno. Nella versione 3.0 sono state introdotte tre nuove librerie anche esse ricchissime, se pure specifiche dei sistemi Microsoft Windows che si chiamano:
- Windows Presentation Foundation (WPF)
- Windows Workflow Foundation (WF)
- Windows Communication Foundation (WCF)
Quotando Paul Adams, “Non Fatevi Prendere dal Panico”. E’ il consiglio per tutti coloro a cui è diretto questo articolo. Non spaventatevi, rilassatevi, prendere fiato, iniziate a capire come si scrive sintatticamente un programma VB o C#, e poi iniziate pian piano a imparare a conoscere il Framework dalle sue parti fondamentali. Le “zone” a cui dare un’occhiata per prime le elenco di seguito:
- System
- System.Environment
- System.IO
- System.Drawing
- System.Collections
- System.Text
- System.ComponentModel
- System.Windows.Forms
- System.Web
- System.Net
Ho utilizzato la parola “zone”, per indicare una serie di entità che trovate all’interno del Framework, perché se pure così potrebbe sembrare, non corrispondono ciascuna ad una dll. Vediamo con una immagine, quali sono le dll del framework 2.0:
Come potete vedere, i nomi che ho citato in precedenza, non corrispondono ciascuno ad una dll, buona parte di essi sono infatti contenuti nella dll System. Essi sono invece dei Namespaces, la parola Namespace, inventata nella definizione del Framework e tradotta in italiano con Spazio dei Nomi, probabilmente da un traduttore che non sapeva molto di informatica, non ci dice molto. A me è servito un anno circa per capire a cosa servissero, oltre che a farmi scrivere dei nomi lunghissimi quando usavo le classi di sistema, ma forse io sono un po’ tarda, spero di riuscire a farvelo capire rapidamente con un esempio:
Se rappresentiamo il .NET Framework come una Biblioteca, i Namespaces sono le categorie e sottocategorie usate dai bibliotecari per collocare e classificare i vari libri. Nel caso del Framework, System è lo scaffale, Environment, IO, Drawing, sono i ripiani, Forms è uno dei libri. La segmentazione dei Namespaces non è solo a 2 o 3 livelli, può scendere di un numero maggiore, in base alla complessità delle classi dell’infrastruttura.
Dovrò applicare questa cosa anche ai miei programmi? E’ la domanda che mi sono posta anche io quando ho iniziato a lavorare. La risposta è la seguente: se i progetti che costruirete per le vostre applicazioni saranno molto complessi, applicare questo tipo di classificazione al codice che scriverete vi aiuterà a cercare dove avete messo una classe che sapete di aver già sviluppato mesi, o anni addietro per andare a ripescarla e usarla in un nuovo progetto. Se avrete la compiacenza di seguirci nel tempo, proveremo a darvi modo di applicare concretamente ai progetti di test questi concetti, in modo che poi possiate farne buon uso nei programmi che svilupperete professionalmente.
Una delle linee guida per gli sviluppatori, promuove caldamente almeno l’uso da parte di ogni azienda che sviluppa e installa software di utilizzare un nome univoco quale primo livello di Namespace per le proprie applicazioni. Suggerendo di usare ad esempio il nome della azienda, o, se siete un singolo, il proprio cognome. Questo per rendere univoci i nomi delle classi delle vostre librerie.
Oltre all’uso dei Namespaces, ai fini di ritrovare il codice che scriverete, potete utilizzare i “gadget” messi a disposizione da Visual Studio, ed una serie di Plugin (quasi sempre gratuiti) messi a disposizione generosamente da nostri colleghi per automatizzare la creazione di documentazione per ogni riga di codice scritta. Con questi strumenti, senza troppa fatica, potrete costruire una MSDN personale che aiuti voi, ed un eventuale team con cui lavorerete a riutilizzare il codice senza problemi. Visual Studio, fornisce l’Intellisense a tutte le classi che sviluppate nel vostro codice e con una quantità minima di lavoro, documentando metodi, parametri e property delle vostre classi, anche un collega che non ha mai visto il codice di una classe da voi scritta sarà in grado di utilizzarla all’interno dei suoi progetti.
Mi sono lanciata un po’ troppo, lo ammetto, coloro a cui questo articolo è diretto non sanno se non vagamente cosa sono classi, metodi, parametri e property. Cercherò, assieme agli altri agli altri contributor di questo sito, di integrare quanto troverete sui libri scritti dai Guru di .NET con il nostro supporto di tipo “poco teorico molto pratico”.
OK e adesso come si comincia?
La prima cosa da fare è Aprire Visual Studio .NET, nella versione Professional 2005 assomiglia a ciò che vedete nell’immagine qui sotto.
Interessante, direte voi, e adesso…
Il bottoncino magico, in questo caso è New Project.
N.B. Tutti i riferimenti saranno alla versione inglese di Visual Studio Professional, in quanto chi scrive non ama e quindi non usa le versioni italiane degli strumenti di sviluppo, non per anglofilia ma per “casinofobia” 
. DotNetWork è nato anche per dar modo ai programmatori italiani di trovare più materiale in madrelingua, ma ovviamente per un archivio come si deve ci vorrà del tempo, ed il lavoro di molte persone (Anche voi che leggete potete dare una mano se vi và).
Ora, premiamo il Bottoncino magico e quel che otteniamo è:
Se usate Visual Studio Express probabilmente il numero dei Template (Modelli) che ci sono sulla lista è inferiore, e probabilmente non c’è quel che vi farò fare adesso, perciò, se non lo trovate, create una semplice applicazione di tipo Console in VB o C# in base al linguaggio che preferite. Per chi ha una versione Standard, Professional o Team System seguitemi:
Aprendo il nodo Other Project Types sulla treeview Project Types, selezioniamo il nodo Visual Studio Solutions e fra i Template, Selezioniamo Blank Solution. Nelle TextBox, diamo nome al nostro progetto e chiamiamolo DotNetWorkDaZero, E selezioniamo la cartella ove il progetto verrà memorizzato, in questo caso, sul mio disco, D:\4uData\4uDotNetWork. Ovviamente voi potete usare la cartella che preferite, se posso darvi un suggerimento interessato, non utilizzate la cartella Documenti, createvi una cartella per i progetti su un disco del vostro PC, magari su una partizione dedicata ai Dati e possibilmente fate una cartella ad un livello non troppo lontano dalla root.
Pigiamo OK e otterremo qualcosa di simile a questo:
Ora spostiamo la nostra attenzione sul Solution Explorer che si trova in alto a destra nella finestra di Visual Studio, se non doveste vederlo, il bottoncino per farlo comparire è il seguente: 
Facendo click con il tasto destro sulla Soluzione e nel menu di contesto selezioando Add New Project> Dovreste vedere qualcosa di simile:
Cliccando sul New Project Torniamo qui:
Perché vi ho fatto fare tutto il giro? Perché fatto salvo per i progetti didattici che trovate sui libri, nel mondo reale anche un hobbista che voglia scrivere un programma in modo utile, non scriverà mai tutto il codice in un singolo progetto, quindi abituiamoci subito a capire che cos’è una Soluzione, e che cos’è un Progetto all’interno di una soluzione. Nel mio caso, Visto che voglio mostrarvi sia VB che C# creerò due progetti di tipo Console, uno in C# e l’Altro in VB ripetendo 2 volte ciò che ho fatto ora.
Per coloro che non hanno mai usato Visual Studio quindi non lo hanno ancora configurato, oppure per chi ha usato Visual Studio Express, se per caso inserito il primo progetto, la cartella con la Soluzione sparisce, oppure alla creazione di un progetto non appare, è un settaggio di default per cui sia in VB che in C# quando una soluzione ha al suo interno un solo progetto, non viene visualizzata. Chi viene da Visual Studio 2003 come me ci resta male la prima volta, ma per fortuna può essere fatta riapparire usando il menu Tools>Options>:
Questa finestra permette di configurare tutto l’ambiente, come potete vedere nell’immagine selezionando Projects and Solutions, troviamo la checkbox per visualizzare la soluzione (spero ci sia anche in Visual Studio Express) In questa finestra, potete anche configurare, usando la prima delle textbox, il luogo ove Visual Studio proporrà la generazione dei nuovi progetti che creerete, come già detto, suggerisco di crearvi una cartella apposita, togliendo il tutto dalla cartella Documents And Settings, in quanto già al primo livello di un progetto, il nome del file sarà troppo lungo. E’ più facile ricordarsi un path di tipo:
D:\VSProjects\DotNetWorkDaZero
che
C:\Documents and settings\MarioRossi\Documenti\Visual studio projects\DotNetWorkDaZero.
Dopo l’inserimento dei due progetti, chiudendo la Tree di visualizzazione della struttura del progetto fino ai nodi del primo livello, la mia soluzione assomiglia a questa:
Osserviamo i due progetti:
VB
C#
Molto scarno vero? Ma essendo un progetto Console è ovvio, direte voi. Non proprio, anche nel progetto, come abbiamo visto prima accadeva per la soluzione, l’ambiente di sviluppo nasconde parte di ciò che compone il progetto.
Assumo si tratti di qualcosa predisposto per rendere le cose meno complicate per chi è alle prime armi, e per quanto ho potuto sperimentare, solo nei progetti VB.
A mio avviso, è invece sapere subito com’è fatta tutta la struttura di un progetto e osservare come sono disposte le cose e dove trovarle, poi, quando si sa dove le cose si trovano, si attivano i meccanismi per nasconderle rendendo l’interfaccia meno intasata.
Come potete notare, nel progetto C# Si vedono già alcune cose in più.
Premete il tastino che vedete evidenziato in arancione sulla toolbar del Solution Explorer e appariranno alcune cose, la più importante è la cartella references, che conterrà tutti i reference a librerie esterne al nostro programma.
Come possiamo notare, fatto salvo la mancanza dell’icona, a cui possiamo comunque ovviare, non vi sono differenze fra i due progetti. Vi invito a osservare le cartelle non incluse a progetto (in bianco), bin e obj ove troveremo il codice compilato.
Visto che .NET è un sistema i cui linguaggi di programmazione sono di tipo Object Oriented, e soprattutto visto che in questo caso vogliamo partire da zero, per iniziare cancelliamo in entrambi i progetti il file prodotto automaticamente dal Template Module1.vb e Program.cs. Lo rigenereremo dopo.
Per coloro che lavoreranno con VB Aprite nuovamente il menu Tools>Options>
E’ opportuno che tutti coloro che utilizzano Visual Basic si abituino a predisporre queste opzioni come nella finestra, in modo da evitare l’uso di alcune “scorciatoie” controproducenti per l’efficienza e utili a provocare errori difficilmente rilevabili se non dopo giornate spese a cercare. Option Explicit obbliga la dichiarazione delle variabili. Option Strict obbliga all’uso delle conversioni esplicite per tutte le assegnazioni in cui c’è un cambio di tipo dati. Questa opzione è importante per evitare che sia possibile fare qualcosa del tipo:
dim i
i= “10”
dim numero as integer
numero = i
Lasciando al compilatore il compito di decidere come convertirlo, è sempre meglio che un programmatore inizi subito a prendersi le proprie responsabilità, lasciando al compilatore solo il compito per cui è stato definito, ovvero generare codice macchina.
Proseguiamo con l’esplorazione degli strumenti. Adesso facciamo un doppio click su My Project o Properties in base al linguaggio utilizzato, per far comparire una delle finestre qui sotto.
C# 
VB 
Questa serie di finestre, serve alla configurazione dell’applicazione, avrete occasione di utilizzarla in tutti i vostri progetti, per ora ci limitiamo ad esplorarne il minimo indispensabile:
Selezioniamo il tab di configurazione dell’applicazione e iniziamo a guardarne il contenuto.
La prima casella di testo del tab Application contiene il nome proprio dell’eseguibile o della dll (Assembly name) infatti i programmi .NET sono composti da uno o più Assembly.
Sotto al nome Assembly, c’è l’elenco a discesa che stabilisce di che tipo di applicazione si tratta. Nel nostro caso una Applicazione di tipo Console.
C#
VB
Sotto ancora abbiamo l’oggetto da cui l’applicazione parte. Qui abbiamo una prima differenza, in C# se non specificato, viene automaticamente ricercato il metodo statico Main. L’obbligo di specificare l’entry point c’è solo se per qualche motivo (usualmente solo didattico) ci sono più metodi Main in classi diverse.
In VB per l’applicazione di tipo Console è automaticamente selezionata una Sub Main, ma se osserviamo la lista, è possibile indicare direttamente un oggetto per lo startup. Se in VB selezionassimo un altro oggetto, il compilatore genererà automaticamente il Main al nostro posto. Ma come abbiamo già detto, siamo qui per imparare a programmare, non per lasciare al compilatore decidere per noi.
C#
VB
La casella di testo a destra del nome assembly, che riguarda la gestione dei Namespace, è la seconda a differire fra C# e VB. Infatti, mentre per C# si tratta di un Default Namespace, ovvero di una dichiarazione che viene riportata automaticamente in tutte le nuove classi generate, e quindi un semplice promemoria. Per VB si tratta del Root Namespace, ovvero del namespace di base che viene inserito come prefisso al namespace di tutte le classi del progetto.
Facciamo un esempio pratico:
Il Namespace scritto nei nostri progetti è il seguente:
VB
C#
DaZeroVb
DaZeroCs
Ma se volessimo definire una classe MyClass, contenuta nel namespace BaseClasses in entrambi i linguaggi, la definiremo così:
VB
Namespace BaseClasses
Public class MyClass
'Costanti, Campi
'Il costruttore
Public Sub New()
'Il codice da eseguire quando la classe viene instanziata
'
End Sub
'Proprietà
'Metodi
End Class
End Namespace
C#
namespace DaZero.BaseClasses
{
public class MyClass
{
//Costanti e Campi
//Costruttore
public MyClass()
{
//Codice del costruttore
}
//Proprietà
//Metodi
}
}
Come potete notare, mentre per C# il Default Namespace è solo un dato proposto che viene inserito in una classe e poi può essere modificato, per VB il Root Namespace è un prefisso che viene posto automaticamente ed in modo invisibile davanti al namespace inserito in una classe.
Entrambi i modi d’uso hanno i loro pro ed i loro contro. Il metodo di VB impedisce che qualsiasi classe contenuta in un progetto si trovi in un Namespace al di fuori della Root e cambiando il Root Namespace si spostano tutte le classi del progetto nel nuovo Namespace. L’ ostacolo della Root obbligata è aggirabile mettendo un Root Namespace Vuoto e specificando tutto il percorso nelle classi, ma è un ostacolo piccolo piccolo, se ligi ai consigli dei pattern & practices usiamo sempre come root namespace il nome della nostra azienda, anche perché una Dll con due root namespace sarebbe piuttosto strana (ma non vietata).
Il metodo di C# d’altro canto fornisce a colpo d’occhio il “Path” del Namespace della classe; per contro, se cambiamo il default Namespace deve essere corretto a mano nelle classi già definite. Ostacolo abbondantemente aggirato usando un Trova e Sostituisci sull’intero progetto.
I tab della configurazione di progetto che stanno dopo quello esaminato, li vedremo più avanti, visto che per la nostra prima applicazione non necessitiamo di grandi strumenti.
Vi sono comunque ulteriori piccole differenze fra i due linguaggi che personalmente reputo dovute a diversi punti di vista fra i Team di Sviluppo e soprattutto alla volontà,e sopratutto alla volontà da parte del Team di VB di semplificare la migrazione da VB6 rendendo il nuovo ambiente di sviluppo il più confortevole possibile sacrificando in alcuni casi alcune importanti caratteristiche di .NET. Ma niente paura, come abbiamo fatto con il tastino Visualizza tutti i file, in questo e in tutti gli articoli futuri, vi mostreremo tutto ciò che c’è a disposizione, per dimostrarvi che non c’è nulla da temere e che se pure .NET è una montagna da scalare, i progettisti hanno attrezzato il percorso in modo da permetterci di raggiungere agevolmente la cima, posto che abbiamo voglia di faticare un poco e non ci spaventiamo davanti alla prima parete verticale. Una volta che avrete imparato quel che l’ambiente fornisce starà a voi, in base al tipo di applicazione che state costruendo, decidere quali scorciatoie, quali wizard, quali funzionalità utilizzare e quali no, fra tutte quelle offerte dall’ambiente di sviluppo.
La nostra prima classe (Scuola Elementare Pietro Zorutti, classe prima B 1/10/1971)
Torniamo al nostro progetto VB o C# facciamo click sul progetto DaZeroCs oppure DaZeroVB con il tasto destro e sul menu contestuale, selezioniamo Add>Class>
L’immagine a lato mostra come si presenta il menu, fate attenzione che la posizione di Add> sul menu principale può dipendere dalla configurazione di Visual Studio 2005 e dai Plugin installati.
Qui sopra, la finestra per la selezione del tipo di Classe che vogliamo inserire nel progetto, nel nostro caso utilizzeremo il semplice Template Class che ci crea una classe vuota, in successivi articoli spero di avere il modo di farvi vedere l’uso di tutti questi modelli di classe.
Chiamiamo le nostre classi Program.cs oppure Program.vb e vediamo cosa troviamo nel codice prodotto dal template.
namespace DaZeroCs
{
public class Program
{
}
}
Public Class Program End Class
Come possiamo vedere la quantità di codice prodotta è minima, ed in C# viene inserita la clausola Namespace mentre in VB non serve perché la classe si troverà all’interno del Root Namespace.
Abbiamo creato la nostra prima classe, ma se proviamo a compilare otteniamo degli errori:
(VB) Error 1 ‘Sub Main’ was not found in ‘DaZeroVb’.
(C#) Error 1 Program ‘D:\4UDATA\4uDotNetWork\DotNetWorkDaZero\DaZeroCs\obj\Debug\DaZeroCs.exe’ does not contain a static ‘Main’ method suitable for an entry point DaZeroCs
Più o meno concisi, ma entrambi i compilatori ci dicono che manca una cosa che si chiama Main.
Che cos’è il Main, ebbene, anche se in VB è possibile mascherarlo (in realtà se si sceglie la configurazione in cui non c’è il compilatore lo crea da solo quando viene lanciato). Il Main è per definizione il primo metodo che il .NET Framework chiama quando un programma viene messo in esecuzione dal Sistema Operativo. Il Main è un metodo static (Shared) che può essere contenuto in una qualsiasi classe del progetto, oppure, per VB, in un Modulo.
Il metodo Main, è di tipo void (Sub) e può avere come parametro un array di stringhe, questo parametro, conterrà al suo interno tutte le stringhe che saranno digitate a linea di comando quando il programma viene chiamato.
Scriviamo il metodo Main e vediamo come cambia il codice delle nostre classi:
namespace DaZeroCs
{
public class Program
{
[System.STAThread]
public static void Main()
{
System.Console.WriteLine("Salve a tutti, IO sono DaZero.cs ed Esisto");
System.Console.ReadLine();
}
}
}
Public Class Program
<System.STAThread()> _
Public Shared Sub Main()
System.Console.WriteLine( "Salve a tutti, IO sono DaZero.vb ed Esisto")
System.Console.ReadLine()
End Sub
End Class
Abbiamo preparato il classico Hello World, e in questo metodo, utilizziamo per la prima volta alcune cose, la prima è la riga che precede la dichiarazione del metodo, ovvero [System.STAThread] (<System.STAThread>) questa riga, è definita come una Decorazione del metodo Main, e aggancia al metodo un Attributo (STAThread) il cui significato per ora non ci interessa. Introduciamo solo il concetto di Decorazione e di Attributo, una classe, un metodo, una property all’interno di un programma .NET può essere Decorato con uno o più attributi che forniscono informazioni di tipo dichiarativo al compilatore e permettono di fornire informazioni e funzionalità a ciò che decorano, alcune Decorazioni servono ad esempio a indicare all’ambiente di Vsual Studio ciò che serve per utlizzare correttamente i designer e le property grid.
Non scendiamo in dettaglio riguardo gli attributi perché esulano dal percorso di questo articolo introduttivo, diciamo pure che anche chi inizia da Zero deve sapere che esistono, in seguito, troveremo sicuramente occasione di spiegarne l’uso e lo scopo.
La seconda cosa che utilizziamo, è la classe Console, una delle tante classi del Framework che fornisce ai nostri programmi le funzioni necessarie a scrivere sulla Console, ovvero quella strana (per chi non ha lavorato con il DOS) finestra a caratteri che si può veder usare dai Sistemisti e da personaggi strani (per lo più dei biechi figuri che scrivono programmi con il notepad 
) affezionati all’interfaccia carattere che esisteva prima di Windows.
Il nostro programma, per semplicità è stato creato per lavorare con questa interfaccia, e l’output che fornisce è il seguente:
Premendo il tasto invio, il programma termina e la finestra si chiude.
Concludiamo qui la nostra prima puntata dedicata agli absolute beginners, nella prossima faremo una panoramica dei due linguaggi di programmazione, abbandoneremo l’interfaccia qui proposta per quella grafica sicuramente più gradevole a tutti ed inizieremo ad addentrarci insieme nel fantastico mondo del .NET Framework!
Potete scaricare il codice a corredo di questo articolo al link qui sotto:
