Overview della tecnologia

ClickOnce è il “nome in codice” di una delle nuove tecnologie che vedranno la luce parzialmente con il rilascio di Whidbey e completamente con il rilascio di Longhorn. Longhorn è a sua volta il nome in codice della prossima versione di Windows, il cui rilascio è attualmente previsto/ipotizzato per la fine del 2005.

L’obiettivo di ClickOnce è quello di mettere a disposizione di noi sviluppatori uno strumento che ci permetta di rilasciare in modo comodo e rapido le applicazioni, sia per la piattaforma Windows 2000/2003/XP che per Longhorn stesso. Tramite ClickOnce l’utente finale sarà in grado di utilizzare un’applicazione Windows Forms (cioè un’applicazione .NET per Windows) o Avalon (altro nome in codice per l’ambiente grafico di hosting delle applicazioni basate su finestre per Longhorn) con un solo click del mouse, come appunto recita il nome.

Jamie Cool, uno dei PM del team di sviluppo di ClickOnce, ha dichiarato a PDC 2003 che si sono ispirati alla semplicità di utilizzo delle applicazioni Web, nelle quali basta digitare la URL del sito per usufruire delle sue funzionalità. Con la stessa logica anche il deployment di applicazioni Windows tramite ClickOnce potrà avvenire utilizzando una pagina Web, al cui interno troveremo un link per il deployment automatizzato del programma. Ovviamente sarà possibile eseguire il deployment anche da cartelle condivise, CDROM, ecc. ma la novità è la possibilità di eseguire il deployment rapido da una pagina Web.

 

 

[La pagina di deployment via Web.]

 

L’utente finale vedrà solo una piccola e semplice schermata, che lo informerà del fatto che l’applicazione, se ottenuta da un server trusted, è in fase di installazione. Come vedremo successivamente, sono previste delle politiche di security che consentono di far scegliere all’utente finale se installare o meno soluzioni software non “trusted”, per evitare il proliferare di virus via ClickOnce!

 

[Il popup in centro allo schermo, che informa l’utente delle fasi di installazione.]

 

[L’applicazione finale in esecuzione.]

 

In fase di rilascio potremo decidere se le nostre applicazioni dovranno essere utilizzabili solo on-line, cioè connessi al server di rilascio, oppure se l’utente finale dovrà disporre di una copia locale dell’eseguibile, per poterlo utilizzare anche off-line, richiamandolo con la classica icona nel menù avvio, che sarà in tal caso creata per noi da ClickOnce. Inoltre le applicazioni rilasciate con ClickOnce, se lo vorremo, saranno in grado di gestire automaticamente, sia per noi sviluppatori che per gli utenti finali, l’aggiornamento a versioni e/o ricompilazione successive.

Dal punto di vista operativo ClickOnce si riconduce a qualche cartella e a un paio di file XML (ecco perché mi piace J ... !) che possiamo creare manualmente, ma che possiamo anche farci comodamente creare da Visual Studio .NET Whidbey, che è completamente integrato con ClickOnce.

 

Partendo da un qualsiasi progetto di applicazione possiamo infatti utilizzare un wizard le cui fasi salienti sono illustrate nelle seguenti immagini.

 

[La voce di menù per la pubblicazione.]

 

[Il primo passo del wizard: la scelta della URL alla quale rendere disponibile il pacchetto di deployment automatico.]

 

[La schermata che ci permette di scegliere la modalità di pubblicazione on-line/off-line.]

 

[Il riepilogo di quanto scelto.]

 

Con il wizard appena mostrato (menù Project->“Publish Project” di Whidbey) è possibile creare una cartella Web (pubblicata via UNC, FTP o FrontPage Extensions), che renderà disponibile il setup dell’applicazione e l’eventuale setup di prerequisiti software, quali il Framework .NET, MDAC, il motore di Crystal Report, ecc. In questo momento i requisiti software per poter utilizzare ClickOnce sono:

