Nei (numerosi) post precedenti, abbiamo creato
pian pianino un'applicazione Age, giusto per verificare
passo passo tutte le classi/componenti/funzionalità che ho voluto trattare
per prepararmi all'esame. La mia applicazione sul mio PC è funzionante, e mi
diverte anche usarla - ho provato ad usarla adesso, e grazie alla stored
procedure che abbiamo creato qua, mi dice che il prossimo compleanno è quello di
mio papà! 
Quello che voglio fare è creare un setup per rendere distribuibile l'applicazione
anche in giro, magari per mettere il download sul mio sito o masterizzarlo
su CD. La nuova piattaforma .NET ci mette a disposizione lo strumento
giusto, cioè un tipo di progetto studiato appositamente per questo tipo di
esigenza che, guarda caso, si trova sotto il gruppo Setup and Deployment
Projects. Sotto questo gruppo si trovano diversi tipi di progetto.
Quello che interessa guardare oggi è quello chiamato Setup
Project.
Per organizzare meglio il mio IDE, di solito faccio una
cosa. Supponiamo di avere aperto il progetto Age con il
sorgente C# scritto nelle settimane precedenti. Adesso che voglio creare il suo
setup, non chiudo questo progetto, ma semplicemente aggiungo un nuovo
progetto
alla soluzione. VS.NET ovviamente non ha problemi a gestire questa situazione: la soluzione comprenderà
quindi due progetti separati. Il primo è il progetto all'applicazione, e il secondo
è il setup dell'applicazione.
In breve: clicco con il pulsante destro su Solution nel
Solution Explorer, vado su Add e seleziono
New Project. Dal dialog, seleziono Setup
Project, gli do un nome sensato ("SetupMCAD" nel mio caso) e confermo
con Ok. L'IDE si aggiorna e mi propone una finestra denominata File
System.
Fermiamoci qua un attimo. Prima di proseguire, voglio
raccontare le mie esperienze passate parlando di setup & deployment, per far
capire i limiti degli strumenti con i quali lavoravo, i problemi che ho
(abbiamo) dovuto patire fino ad arrivare a .NET. Magari Michele ed Eleonora
, da buoni frequentatori di it.comp.lang.visual-basic, ne
sanno qualcosa, chi lo sa?
Un po' di storia, volete?
Ho cominciato a lavorare con Visual
Basic 4.0, parecchi anni fa. Ufficialmente, sono stato assunto nel 1995, ma fin
da prima programmavo qualcosa con BASIC, GWBASIC, Quick Basic e Visual
Basic
4.0 a 32-bit (c'era anche la versione a 16-bit per Windows 3.1). Non mi
trovavo male, in fondo la sintassi del BASIC è sempre quella. Solo VB mi ha veramente
scombussolato, usciva dai tradizionali schemi della programmazione
(imperativa, giusto?) nei quali ero abituato. I primi passi in OOP. Il panico è
durato poco: è bastato comprare il mio primo libro su VB per schiarirmi le idee
in merito.
All'epoca, 18 anni circa, ero appassionato di GdR (giochi di ruolo). In VB creai
un (strampalato, ma mica tanto) programma per creare i personaggi (abilità, statistiche,
punteggi vari che non sto qui a precisare, sono OT). Riscosse
un enorme successo: ben 5 persone lo apprezzarono, ovvero gli amici con i
quali mi trovavo per giocare. 
Il 10 Maggio 1998 aprii il
mio primo sito Web
, sul mitico Geocities, che offriva spazio gratuito, per cui
mi domandai: quasi quasi, distribuisco Shankara in giro per il mondo, e
vediamo un po' cosa succede. Per chi fosse curioso, il
sito Web è online ancora adesso.
Quanto tempo è passato, porca
miseria!
Fu in quel periodo che mi imbattei per la prima volta nel
Package and Deployment Wizard, disponibile ancora adesso
insieme a Visual Basic 6.0.
Non era proprio terribile. Gli si dava in pasto un file VBP (progetto VB) e questo tool creava il setup
completo (setup.exe + CABs). Dal progetto, lui deduceva tutte le dipendenze, creava il
file setup.ini con tutte le informazioni necessarie per portare avanti fino
in fondo il setup. Aveva una serie di difetti, più o meno terribili:
- a volte non trovava veramente tutte le dipendenze
- a volte nel file setup.ini, i files non venivano
riportati nell'ordine corretto (prima di poter installare un file, bisogna
installare prima i files da cui dipende)
- a volte nel file setup.ini, chissà perchè, i files
OCX non venivano marcati dal parametro {DllRegisterServer}, per cui non
venivano registrati
- l'interfaccia all'inizio andava anche bene, ma poi è
diventata veramente vecchia, obsoleta e inquietante
- il setup è di una lentezza disarmante
- a volte cominciava a fare domande assurde,
specialmente quando doveva sovrascrivere files già esistenti. Domande
complicate, quasi un rompicapo, con doppie negazioni che rendevano la vita
difficile all'utente finale
- avete mai provato a distribuire le librerie di
Crystal Report con questo tool?
- bisognava ricompilare setup1.vbp per personalizzare il nostro
setup
Questi, e tutta una serie di altri motivi che ero non ricordo mi hanno fatto
un po' impazzire con il buon vecchio Package and Deployment
Wizard. Nel corso degli anni, sono passato a Visual Studio
Installer, con l'IDE incorporato dentro InterDev. Ci sono stati (e ci
sono ancora) un sacco di strumenti come InstallShield, Wise
Installer, alcuni addirittura gratuiti, e chi ne ha più ne metta.
Torniamo al nostro Visual Studio
Chiariamo subito una
cosa: se usiamo controlli e componenti inclusi
nel Framework, le dipendenze non sono più affare nostro.
Teoricamente noi potremmo fare il deploy semplicemente con una copia del nostro
EXE, e magari qualche altro files (xcopy deployment). La cosa più semplice che
possiamo fare con il nostro Setup Project, quindi, è quella di
indicare dove posizionare ogni file sul sistema dell'utente finale.
L'IDE di VS.NET ci propone all'inizio tre possibili locazioni:
Application Folder, User's Desktop e
User's Programs Menu.
Il primo folder (Application Folder) è ovviamente la directory di
installazione scelta dall'utente, che per default è
[ProgramFilesFolder][Manufacturer]\[ProductName].
Negli altri due folders
possiamo creare gli shortcuts per facilitare la vita all'utente: per esempio, lo
shortcut all'EXE principale della nostra applicazione. Oppure, un link al nostro
sito, Oppure, il link per l'uninstall. E così via.
Se volessi aggiungere qualche directory speciale, basta cliccare con il
pulsante destro su File System on Target Machine, e dal
ContextMenu selezionare la directory che ci serve (font, preferiti, send-to,
system, etc.). Notare la comparsa della directory relativa alla
GAC, per poter installare assembly in questa locazione. Io
personalmente consiglio un bello sguardo alla Property Window ogni volta che
cliccate su un elemento: ogni file ha le sue proprietà, come come il nodo
Application Folder che ho detto prima. Magari ne parlerò meglio in futuro.
Per generare il vero setup, è sufficiente fare il build del progetto di
Setup. Nella directory di output (dove? clic destro sul
progetto dal Solution Explorer, poi proprietà) vi ritroverete
setup.exe e il file MSI che servono per distribuire l'applicazione agli
utenti.
In questo post ci fermiamo qua, ho preferito introdurre il discorso. La
prossima volta sarò più conciso e vedremo cosa ci può capitare durante l'esame
MCAD.
.NET è meraviglioso
L'accoppiata .NET
Framework + IDE di VS.NET è straordinaria.
Per me che arrivo da una
decina d'anni di esperienza con il buon vecchio Visual Basic 6.0, vedere
cosa sono in grado di fare le classi di .NET è motivo di esaltazione e
qualche volta di orgoglio. 
Una lacrimuccia mi scende se penso al
mio VB6. 
Credo che approfondirò il discorso in un altro post
che voglio fare, e che esula dalla certificazione MCAD. E' possibile aggiungere
launch condition al setup, customizzare in ogni modo quello che il setup
deve fare (creare db, andare sul Web, lanciare applicazioni, spedire e-mail),
aggiungere finestre di dialogo personalizzate. Strepitoso, suplime!
.NET è meraviglioso, sul serio.
Cito
Alejandro, che direbbe:
Fletto i muscoli, ed eredito da
System.Configuration.Install.Installer