Condividi tramite


Determinazione di quando usare Windows Installer e XCOPY

 

Martin Wasznicky
Microsoft Corporation

Gennaio 2002

Riepilogo: Esamina e confronta due approcci per la distribuzione di applicazioni Microsoft .NET: il comando DOS XCOPY e la tecnologia Microsoft Windows Installer. (8 pagine stampate)

Obiettivi

  • Informazioni su quando e come usare XCOPY per la distribuzione di soluzioni Microsoft® .NET
  • Informazioni su quando usare Microsoft® Windows® Installer per la distribuzione di soluzioni .NET

Presupposti

Per sfruttare al meglio questo documento, tenere presente quanto segue:

  • Si è esperti programmatori di Microsoft® Visual Basic®
  • Sono state distribuite applicazioni con Il programma di installazione di Microsoft® Visual Studio® o Microsoft Windows Installer 2.0
  • È stato usato il comando DOS XCOPY
  • È possibile accedere a .NET e Microsoft® Internet Information Server (IIS)

Contenuto

Introduzione
Uso di XCOPY
Windows Installer
Novità di Visual Studio .NET
Riepilogo

Introduzione

Microsoft .NET Framework offre diverse nuove funzionalità in modo da semplificare la distribuzione dell'applicazione come un'operazione XCOPY. Molti sviluppatori hanno familiarità con i problemi di distribuzione di applicazioni COM tradizionali; registrazione di classi e librerie dei tipi, mantenimento della compatibilità binaria e mancanza di distribuzione di componenti side-by-side (tutto questo viene talvolta definito "DLL HELL"). Regedt32.exe è diventato uno strumento familiare nell'arsenale di distribuzione dei componenti dello sviluppatore a causa delle dipendenze che COM ha con il Registro di sistema.

Con l'introduzione degli assembly e del controllo delle versioni in .NET Framework, il cavo umbilicale al Registro di sistema viene infine tagliato. Poiché gli assembly sono autodescrittori (contengono metadati che descrivono, tra l'altro, i tipi, le risorse e gli assembly a cui si fa riferimento), la dipendenza dal Registro di sistema viene rimossa, rendendo la promessa di distribuzioni XCOPY in realtà.

Tuttavia, sembra interessante la distribuzione XCOPY, come qualsiasi tecnologia, ha le sue limitazioni. A seconda della complessità e delle esigenze di automazione di uno scenario di distribuzione specifico, XCOPY potrebbe non essere in grado di soddisfare le esigenze di distribuzione di un'applicazione. In questi casi, .NET Framework si integra con la tecnologia Microsoft Windows Installer 2.0 per fornire opzioni di installazione, distribuzione e distribuzione alternative per lo sviluppatore. Visual Studio .NET offre inoltre progetti di installazione e distribuzione basati sulla tecnologia Windows Installer 2.0. Ciò consente agli sviluppatori di creare facilmente pacchetti di installazione e distribuzione per le applicazioni più complesse basate su .NET Framework.

In questo documento sono trattati due argomenti principali:

  • Uso di XCOPY: Panoramica del comando DOS XCOPY usato come strumento per la distribuzione di applicazioni .NET. Verranno illustrate le limitazioni e gli usi di XCOPY, tra cui la persistenza delle informazioni ACL di sicurezza, gli attributi di file e cartelle, la generazione del sistema di cartelle e le violazioni di condivisione.
  • Windows Installer: Panoramica della tecnologia Windows Installer e analisi delle relative funzionalità esposte da .NET. Viene esaminata anche l'adeguatezza di quando usare la tecnologia Windows Installer rispetto a XCOPY.

Uso di XCOPY

La distribuzione di applicazioni consiste in genere nella distribuzione dell'applicazione o del componente finale nei computer in cui verrà eseguita l'applicazione. A causa della natura autodescrittura di assembly .NET, la distribuzione e la replica di . Le applicazioni create da NET che usano XCOPY sono diventate realtà perché, in molti casi, non è più necessario modificare il Registro di sistema o eseguire altre attività ausiliarie, ad esempio l'arresto di un servizio Microsoft® Windows® NT. La semplicità degli assembly rende XCOPY uno strumento appropriato da usare in determinati scenari di distribuzione specifici.