·         Sul Server: un qualsiasi server Web (come IIS) in grado di fornire il download di risorse e tipologie di documenti non solo HTML (.deploy, .manifest, .exe, ecc.).

·         Sul PC di sviluppo: Visual Studio .NET Whidbey nella versione Alfa rilasciata a PDC 2003 (o successive).

·         Sul client: .NET Framework nella versione Alfa rilasciata a PDC 2003 (o successive).

 

Tutte le impostazioni sono configurabili da Visual Studio .NET Whidbey, tramite le proprietà del progetto.

 

[Ho riassunto in una sola schermata i parametri relativi all’aggiornamento automatico e ai prerequisiti da rendere disponibile in fase di bootstrap.]

 

In apertura ho detto che ClickOnce vedrà la luce con Whidbey ma il suo rilascio definitivo avverà con Longhorn. Infatti, sempre che in Microsoft non cambino idea (in questo momento siamo alla versione Alfa...), alcune funzionalità come la registrazione automatica di estensioni alla Shell, l’associazione di estensioni di file ai relativi programmi installati e la possibilità di gestire la configurazione dinamica delle applicazioni, saranno disponibili solo con Longhorn. Inoltre con Longhorn sarà possibile eseguire il download degli aggiornamenti in background, durante l’utilizzo della versione attualmente disponibile del programma. Pare che sarà sfruttata un’evoluzione del motore di Windows Update.

Ma come funziona?

Quando pubblichiamo un’applicazione con il wizard di Whidbey, otteniamo una directory che contiene dei file simili ai seguenti:

 

[Il contenuto della cartella di deployment pubblicata sul Web.]

 

Come si vede al suo interno trovano posto i file:

·         Publish.htm: è la pagina che abbiamo visto nella prima immagine.

·         Setup.exe: è il bootstrapper che installa i prerequisiti, qualora necessari.

·         AvalonAppDemo.deploy: è il primo dei due file XML di deployment.

 

Il file AvalonAppDemo.deploy avrà il seguente contenuto:

 

<?xml version="1.0" encoding="utf-8"?>
<assembly
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd"
manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity name="AvalonAppDemo.deploy" version="1.0.0.1"
publicKeyToken="0000000000000000" processorArchitecture="x86"
asmv2:culture="en-US" />
<description asmv2:publisher="AvalonAppDemo" asmv2:product="AvalonAppDemo">
</description>
<deployment isRequiredUpdate="false" xmlns="urn:schemas-microsoft-com:asm.v2">
<install shellVisible="true" />
<subscription>
<update>
<periodic>
<minElapsedTimeAllowed time="0" unit="hours" />
</periodic>
</update>
</subscription>
<deploymentProvider codebase="AvalonAppDemo.deploy" />
</deployment>
<dependency>
<dependentAssembly>
<assemblyIdentity name="AvalonAppDemo.manifest"
version="1.0.0.1" publicKeyToken="0000000000000000"
processorArchitecture="x86" asmv2:culture="en-US" />
</dependentAssembly>
<asmv2:installFrom codebase="AvalonAppDemo_1.0.0.1/AvalonAppDemo.manifest" />
</dependency>
</assembly>

 

Trattandosi di un articolo introduttivo non entrerò in tutti i dettagli del file, ma ritengo utile sottolineare il significato delle parti che ho evidenziato in grassetto, nell’ordine in cui compaiono:

 

·         Abbiamo l’identità dell’applicazione data da nome, versione, publicKey token e cultura.

·         Abbiamo l’indicazione del fatto che dovrà essere disponibile off-line (shellVisible=true).

·         Abbiamo la notizia del fatto che il file AvalonAppDemo.manifest, in una determinata versione, è collegato a questo deployment.

·         Infine possiamo sapere che l’installazione andrà eseguita sulla base della cartella AvalonAppDemo_1.0.0.1 e del suo file AvalonAppDemo.manifest, che corrispondono all’ultima versione disponibile del setup.

 

