Technology Experience

Contenuti gestiti da Igor Damiani
posts - 949, comments - 2741, trackbacks - 15120

My Links

News

  • Questo blog si propone di raccogliere riflessioni, teoriche e pratiche, su tutto quello che riguarda il world-computing che mi sta attorno: programmazione in .NET, software attuale e futuro, notizie provenienti dal web, tecnologia in generale, open-source.

    L'idea è quella di lasciare una sorta di patrimonio personale, una raccolta di idee che un giorno potrebbe farmi sorridere, al pensiero di dov'ero e cosa stavo facendo.

    10/05/2005,
    Milano

Archives

Post Categories

Generale

[MCAD.41] Conclusione dell'argomento Setup Project e varianti

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:

  1. As loose uncompressed files
  2. In setup file
  3. 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!

powered by IMHO 1.2

Print | posted on Wednesday, September 28, 2005 12:59 PM | Filed Under [ MCAD ]

Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET