Perchè il "Package and Deplyoment Wizard" di VB non è più al passo coi tempi
a cura di Sergio Pappalardo (requisiti: infarinatura sui concetti di base di distribuzione di un software, installazione, dipendenze e packaging)

Premessa del revisore
Per forza di cose, dato l'autore e l'argomento, questo articolo contiene qualche passo 'autopromozionale'. D'altra parte, CIS è promosso dal nostro stesso sito in modo del tutto disinteressato, in base alla sola affidabilità del prodotto. Nonostante queste parti pubblicitarie, quanto segue è importante per capire perché NON usare più l'installer fornito con Visual Basic.

Introduzione
Prima o poi giunge il fatidico momento per ogni sviluppatore che si rispetti, dilettante o professionista che sia, di distribuire il proprio software. Proprio quando sembra che il peggio sia passato, si scopre che manca, invece, ancora molto per raggiungere l'agognato risultato, quello di permettere a chiunque (o quantomeno alla maggior parte di utenti possibili) di poter utilizzare il software appena compilato al massimo di ogni sua funzionalità.

Ma si intravede qualcosa... Forse la soluzione è proprio lì, nel Menu Avvio, nel collegamento accanto a quello per l'avvio di Visual Studio... ma sì! Forse è proprio quel "Package and Deployment Wizard" installato insieme al nostro IDE preferito senza che nemmeno ce ne accorgessimo! Così semplice... possibile?! Oppure bisogna guardare in po' più un là del proprio naso?... Scopriamolo.

Situazione
Finalmente, dopo mesi e mesi di intenso sviluppo, abbiamo concluso anche gli ultimi test e così abbiamo davanti ai nostri occhi, risplendente sul nostro monitor con la sua bell'icona colorata, il nostro eseguibile, fresco fresco di compilazione. E adesso? Si potrebbe essere portati a pensare che il peggio sia passato e che non solo cominci la parte divertente del nostro lavoro, ma che inizieremo ben presto ad avere delle belle soddisfazioni dalla nostra creatura!

Purtroppo, non c'è niente di più sbagliato. Adesso bisogna permettere a chiunque di poter utilizzare il nostro eseguibile, nel modo corretto (senza errori) e al massimo delle sue potenzialità (proprio come lo vediamo sul nostro monitor) e dandogli la possibilità di usufruire di tutte le funzionalità di cui lo abbiamo dotato. Che sia indirizzato, quindi, a dei beta-tester (come auspicabile subito dopo il rilascio di una nuova versione) o agli utenti finali sotto forma di CD/DVD o ancora sul nostro sito web pronto per essere scaricato, il problema è sempre lo stesso: la distribuzione.

Il problema
Appurato quindi che il problema è la distribuzione del nostro software, sorge spontanea una domanda: "Non è sufficiente distribuire il nostro eseguibile?". La risposta è assai semplice: no.

Il motivo non è altrettanto banale e risiede non solo nel come un software viene compilato, ma anche nel modo in cui intendiamo distribuirlo e di quali comodità a valore aggiunto vogliamo dotarlo. Nella maggior parte dei casi - e con questo intendo il 99% delle volte - un programma, per funzionare correttamente, necessita di alcuni file aggiuntivi di supporto, quali: componenti di terze parti (dipendenze), ActiveX (.ocx), librerie (.dll), documentazione (.html, .chm, .hlp, ecc.), file binari, file di configurazione (.ini, .dat, .cfg, ecc.), file di dati (mdb, dat, xml, ecc.), file multimediali (immagini, video, suoni), font addizionali (.ftt, .fnt, ecc.). A questi bisogna aggiungere tutti i file necessari per l'accesso ai dati, ossia il motore di DBMS (Database Management System), visto che la gran parte delle applicazioni sviluppate, anche se non sono strettamente gestionali, utilizzano basi di dati. Per complicare le cose, c'è il fatto che, se si sviluppa in VB, è necessario distribuire anche la Microsoft Virtual Machine idonea per la versione di VB in nostro possesso (msvbvmX.dll, dove la X sta appunto per il numero di versione); se invece si sviluppa in un qualsiasi linguaggio .Net, sarà necessario distribuire il Framework, sempre nella versione appropriata.