Alcune applicazioni che si prestano molto facilmente alla distribuzione e alla replica XCOPY sono Servizi Web XML e ASP.NET applicazioni Web. In precedenza, questi tipi di applicazioni venivano compilati usando Internet Information Services (IIS) e i componenti COM tradizionali. L'installazione dei componenti per queste applicazioni comporta in genere la registrazione del componente durante il processo di distribuzione tramite l'utilità Regsvr32.exe. L'aggiornamento dei componenti esistenti era molto più problematico, perché IIS ha inserito un blocco di file esclusivo sui componenti. L'unico modo per rilasciare il blocco era arrestare IIS. La sostituzione dei componenti esistenti include in genere i passaggi seguenti:

  1. Arrestare il servizio IIS.
  2. Annullare la registrazione del componente precedente usando l'utilità Regsvr32.exe.
  3. Copiare un nuovo componente.
  4. Registrare un nuovo componente usando l'utilità Regsvr32.exe.
  5. Avviare il servizio IIS.

Questi passaggi non sono più necessari per i servizi Web XML e le applicazioni Web ASP.NET. IIS non inserisce blocchi di file esclusivi negli assembly .NET e, poiché gli assembly sono autodescrittura, non devono essere registrati. Ciò rende ASP.NET applicazioni basate sul Web ideali per la distribuzione e la gestione di XCOPY.

Ad esempio, verrà illustrata la distribuzione di un servizio Web XML in un computer remoto che si trova nello stesso dominio Di Windows NT. Ai fini di questo esempio, il computer client in cui si trova attualmente l'applicazione Web è denominato CLIENT1 e il computer remoto, in cui verrà distribuita l'applicazione Web, è denominato SERVER1.

Ecco l'aspetto della struttura di directory dell'applicazione Web da distribuire.

Figura 1. MMC di Internet Information Service in CLIENT1 che visualizza la directory virtuale dell'applicazione Web DemoWebSrv ASP.NET per la distribuzione in SERVER1

All'interno della sottodirectory /bin è presente un assembly denominato DemoWebSrv.DLL. Il percorso fisico della struttura di directory in CLIENT1 è C:\INETPUB\WWWROOT\DEMOWEBSRV. Il percorso, C:\INETPUB\WWWROOT in CLIENT1 è mappato al nome della condivisione di rete di WWWROOT

Per iniziare lo scenario di distribuzione, seguire questa procedura:

  1. Creare una condivisione di rete in SERVER1 denominata WWWROOT ed eseguirne il mapping alla sottodirectory wwwroot che si trova nella directory InetPub. Si tratta del percorso predefinito del sito Web predefinito iis. Questo percorso verrà usato come argomento di destinazione del comando XCOPY.

  2. Copiare la struttura di cartelle e i file della directory dell'applicazione del sito Web DemoWebSrv che si trova in CLIENT1 in SERVER1 usando XCOPY. Al prompt di DOS digitare il comando seguente (il primo argomento del comando XCOPY è la directory di origine da cui copiare; il secondo argomento è la directory di destinazione in cui eseguire la copia):

    XCOPY \\CLIENT1\wwwroot\demowebsrv 
    \\SERVER1\wwwroot\demowebsrv /E /K /R /O /H /I
    
  3. Creare una directory virtuale denominata DemoWebSrv nel sito Web predefinito in SERVER1 e contrassegnarla come applicazione. Eseguirne il mapping alla directory C:\INETPUB\WWWROOT\DEMOWEBSRV appena creata.

Verrà quindi visualizzata la spiegazione delle opzioni usate alla fine del comando XCOPY. Per visualizzare un elenco più completo, digitare XCOPY /? al prompt dei comandi DOS.

  • / E copia directory, sottodirectory e file dell'argomento di origine, inclusi quelli vuoti.
  • / K copia tutti gli attributi di file e cartelle esistenti.
  • Quando si usa XCOPY per copiare file o una struttura ad albero di directory, XCOPY rimuove gli attributi di file per impostazione predefinita. Ovvero, se un file ha impostato l'attributo di sola lettura, una volta copiato, l'attributo viene perso. Per mantenere (applicare) gli attributi originali con i file copiati, usare il parametro /K .
  • / R sovrascrive i file contrassegnati come di sola lettura.
  • / O mantiene tutti gli ACL di autorizzazione correlati alla sicurezza del file e delle cartelle.
  • / H copia sia i file nascosti che i file di sistema.
  • / I indica a XCOPY di presupporre che la destinazione sia una directory e la crea se non esiste già. Poiché l'argomento di destinazione \ <\SERVER1\wwwroot\demowebsrv>, è una directory che non esiste, XCOPY lo crea.

Tutto qui. XCOPY distribuisce correttamente il servizio Web XML in SERVER1. XCOPY è ideale per distribuzioni semplici come queste e per gli aggiornamenti in tempo reale. XCOPY è utile anche per la distribuzione di applicazioni desktop nel client.

