Negli ultimi post abbiamo divagato, ma mi è piaciuto
veramente far vedere a me e agli altri cosa sono riuscito a combinare con il
Setup Project di VS.NET. Credo che siano state un po' OT rispetto
al percorso richiesto dalla certificazione MCAD, però è sempre comodo
sapere qualcosa in più, piuttosto che qualcosa in meno. Con il post di oggi
chiudiamo il discorso dedicato alla creazione dei setup, vedendo un attimo quali
formati di files possiamo generare, che differenze ci sono, come possiamo
distribuirli e così via.
Introduzione
Innanzitutto, ho riaperto la solution che
abbiamo avuto tra le mani fino a ieri. Clicchiamo con il pulsante destro del
mouse sul progetto di setup ed andiamo a dare un'occhiata alle Properties. Dalla
finestra di dialogo possiamo già stabilire qualche dettaglio in più sul
comportamento del nostro VS.NET.
Nella casella Output file name possiamo decidere il nome del
file ed in quale directory vogliamo posizionare il file MSI. Possiamo scriverlo
manualmente, oppure cliccare sul pulsante Browse. Nulla di
complicato, passiamo a qualcos'altro. 
La casella Package files
permette di stabilire il formato del package che vogliamo creare. Abbiamo tre
possibilità diverse:
- As loose uncompressed files
- In setup file
- In cabinet file(s)
Da notare che in ogni caso nella directory di output viene comunque salvato
il file MSI.
Nel primo caso, nella directory vengono posizionati banalmente
tutti i files che compongono il progetto, senza compattarli: nel mio caso, vedo
il file EXE, il file Readme.txt che ho usato nel custom dialog Read
Me, vedo setup.exe e così via.
Nel secondo caso, i
files vengono compattati e riuniti in un file MSI.
Nel terzo caso, i files vengono compattati e
riuniti in uno o più files CAB per il download da Web. In quest'ultimo caso,
inoltre, può essere utilizzata la casella CAB size che
determina la dimensione massima che deve avere ciascun file CAB: questa
impostazione può essere utile per creare setup su floppy-disk (!), su dischi
ZIP, etc. etc. Per default, tale impostazione è Unlimited.
La casella Bootstrapper è sempre disponibile. Questa ci
consente di specificare se vogliamo avere il file
setup.exe nella directory di output. Può essere
None: in tal caso, nella directory di output viene messo il
package senza nient'altro (il file MSI o il file CAB, per esempio). Può essere
Windows Installer Bootstrapper, che copia appunto il file
setup.exe. Altrimenti, possiamo indicare Web
Bootstrapper, che ci permette di iniziare il setup dal Web.
Voglio far notare, anche se è banale, che se un setup è in formato MSI,
possiamo lanciarlo anche senza setup.exe: è sufficiente fare doppio-click e
partirà automaticamente Windows Installer.
Altri tipi di setup disponibili con Visual Studio .NET
Il
contenuto espresso in questi ultimi miei post ha trattato soprattutto del
setup di una classica applicazione Windows Forms. VS.NET mette a disposizione
altri tipi di setup, le cui caratteristiche sono più o meno le stesse, ma hanno
peculiarità e scopi differenti. Vediamole in breve.
Web Setup Project
Questo tipo di setup permette il
deployment di un'applicazione (web-services, per esempio) su un server Web.
Oltre alla classica copia dei files richiesti, ci sono diverse proprietà
interessanti: per esempio, RestartWWWService permette di
stoppare e riavviare il servizio IIS su cui è avvenuto il deploy. Altre
proprietà dell'oggetto Web Application Folder sono:
AllowDirectoryBrowsing, AllowReadAccess, AllowScriptSourceAccess,
AllowWriteAccess, DefaultDocument, LogVisits e VirtualDirectory. Per chi
lavora tutti i giorni con IIS, sa di cosa sto parlando. Con questo tipo di
setup, quindi, possiamo fare il deploy di un'applicazione su un server IIS,
impostando direttamente molte delle proprietà IIS relativa all'applicazione
appena installata.
Merge Module Project
Questo setup genera dei file MSM. La finestra delle
proprietà non permette di cambiare sul formato CAB. Il file MSM è una
versione semplificata del formato MSI: non contiene la Features Table, e quindi un
file MSM non può essere installato da solo, ma deve essere obbligatoriamente
incorporato dentro un altro progetto che crei un file Windows Installer. Ho
trovato questo articolo su MSDN che dice espressamente che
bisognerebbe creare un Merge Module ogni volta che si vuole distribuire una
nuova versione di un certo componente/assembly, per evitare conflitti di
versione. Oppure, ancora, per "isolare" i files richiesti da un certo
componente: per esempio, se creassi un Windows Control che viene utilizzato da n
applicazioni, sarebbe comodo creare un file MSN per questo controllo, così da
poterli incorporare dentro il setup principale delle mie n applicazioni. In tal
caso, infatti, non dovrei ricordarmi ogni singolo file richiesto dall'assembly:
è sufficiente includere nel classico Setup Project
ed il gioco è fatto!