Tutto questo deve essere distribuito insieme al nostro eseguibile e, com'è facile intuire, complica notevolmente il lavoro di distribuire con successo il nostro software. Anche perché bisognerà sapere con esattezza non solo di quali componenti, dipendenze e altri file necessita il nostro eseguibile, ma anche dove andranno copiati sul sistema dell'utente finale (sistema destinazione). Inoltre, bisognerà pensare come comportarsi nel caso esistano già versioni precedenti o più aggiornate degli stessi componenti che intendiamo distribuire, o se la tecnologia da noi utilizzata è già installata (e anche qui, dipende se la versione è uguale, inferiore o superiore alla nostra). Infine bisognerà sapere quali componenti andranno registrati, pena il mancato funzionamento della nostra applicazione.

Infine, la cosa più importante di tutte: bisognerà installare la nostra applicazione sul sistema destinazione sempre tenendo presente che non si devono fare danni o precludere il funzionamento di altri software già installati. Questo, infatti, getterebbe discredito non solo sulla nostra applicazione, ma anche su noi stessi, inficiando ogni lavoro futuro che andremo a sviluppare, se le notizie sulle nostre "malefatte" si dovessero spargere in giro. E si sa, con Internet si fa presto a diffondere qualcosa... Facciamo un esempio pratico: se il nostro eseguibile necessitasse di un componente ActiveX, perché abbiamo usato una griglia particolare, dovremo distribuire il file .ocx relativo a questa griglia. Ebbene, se il sistema destinazione avesse già tale componente? Dovremmo controllare le versioni dei due ocx e sovrascrivere quello della griglia destinazione solamente se il componente che distribuiamo è più recente, preoccupandoci di deregistrare il vecchio componente e registrare il nuovo. Se però un software eventualmente già installato avesse problemi con la nuova versione di questo componente smetterebbe di funzionare... Come comportarci allora? E questo è solo un esempio.

La soluzione a tutti questi innumerevoli problemi è... usare un installer.

Previsione 1: Qualcosa andrà storto.
Sembra una previsione nel migliore stile delle leggi di Murphy, però non c'è nulla di più veritiero a proposito di installazioni: l'imprevisto è sempre dietro l'angolo, visto che, dovendo avere a che fare con un sistema che non è il nostro, che non conosciamo e sul quale non possiamo mettere le mani, le variabili sono innumerevoli e imprevedibili.