Come per qualsiasi tecnologia, esistono limitazioni relative a come e quando usare XCOPY per distribuire . Applicazioni predefinite di NET. In genere, XCOPY è utile solo negli scenari di distribuzione semplici ed eseguiti manualmente. Di seguito sono elencati alcuni casi in cui XCOPY non è sufficiente; questi richiederebbero un metodo di distribuzione più affidabile.

  • Distribuzione automatica dei componenti COM per le applicazioni .NET con cui interagire. La registrazione è ancora obbligatoria.
  • Precompilare un assembly in codice nativo nel computer remoto.
  • Installazione di assembly nella Global Assembly Cache del computer remoto.
  • Aggiornamento di file bloccati esclusivamente. Ad esempio, un servizio Windows NT usato per ospitare una soluzione di comunicazione remota .NET.
  • Installazione. Servizi Windows NT predefiniti per NET.
  • Configurazione e creazione automatizzate delle impostazioni della directory IIS, impostazioni di sicurezza NTFS, condivisioni di rete e account utente e gruppo di Active Directory.
  • Creazione automatica di collegamenti desktop, aggiunta a Installazione applicazioni, creazione di voci di menu Start e così via.

Anche se XCOPY funziona bene per soluzioni semplici, esistono ovviamente molti casi in cui viene garantita una soluzione di distribuzione più affidabile. Tale opzione viene fornita dal programma di installazione di Visual Studio .NET, basato sulla tecnologia Windows Installer 2.0. Questo aspetto verrà esaminato più avanti.

Windows Installer

Spesso, i requisiti di configurazione delle applicazioni sono molto più complessi, quindi quelli che possono essere gestiti da una semplice strategia di distribuzione XCOPY. In molti casi, la soluzione di distribuzione finale è destinata agli utenti finali che non dispongono delle competenze necessarie per configurare manualmente un'applicazione. In altri casi, potrebbero esserci così tanti requisiti di configurazione ,ad esempio la creazione di utenti e gruppi, la configurazione della sicurezza, la creazione di strutture di directory e così via, che un programma di installazione automatizzato diventa necessario per garantire la precisione e la coerenza nel comportamento installato dell'applicazione finale. In entrambi i casi, una distribuzione XCOPY in genere non è sufficiente per soddisfare tali requisiti.

Per esigenze di distribuzione e applicazioni più affidabili, è possibile usare Visual Studio .NET per compilare pacchetti di installazione e distribuzione. La distribuzione di Visual Studio .NET è basata sulla tecnologia Windows Installer. Windows Installer è un servizio di installazione e configurazione software fornito con i sistemi operativi Microsoft® Windows® 2000 e Windows XP ed è distribuito liberamente a tutte le piattaforme Win9x e NT4. Il servizio Windows Installer gestisce un record di informazioni su ogni applicazione installata. Il runtime di Windows Installer controlla questi record durante l'esecuzione dei pacchetti di distribuzione. Quando un'applicazione viene disinstallata, i record vengono controllati per assicurarsi che nessun'altra applicazione si basi sui relativi componenti prima di rimuoverla. Windows Installer 2.0 è stato esteso per fornire le funzionalità seguenti per supportare gli assembly .NET:

  • Installazione, ripristino o rimozione di assembly nella Global Assembly Cache.
  • Installazione, ripristino o rimozione di assembly in percorsi definiti dall'utente.
  • Rollback di installazioni, riparazioni o rimozioni di assembly non riuscite.
  • Installazione su richiesta di assembly nella Global Assembly Cache.
  • Installazione su richiesta di assembly in percorsi definiti dall'utente.

Oltre a queste funzionalità, i progetti di distribuzione .NET di Visual Studio consentono tutte le comodità di altri programmi di installazione, ad esempio la lettura e la scrittura di chiavi del Registro di sistema, la creazione della directory, la registrazione dei componenti, la raccolta di dati immessi dall'utente durante l'installazione e così via. Altre funzionalità incluse sono:

  • Possibilità di impostare le condizioni di avvio, ad esempio il controllo del nome utente corrente, il nome computer, l'ambiente fisico, il sistema operativo corrente, l'esistenza di CLR .NET e così via.
  • Possibilità di eseguire un programma o uno script personalizzato al termine dell'installazione effettiva. I dati raccolti dall'installazione possono essere passati al programma e l'intera installazione può essere eseguito il rollback se il programma genera un errore. Il programma può trovarsi in un .dll, .exe, script o in un assembly.