Sarà possibile firmare digitalmente (XMLDSIG) i file di deployment, per aumentare la sicurezza del deployment. Anche la pubblicazione di nuove versioni, sui server di deployment, potrà essere vincolata alla disponibilità di certificati digitali di autenticazione di chi sta pubblicando, per evitare manomissioni.

Le sottocartelle sono tante quante le versioni rilasciate, più  una che contiene il pacchetto di installazione del runtime del framework (DOTNETFX.EXE). Le altre corrispondono alle possibili versioni del software.

Osserviamo brevemente anche il file .manifest:

 

<?xml version="1.0" encoding="utf-8"?>
<assembly
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd"
manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <assemblyIdentity name="AvalonAppDemo.manifest" version="1.0.0.1"
 publicKeyToken="0000000000000000" processorArchitecture="x86" 
 asmv2:culture="en-US" language="x-ww" />
<description>
</description>
<asmv2:configuration configFile="System.Storage.tlb.manifest" />
<entryPoint name="main" dependencyName="AvalonAppDemo"
xmlns="urn:schemas-microsoft-com:asm.v2">
<commandLine file="AvalonAppDemo.exe" parameters="run" />
</entryPoint>
<TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<Security>
<ApplicationRequestMinimum>
<PermissionSet ID="LocalIntranet">
<IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1" Read="USERNAME" />
<!-- Omissis -->
</PermissionSet>
<DefaultAssemblyRequest PermissionSetReference="LocalIntranet" />
</ApplicationRequestMinimum>
</Security>
</TrustInfo>
<dependency asmv2:name="AvalonAppDemo">
<!-- Omissis -->
</dependency>
  <file name="Readme.html" 
hash="39F617A65F738D292523390A2A569956BDA43C99" 
hashalg="SHA1" asmv2:size="106629" />
</assembly>

 

In questo secondo file, che può anche essere generato manualmente con il tool mg.exe (Manifest Generator), trovano posto sempre in grassetto e in ordine di presenza:

 

·         Come prima l’identità del manifest.

·         L’entrypoint dell’applicazione.

·         Le informazioni sulla sicurezza, intese come minima richiesta di permessi necessari al corretto funzionamento del programma.

·         Eventuali dipendenze da altri file, dei quali viene fornito anche un hash e la dimensione per evitarne la manomissione o il download parziale

 

Proprio in merito alla sicurezza e ai requisiti minimi per il corretto funzionamento del programma occorre dire che questi saranno configurabili manualmente o da Visual Studio .NET, sempre dalle opzioni del progetto.

 

[Pannello di selezione del livello di trust minimo per il progetto.]

 

Ancora sul fronte della sicurezza sarà anche possibile far sì che l’utente debba dare il proprio consenso all’installazione di applicazioni che non provengono da contesti “trusted”.

 

Dopo aver letto queste righe introduttive qualcuno potrebbe chiedersi: “E cosa c’è di diverso dal URL deployment di un eseguibile .NET attuale?!”.

Bene, innanzitutto per poter eseguire un’applicazione che rendiamo disponibile via URL, con l’attuale versione del Framework .NET, dobbiamo avere il Framework già installato sul client. Con ClickOnce invece sarà possibile installare in automatico anche il Framework stesso. Nel caso di deployment via URL inoltre il client oggi non è in grado di accorgersi da solo di nuove release del software (al limite si accorge solo di nuove versioni del file sul Web server), ma siamo noi a doverglielo dire, per esempio intevenendo sul file .config del client (in caso di class library), oppure utilizzando soluzioni come l’Application Updater. Quando installiamo un’applicazione con ClickOnce, se scegliamo il deployment che renda disponibile l’applicazione anche off-line, sarà create una voce di un-install nell’apposita sezione del pannello di controllo, cosa che ancora una volta non accade oggi con il deployment via HTTP di .NET 1.x. Vi sono altre differenze e novità rispetto al deployment dell’attuale versione di Framework .NET, ma quelle appena viste sono tra le più significative.