Il "Package & Deployment Wizard" (P&D) di VB6
Di conseguenza, è auspicabile usare uno strumento idoneo, che minimizzi il più possibile le cose che potrebbero andare storte (magari le eliminasse!). Dunque, a chi rivolgersi? Vediamo, installando il nostro amato Microsoft Visual Studio che usiamo ogni giorno per lavorare, ci sarà pure un installer tra gli innumerevoli strumenti installati e dai nomi più esotici, magari nascosto nella selva di cartelle, sotto-cartelle e file... Navigare nella cartella Programmi neanche a parlarne, potrebbe essere sommerso sotto giga e giga di file, sarebbe una battaglia persa! Sono pigro, comincio allora dal Menu Avvio... nella cartella di gruppo di Visual Studio... ecco una sotto-cartella "Microsoft Visual Basic 6.0 Tools" e lì... (eccolo! L'ho già trovato, possibile?) fa bella mostra di sé un collegamento denominato "Package & Deployment Wizard" [da ora in avanti abbreviato in "P&D"]. Forse è la soluzione di tutti i nostri problemi di installazione...

Avviamolo dunque. Il P&D ci chiederà che tipo di pacchetto vorremo creare e, dandogli in input il nostro bel file di progetto (.vbp), sarà in grado di proporci un pacchetto contenente tutte le dipendenze necessarie. O almeno così sembra... Inoltre, provando ad installarlo, offrirà all'utente un'interfaccia grafica idonea per le poche, fondamentali scelte durante la fase di installazione, contemporaneamente occupandosi, dietro le quinte, di tutti quegli importanti aspetti che ho fatto presente precedentemente: scelta cartella destinazione, copia file alla destinazione opportuna, registrazione componenti, confronto versioni eventualmente già installate, ecc..

Ok, dopo un po' di fatica (ma poi neanche troppa) per capire come funziona l'intuitivo (in perfetto stile Microsoft!) P&D, ecco che tutti i nostri problemi sembrerebbero essere risolti nel migliore dei modi, facilmente, senza dover studiare soluzioni complesse che avrebbero ritardato l'uscita della nostra applicazione e per di più - cosa che non guasta mai - in modo economico, visto che il P&D è uno strumento fornito di serie con l'IDE. Non è stato dunque così difficile come prospettato.

Tutto rose e fiori dunque? Non proprio...

Previsione 2: Qualcosa andrà di nuovo storto.
Ma come, di nuovo?! Anche utilizzando il P&D non andrà tutto per il verso giusto? Già, è molto probabile. Scopriamo insieme perché questo grazioso strumento si rivela più uno specchietto per le allodole, illudendo di fare le cose come si deve, ma spesso - troppo spesso - causa più problemi di quanti ne risolva, specialmente in questi ultimi tempi, in cui nuove tecnologie si sono susseguite a ritmo indiavolato e anche Windows si è evoluto parecchio, complicando ulteriormente le cose per il povero P&D, rilasciato da Microsoft in tempi che, informaticamente parlando, sono vere e proprio ere geologiche fa.

Un passo indietro nel tempo...
======================================================================== Più di sette anni fa, finii di programmare il mio primo gestionale, che usava una base di dati per memorizzare clienti, ordini, fatture e bilanci. L'avevo compilato con VB5 e mi apprestavo a darlo a un mio beta- tester di fiducia, che pur non essendo programmatore conosceva e utilizzava parecchi gestionali, quindi avrebbe potuto darmi parecchi utili consigli.

Recatomi sul luogo per vedere se il mio eseguibile appena compilato girava correttamente anche sul suo sistema, mi resi subito conto che le grane erano appena cominciate: "ActiveX can't create object", "Impossibile trovare ISAM installabile" e altri errori ameni cominciarono a popolare lo schermo. Subito, capii che non bastava semplicemente copiare il mio eseguibile, perché evidentemente sul mio sistema c'erano diversi file, da cui l'eseguibile dipendeva, che avrei dovuto includere nel pacchetto. Sì, ma... quali? Le community su Internet non erano così numerose come ora e io non possedevo ancora la possibilità di connettermi alla Rete. Messomi di impegno, chiedendo in qualche mailing-list di sviluppatori dall'Università, scoprii che potevo utilizzare il P&D per creare il mio pacchetto di installazione, avrebbe pensato a tutto lui. Uno strumento della Microsoft, pensai, fatto apposta per il linguaggio di programmazione da me usato, non poteva che essere la soluzione definitiva a quei problemi che mai avevano sfiorato la mia mente.

Niente di più sbagliato! Dopo l'emozione iniziale, dovuta alla creazione con successo del mio primo pacchetto di installazione, dovetti ricredermi sulla facilità dell'operazione... Una volta avviata l'installazione sul mio stesso sistema di sviluppo, uno strano errore relativo a un certo "DLLSelfRegisterEx" non trovato. Demoralizzato, tornai a documentarmi e scoprii che era un bug di P&D: era necessario modificare, nello script di installazione generato dal P&D, la stringa in "DLLSelfRegister". In questo modo finalmente veniva installato correttamente! Almeno sul mio sistema. Ma un'altra amara sorpresa mi attendeva...

Con immenso sconforto, dopo essermi recato nuovamente con fare sicuro dal mio beta-tester, dovetti subire un'ennesima sconfitta: il pacchetto di installazione finalmente veniva installato senza errori, ma al primo riavvio, dovuto all'aggiornamento dei file di sistema, veniva richiesto un nuovo riavvio, in un loop senza fine. Cominciai a sentirmi imbarazzato della magra figura che stavo facendo, ma per fortuna mi riscattai riparando al mal fatto rimettendolo in grado di utilizzare ancora il computer. Del poter utilizzare il mio applicativo, però, ancora non se ne parlava...

L'entusiasmo iniziale era scemato notevolmente, ma fu lievemente rianimato dall'apprendere che sarebbe bastato installare l'ultimo Service Pack di Visual Studio per evitare il continuo riavvio. "Ecco, adesso deve funzionare per forza!" pensai. Invece no. Dal beta-tester, il gestionale, si avviava sì, dopo l'installazione, ma qualche errore persisteva e appena utilizzata una funzione facente uso del database, veniva mostrato un simpatico messaggio di errore con la successiva immediata chiusura del programma. A quel punto, comunque, la mia esperienza, per quanto poco, era cresciuta e sapevo che avrei dovuto accertarmi che tutti i file fossero distribuiti col pacchetto. Controllai quindi che tutti i file utilizzati dal mio applicativo venissero inclusi dal P&D, verificando con attenzione non solo quali referenze fossero incluse nel mio progetto VB, ma anche quali file fossero necessari per l'utilizzo dell'accesso ai dati tramite DAO (il database usato dal mio gestionale di allora). Naturalmente, con un simile procedimento empirico, la paura di dimenticarsi sempre qualcosa era onnipresente, per esempio scoprii per puro caso di dover aggiungere una libreria ausiliaria da copiare e registrare nella cartella "System"per far sì che un OCX da me utilizzato potesse funzionare correttamente. Inoltre, al tempo non ero nemmeno al corrente del problema principale di P&D, per altro aggravatosi sempre di più con il succedersi degli anni... ma di esso parlerò tra poco.

Alla fine, però, la mia perizia fu premiata: l'installazione andò a buon fine sul sistema del mio amico beta-tester e fu possibile utilizzare il gestionale al pieno delle sue funzionalità. Mi vennero quasi le lacrime agli occhi vedendolo girare in tutto il suo splendore in un computer diverso dal mio! Il P&D aveva svolto il suo compito, ma non ne ero per nulla soddisfatto...

Il dubbio e il problema principale
Quanta fatica però! Ma non esisteva proprio un software che potesse sostituirsi allo sviluppatore per la creazione di un compito meccanico, ma allo stesso tempo lungo e meticoloso, dove ogni disattenzione poteva inficiare l'intera preparazione del pacchetto di installazione creato fino a quel punto? Sembra proprio un compito adatto a un software per computer, quello di sostituirsi all'operatore "umano" per automatizzare operazioni noiose e ripetitive scongiurando la possibilità di errori. Dunque, siccome in informatica per ogni problema esistente almeno dieci persone al mondo l'hanno già risolto, dove risiedono questi software alternativi al P&D?

Già, perché non è che il P&D di VB non risulti idoneo al suo scopo, anzi. Solamente non automatizza granché molto il lavoro dello sviluppatore, senza contare il numero di bug che introduce nel procedimento di installazione vero e proprio e, forse la cosa più importante, non è stato più aggiornato da Microsoft per seguire lo sviluppo dei sistemi operativi Windows succedutisi dopo il rilascio dell'ultimo service pack per VB6. Ed è proprio questo, dunque, il più grosso problema di P&D: non essendo stato modificato per essere perfettamente compatibile con le ultime versioni di Windows, il P&D non può conoscere le loro peculiarità e risulta quindi piuttosto pericoloso, poiché quasi sempre, nei pacchetti di installazione con esso creati, viene richiesto l'aggiornamento di file di sistema (come OLEAUT32.DLL) che in Win2000, XP e successivi, devono essere aggiornati unicamente tramite Service Pack per il sistema operativo stesso (secondo le specifiche della stessa Microsoft) e non da parte di un comune programma, men che meno da un installer. Se si sovrascrivessero tali file, perché il pacchetto viene creato da una macchina più aggiornata (es. WinXP) rispetto a quella dell'utente finale (es. una qualsiasi versione Win9x oppure anche WinNT o 2000), ecco che il sistema diverrebbe nel migliore dei casi completamente instabile, nel peggiore risulterebbe persino impossibile avviarlo.

La decisione
Ecco perché il P&D può causare gravi e diversi danni al sistema ed ecco perché, pur non sapendo di quest'ultimo, più importante, potenziale problema, decisi, subito dopo le mie tribolazioni con il mio primo pacchetto di installazione, di non utilizzare più P&D, ma di rivolgermi verso altri lidi.

Quali? Beh, sul mercato le offerte non mancavano di certo: "InstallShield" e "Wise" per citare i più blasonati, ma anche molto costosi. Sul freeware, ci sono "Visual Studio Installer" della stessa Microsoft e "Inno Setup", oppure svariati altri front end (la maggior parte dei quali tutt'altro che gratuiti) che non fanno altro che utilizzare Windows Installer come motore e proporre unicamente un'interfaccia grafica alternativa rispetto alla concorrenza.

Poiché ero alla ricerca di qualcosa di gratuito e non soddisfatto nemmeno dei prodotti a pagamento, ecco l'illuminazione: perché non creare un installer raccogliendo le richieste del maggior numero possibile di sviluppatori e che facesse di affidabilità e facilità d'uso i suoi due più importanti capisaldi?

L'alternativa
Nacque così CyberInstaller [da ora in avanti "CIS" ossia CyberInstaller Suite], dapprima solo come motore di installazione programmabile tramite uno script testuale, poi arricchitosi di un motore per trasformare i pacchetti creati in eseguibili compressi auto-estraenti e infine di un front end grafico che assiste lo sviluppatore nell'intera creazione del pacchetto di installazione, compilando automaticamente lo script testuale in base alle scelte dello sviluppatore e preparando automaticamente l'adeguata struttura di file e cartelle necessaria. Naturalmente poi, il motore principale è stato, durante questi anni, arricchito continuamente, in modo da stare al passo con le ultime release di Windows e delle ultime tecnologie software messe a disposizione da Microsoft (DAO, ADO, .Net, ecc.) o da terzi (Crystal Reports, ecc.).

Le soluzioni (tutte in una!) ai problemi
Da quando gode di un front end grafico, CIS (CyberInstaller Studio) garantisce la soluzione all'annoso problema del riconoscimento di tutte le dipendenze di un progetto VB (o di altri linguaggi, compresi quelli per la piattaforma .Net), tramite la scansione del file di progetto (.vbp, o del gruppo di progetti .vbg). Il Trova Dipendenze incluso permette (senza ricorrere per forza a tool di terze parti come ProcessExplorer di SysInternals) di vedere di cosa necessita il nostro applicativo per essere eseguito correttamente su qualsiasi sistema destinazione, inserendo gli adeguati installer di terze parti (es. MDAC per ADO di Microsoft, o il Framework .Net) e gli OCX utilizzati, più qualsiasi altro file utilizzato (font, immagini, help in linea, ecc.) e, naturalmente, aggiungendo tutto il necessario al pacchetto di installazione. Per quei componenti più ostici (come Crystal Reports), CIS garantisce la piena compatibilità con i file MSI (Microsoft Installer) e MSM (Microsoft Merge Modules), di Windows Installer, inserendo anch'essi nel pacchetto di installazione, se necessario, e garantendone la corretta esecuzione all'interno dell'installazione stessa. In aggiunta, per evitare conflitti tra versioni diverse di componenti precedentemente installati, offre un pieno supporto alla tecnologia side-by-side di Microsoft. Il tutto automaticamente, sgravando lo sviluppatore da uno dei compiti che più spesso si rivela essere fonte di errori in sede di installazione, visto l'impegno che richiede.

CIS sancisce poi la fine dei continui riavvii del sistema o di tutti quei bug dovuti a un mancato aggiornamento da parte del produttore dell'installer, in quanto è un progetto software in continuo sviluppo e segue da vicino ogni cambiamento delle tecnologie e degli standard Windows. E questo si collega direttamente al problema principale di P&D: CIS garantisce la massima affidabilità e sicurezza nell'installazione dei propri pacchetti di installazione, mettendo sempre al primo posto la stabilità della macchine su cui si effettua la loro installazione. Addirittura, è l'unico installer che include nativamente una procedura di roll-back che garantisce di riportare completamente il sistema allo stato precedente l'installazione, cosa non fattibile con una normale disinstallazione del pacchetto di qualsiasi altro installer. E naturalmente, CIS non pensa nemmeno ad inserire nel pacchetto file di sistema che non devono essere aggiornati se non da Service Pack del sistema operativo! Altra prova dell'attenzione di CIS verso il sistema dell'utente, è la generazione di un report dettagliato non solo prima dell'installazione stessa, ma anche di ogni operazione effettuata durante durante il processo, per permettere di sapere sempre quali modifiche sono state apportate al sistema destinazione e con quale esito.

Oltre a ciò, CIS dà all'utente la possibilità di installare qualsiasi font utilizzato nella propria applicazione, avviare applicazioni esterne durante il processo di installazione principale (che possono essere anche sotto-pacchetti di installazione), creare chiavi e valori nel registro di Windows, associare estensioni al proprio eseguibile, creare collegamenti (sul desktop o nel Menu di Avvio) e molto altro ancora.

Infine, CIS mostra all'utente finale un'interfaccia grafica in linea con gli standard Microsoft più attuali, adattandosi ai temi del desktop impostati dall'utente e alle caratteristiche visuali del sistema operativo utilizzato (CIS supporta qualsiasi versione di Windows, da Win95 a WinXP, comprese le versioni Server).

NOTA: questo articolo non vuole essere una guida esauriente su CIS, ma visitando il sito ufficiale di CyberInstaller sarà possibile avere un quadro completo di tutte le funzionalità offerte.

Previsione 3: Qualcosa potrebbe andare comunque storto...
Perché le installazioni saranno sempre la bestia nera di qualunque sviluppatore, dato l'enorme numero di variabili in gioco, per di più imprevedibili visto che non possiamo sapere su quale configurazione hardware e software il nostro pacchetto di installazione verrà installato. Possibili conflitti, dovuti a particolari software preesistenti, o peggio a problemi hardware o driver particolarmente suscettibili, sono sempre in agguato. La combinazione di tutto il sistema con i programmi già installati e il nostro pacchetto di installazione deve incastrarsi perfettamente, altrimenti qualcosa - più o meno grave che sia - andrà sicuramente storto, purtroppo. E questo non potrà risolverlo nemmeno il più costoso installer sul mercato...

...ma molto andrà bene!
Però almeno CIS potrà, a costo zero, agevolarci il più possibile e permetterci di installare il nostro applicativo in modo professionale anche se non si è esperti in installazioni, mettendo a disposizione tutti gli strumenti necessari per poter correre ai ripari in caso qualcosa andasse male, garantendo sempre (e questo in tutti i casi) l'affidabilità del sistema destinazione senza minarne la stabilità operativa.

Quindi sì, qualcosa potrebbe andare comunque storto, ma si possono comunque dormire sogni tranquilli, magari infatti al secondo tentativo una piccola revisione manuale al pacchetto ci garantirà quel successo che al primo tentativo ci è stato negato dalla cattiva sorte.

Conclusioni e consigli
CIS ha vinto parecchi riconoscimenti, ma nonostante le medaglie i vari "editor's choice" non può sostituirsi allo sviluppatore, nessun installer può farlo. Ciò che conta davvero è la perizia di chi prepara il pacchetto di installazione, controllando sempre minuziosamente il pacchetto di installazione risultante; solo lo sviluppatore, autore dell'applicazione che si andrà ad installare, sa (o meglio: dovrebbe sapere...) con esattezza di cosa necessita il software appena compilato e potrà sfruttare tutti gli automatismi e gli strumenti messi a disposizione da CIS per far sì che il suo obiettivo - quello di permettere ad ogni potenziale utente un'installazione indolore ed efficace - venga perseguito nel modo più rapido possibile e scongiurando ogni possibilità di errore.

Un consiglio che mi sento di dare nella preparazione di un pacchetto di installazione, qualunque installer si utilizzi, è quello di testare, testare, testare e ancora testare. Prima di tutto sulla propria macchina di sviluppo, successivamente (se il test va a buon fine), sarà necessario provare il pacchetto su una configurazione pulita, magari su versioni di Windows differenti, per eliminare la possibilità che il pacchetto funzioni solo su questo o quel sistema solo perché magari il componente di cui necessita il nostro programma è stato installato da un'altra applicazione (o da Windows stesso), ma che noi ci siamo dimenticati di inserire nel pacchetto. A questo proposito è conveniente utilizzare macchine virtuali con installazioni pulite di varie versione di Windows, una per ogni macchina virtuale (e adesso che software come "VMWare" o "Microsoft Virtual PC" sono gratuiti, non ci sono più scuse all'utilizzo di macchine virtuali a fini di test dei propri pacchetti di installazioni); questo garantirà i test più affidabili e contemporaneamente un risparmio considerevole di tempo.

NOTA: è naturale preventivare il dover tornare alla modifica del pacchetto di installazione dopo l'esito dei vari test, probabilmente più volte, prima di raggiungere un pacchetto di installazione che soddisfi pienamente gli standard qualitativi imposti dal mercato. CIS si rivelerà un valido strumento per limitare il più possibile l'eventualità di dover rimettere mano a un pacchetto creato.

Un ulteriore consiglio è quello di non utilizzare mai strumenti obsoleti nella creazione del proprio pacchetto di installazione, ragion per cui il P&D dovrebbe essere automaticamente scartato in favore di installer in linea con gli standard Microsoft attuali e, soprattutto, che hanno un occhio di riguardo alla stabilità del sistema destinazione (affidabilità dell'installazione). Vi garantisco che CIS non vi deluderà sotto questo punto di vista.

Il valore aggiunto di CIS
Qualcosa che conferisce a CIS un valore aggiunto rispetto a molti altri installer compreso il P&D, è il fatto che esso è supportato attivamente da me e da una nutrita comunità di utenti. CIS è in continuo sviluppo per adattarlo alle richieste fatte da ogni sviluppatore, che cerco di accontentare implementando ogni funzionalità desiderata e comunicatami. Inoltre, al verificarsi o alla segnalazione di un bug, questo viene risolto nel minor tempo possibile e una patch verrà messa a disposizione per il download tramite un sistema di aggiornamento automatico di CIS stesso.

Con quanti software avete la possibilità di interagire direttamente con l'autore per esprimere il vostro feedback in merito? CIS è uno di questi. Me ne dimentico spesso anch'io, ma non è cosa da poco, perché dà garanzia alla fiducia data dagli utenti, mettendoli in condizione di poter partecipare al suo miglioramento ed evoluzione continua.

Questo valore viene decisamente a mancare con il P&D, poiché Microsoft ne ha cessato il supporto da tempo. E sviluppare con uno strumento senza supporto tecnico è, di fatto, alquanto rischioso.

Note sull'autore
Sergio Pappalardo nasce ad Asolo (TV) nel 1978, nel corso degli anni nutre una particolare propensione verso i computer e tutto ciò che li circonda. Liceo Scientifico Tecnologico, Università di Informatica al dipartimento DSI Ca' Foscari di Venezia e adesso professionista indipendente nel ramo dello sviluppo software.
Ulteriori informazioni sul suo sito web.

Feedback
E' possibile contattare Sergio Pappalardo via email per approfondimenti ulteriori riguardo questo articolo o per suggerimenti, critiche o semplicemente ricevere informazioni sul software "CyberInstaller Suite".