Per illustrare una distribuzione di Visual Studio .NET, verrà illustrata la distribuzione del servizio Web XML distribuito in precedenza con XCOPY.

  1. Per iniziare, aprire un progetto di servizio Web XML esistente denominato DemoWebSrv con Visual Studio .NET.

  2. Scegliere Aggiungi progetto dal menu File e quindi Nuovo progetto. Verrà visualizzata la finestra di dialogo Nuovo progetto (vedere la figura 2).

    Figura 2. Finestra di dialogo Nuovo progetto di Visual Studio .NET in cui sono visualizzati i modelli di distribuzione disponibili

  3. In Tipi di progetto fare clic sulla cartella Progetti di installazione e distribuzione , quindi fare doppio clic sul modello Progetto di installazione Web . Il progetto di installazione Web (WebSetup1) viene aggiunto alla soluzione esistente e viene aperto l'editor del file system.

  4. Nell'editor del file system fare clic sulla cartella Applicazione Web.

  5. Scegliere Aggiungi dal menu Azione e quindi fare clic su Output progetto.

  6. Nella casella Aggiungi gruppo di output del progetto (figura 3) selezionare DemoWebSrv dall'elenco Progetto .

    Figura 3. La finestra di dialogo Aggiungi gruppo di output progetto viene usata per aggiungere file specifici da un progetto a un altro

  7. Selezionare i gruppi Output primario e File di contenuto dall'elenco e fare clic su OK. In questo modo vengono aggiunti i file di contenuto e gli assembly compilati e le relative dipendenze al programma Windows Installer compilato (file .msi).

  8. Nell'editor del file system fare clic sulla cartella Applicazione Web. Nella finestra Proprietà impostare la proprietà VirtualDirectory su DemoWebSrv. Impostare la proprietà DefaultDocument su Customers.asmx. Windows Installer usa le informazioni per creare una directory virtuale nel sito Web predefinito del server di destinazione e impostare la relativa proprietà del documento predefinita.

  9. Scegliere Compila WebSetup1 dal menu Compila. Verrà creato un WebSetup1.msi file di installazione di Windows Installer.

  10. Copiare il file WebSetup1.msi nel computer server Web di destinazione e fare doppio clic sul file per eseguire il programma di installazione. Per accedere al servizio Web appena distribuito, avviare Internet Explorer e digitare l'URL <http://< ComputerName>/DemoWebSrv>.

Novità di Visual Studio .NET

  • La natura degli assembly .NET rende XCOPY un'opzione di distribuzione fattibile.
  • La tecnologia Windows Installer è stata estesa per gestire le esigenze di distribuzione di .NET Framework.
  • Gli strumenti di distribuzione .NET di Visual Studio sono basati sulla tecnologia Windows Installer.
  • Programma di installazione di Visual Studio è integrato in Visual Studio .NET. I modelli del programma di installazione vengono aggiunti come nuovi progetti e offrono opzioni di configurazione maggiori.

Riepilogo

Natura autodescrittura di . Gli assembly compilati da NET rendono possibile usare XCOPY per distribuire e aggiornare applicazioni semplici. XCOPY può gestire facilmente gli scenari di distribuzione che richiedono installazioni manuali con poche dipendenze e opzioni di configurazione. Servizi Web XML e applicazioni Web ASP.NET si prestano particolarmente bene a questo tipo di distribuzione, soprattutto durante la fase di sviluppo dell'applicazione.

Visual Studio .NET offre anche altri strumenti di distribuzione, basati su Windows Installer, che consentono requisiti di configurazione e automazione più flessibili e affidabili. L'uso di Visual Studio .NET per creare programmi Windows Installer consente agli sviluppatori di creare programmi di installazione sofisticati per le applicazioni più impegnative.

Quale opzione di distribuzione usare è determinata in definitiva dall'ambito e dalla profondità dei requisiti di configurazione dell'applicazione.

Informazioni sull'autore

Marty Wasznicky è un Senior Systems Engineer con Microsoft Corporation, concentrandosi su Enterprise Application Integration, Business to Business e E-Commerce. Ha più di dieci anni di esperienza nell'architettura e nell'implementazione di soluzioni nel settore IT, sia nelle capacità aziendali che di consulenza. È microsoft Certified Solutions Developer, Microsoft Certified Systems Engineer, Microsoft Certified Database Administrator e Certified Novell Engineer. Ha creato numerosi articoli sul journal del programmatore di Visual Basic e sulle riviste access/VB/SQL Advisor e attualmente lavora nel distretto della California meridionale di Microsoft.

Informazioni su Informant Communications Group

Informant Communications Group, Inc. (www.informant.com) è una società di media diversificata focalizzata sul settore informatico. Specializzata in pubblicazioni di sviluppo software, conferenze, pubblicazione di cataloghi e siti Web, ICG è stata fondata nel 1990. Con uffici nel Stati Uniti e nel Regno Unito, ICG ha servito come integratore di contenuti multimediali e di marketing rispettato, soddisfacendo l'appetito crescente di professionisti IT per informazioni tecniche di qualità.

Copyright © 2002 Informant Communications Group e Microsoft Corporation

Modifica tecnica: PDSA, Inc. e KNG Consulting