Condividi tramite

Creare applicazioni ClickOnce per la distribuzione da parte di terzi

  • Articolo

Non tutti gli sviluppatori che creano distribuzioni ClickOnce pianificano di distribuire le applicazioni stesse. Molti di loro si limitano a creare un pacchetto dell'applicazione usando ClickOnce e quindi consegnare i file a un cliente, ad esempio un'azienda di grandi dimensioni. Il cliente diventa responsabile dell'hosting dell'applicazione nella rete. Questo argomento illustra alcuni dei problemi relativi a tali distribuzioni nelle versioni di .NET Framework precedenti alla versione 3.5. Descrive quindi una nuova soluzione fornita usando la nuova funzionalità "usare il manifesto per l'attendibilità" in .NET Framework 3.5. Infine, conclude con le strategie consigliate per la creazione di distribuzioni ClickOnce per i clienti che usano ancora versioni precedenti di .NET Framework.

Problemi relativi alla creazione di distribuzioni per i clienti

Si verificano diversi problemi quando si prevede di fornire una distribuzione a un cliente. Il primo problema riguarda la firma del codice. Per essere distribuiti in una rete, il manifesto della distribuzione e il manifesto dell'applicazione di una distribuzione ClickOnce devono entrambi essere firmati con un certificato digitale. Ciò genera la domanda se usare il certificato dello sviluppatore o il certificato del cliente durante la firma dei manifesti.

La questione del certificato da usare è fondamentale, poiché l'identità dell'applicazione ClickOnce si basa sulla firma digitale del manifesto della distribuzione. Se lo sviluppatore firma il manifesto della distribuzione, potrebbe causare conflitti se il cliente è un'azienda di grandi dimensioni e più di una divisione dell'azienda distribuisce una versione personalizzata dell'applicazione.

Si supponga, ad esempio, che Adventure Works abbia un reparto finanziario e un reparto risorse umane. Entrambi i reparti con licenza di un'applicazione ClickOnce di Microsoft Corporation che genera report dai dati archiviati in un database SQL. Microsoft fornisce a ogni reparto una versione dell'applicazione personalizzata per i dati. Se le applicazioni sono firmate con lo stesso certificato Authenticode, un utente che tenta di usare entrambe le applicazioni riscontra un errore, perché ClickOnce considera la seconda applicazione identica alla prima. In questo caso, il cliente potrebbe riscontrare effetti collaterali imprevedibili e indesiderati che includono la perdita di dati archiviati localmente dall'applicazione.

Un problema aggiuntivo correlato alla firma del codice è l'elemento deploymentProvider nel manifesto della distribuzione, che indica a ClickOnce dove cercare gli aggiornamenti dell'applicazione. Questo elemento deve essere aggiunto al manifesto della distribuzione prima di firmarlo. Se questo elemento viene aggiunto in un secondo momento, il manifesto della distribuzione deve essere nuovamente firmato.

Richiedere al cliente di firmare il manifesto della distribuzione

Una soluzione a questo problema di distribuzioni non univoche consiste nell'avere lo sviluppatore firmare il manifesto dell'applicazione e il cliente firma il manifesto della distribuzione. Anche se questo approccio funziona, introduce altri problemi. Poiché un certificato Authenticode deve rimanere un asset protetto, il cliente non può semplicemente assegnare il certificato allo sviluppatore per firmare la distribuzione. Anche se il cliente può firmare autonomamente il manifesto della distribuzione usando strumenti disponibili liberamente con .NET Framework SDK, questo potrebbe richiedere conoscenze tecniche più di quanto il cliente sia disposto o in grado di fornire. In questi casi, lo sviluppatore crea in genere un'applicazione, un sito Web o un altro meccanismo tramite il quale il cliente può inviare la versione dell'applicazione per la firma.

Impatto dell'accesso dei clienti sulla sicurezza delle applicazioni ClickOnce

Anche se lo sviluppatore e il cliente accettano che il cliente deve firmare il manifesto dell'applicazione, questo genera altri problemi che racchiudono l'identità dell'applicazione, in particolare quando si applica alla distribuzione di applicazioni attendibili. Per altre informazioni su questa funzionalità, vedere Panoramica della distribuzione di applicazioni attendibili. Si supponga che Adventure Works voglia configurare i computer client in modo che qualsiasi applicazione fornita da Microsoft Corporation venga eseguita con attendibilità totale. Se Adventure Works firma il manifesto della distribuzione, ClickOnce userà la firma di sicurezza di Adventure Work per determinare il livello di attendibilità dell'applicazione.

Creare distribuzioni dei clienti usando il manifesto dell'applicazione per l'attendibilità

ClickOnce in .NET Framework 3.5 contiene una nuova funzionalità che offre agli sviluppatori e ai clienti una nuova soluzione per lo scenario in cui i manifesti devono essere firmati. Il manifesto dell'applicazione ClickOnce supporta un nuovo elemento denominato <useManifestForTrust> che consente a uno sviluppatore di indicare che la firma digitale del manifesto dell'applicazione è ciò che deve essere usato per prendere decisioni di attendibilità. Lo sviluppatore usa strumenti di creazione pacchetti ClickOnce, ad esempio Mage.exe, MageUI.exe e Visual Studio, per includere questo elemento nel manifesto dell'applicazione, nonché per incorporare sia il nome dell'editore che il nome dell'applicazione nel manifesto.

Quando si usa <useManifestForTrust>, il manifesto della distribuzione non deve essere firmato con un certificato Authenticode emesso da un'autorità di certificazione. Al contrario, può essere firmato con ciò che è noto come certificato autofirmato. Un certificato autofirmato viene generato dal cliente o dallo sviluppatore usando gli strumenti standard di .NET Framework SDK e quindi applicato al manifesto della distribuzione usando gli strumenti di distribuzione ClickOnce standard. Per altre informazioni, vedere MakeCert.

L'uso di un certificato autofirmato per il manifesto della distribuzione presenta diversi vantaggi. Eliminando la necessità che il cliente ottenga o crei il proprio certificato Authenticode, <useManifestForTrust> semplifica la distribuzione per il cliente, consentendo allo sviluppatore di mantenere la propria identità di personalizzazione nell'applicazione. Il risultato è un set di distribuzioni firmate che sono più sicure e hanno identità univoche dell'applicazione. In questo modo si elimina il potenziale conflitto che può verificarsi dalla distribuzione della stessa applicazione a più clienti.

Per informazioni dettagliate su come creare una distribuzione ClickOnce con <useManifestForTrust> abilitato, vedere Procedura dettagliata: Distribuire manualmente un'applicazione ClickOnce che non richiede la firma e che mantiene le informazioni di personalizzazione.

Funzionamento del manifesto dell'applicazione per l'attendibilità in fase di esecuzione

Per comprendere meglio il funzionamento del manifesto dell'applicazione per l'attendibilità in fase di esecuzione, prendere in considerazione l'esempio seguente. Un'applicazione ClickOnce destinata a .NET Framework 3.5 viene creata da Microsoft. Il manifesto dell'applicazione usa l'elemento <useManifestForTrust> ed è firmato da Microsoft. Adventure Works firma il manifesto della distribuzione usando un certificato autofirmato. I client Adventure Works sono configurati per considerare attendibile qualsiasi applicazione firmata da Microsoft.

Quando un utente fa clic su un collegamento al manifesto della distribuzione, ClickOnce installa l'applicazione nel computer dell'utente. Le informazioni sul certificato e sulla distribuzione identificano l'applicazione in modo univoco per ClickOnce nel computer client. Se l'utente tenta di installare nuovamente la stessa applicazione da un percorso diverso, ClickOnce può usare questa identità per determinare che l'applicazione esiste già nel client.

ClickOnce esamina quindi il certificato Authenticode usato per firmare il manifesto dell'applicazione, che determina il livello di attendibilità che ClickOnce concederà. Poiché Adventure Works ha configurato i client per considerare attendibile qualsiasi applicazione firmata da Microsoft, a questa applicazione ClickOnce viene concessa l'attendibilità totale. Per altre informazioni, vedere Cenni preliminari sulla distribuzione di applicazioni attendibili.

Creare distribuzioni dei clienti per le versioni precedenti

Cosa accade se uno sviluppatore distribuisce applicazioni ClickOnce ai clienti che usano versioni precedenti di .NET Framework? Le sezioni seguenti riepilogano diverse soluzioni consigliate, insieme ai vantaggi e agli svantaggi di ognuno di essi.

Firmare le distribuzioni per conto del cliente

Una possibile strategia di distribuzione è che lo sviluppatore crei un meccanismo per firmare le distribuzioni per conto dei clienti, usando la propria chiave privata del cliente. Ciò impedisce allo sviluppatore di dover gestire chiavi private o più pacchetti di distribuzione. Lo sviluppatore fornisce solo la stessa distribuzione a ogni cliente. Spetta al cliente personalizzarlo per il proprio ambiente usando il servizio di firma.

Uno svantaggio di questo metodo è il tempo e le spese necessarie per implementarlo. Anche se tale servizio può essere compilato usando gli strumenti forniti in .NET Framework SDK, aggiungerà più tempo di sviluppo al ciclo di vita del prodotto.

Come indicato in precedenza in questo argomento, un altro svantaggio è che la versione di ogni cliente dell'applicazione avrà la stessa identità dell'applicazione, che potrebbe causare conflitti. Se si tratta di un problema, lo sviluppatore può modificare il campo Nome usato durante la generazione del manifesto della distribuzione per assegnare a ogni applicazione un nome univoco. Verrà creata un'identità separata per ogni versione dell'applicazione e verranno eliminati eventuali conflitti di identità. Questo campo corrisponde all'argomento -Name per Mage.exe e al campo Nome della scheda Nome in MageUI.exe.

Si supponga, ad esempio, che lo sviluppatore abbia creato un'applicazione denominata Application1. Anziché creare una singola distribuzione con il campo Nome impostato su Application1, lo sviluppatore può creare diverse distribuzioni con una variante specifica del cliente su questo nome, ad esempio Application1-CustomerA, Application1-CustomerB e così via.

Distribuire usando un pacchetto di installazione

Una seconda possibile strategia di distribuzione consiste nel generare un progetto di installazione Microsoft per eseguire la distribuzione iniziale dell'applicazione ClickOnce. Questo può essere fornito in uno dei diversi formati: come distribuzione MSI, come file eseguibile di installazione (.EXE) o come file cab (cab) insieme a uno script batch.

Usando questa tecnica, lo sviluppatore fornirà al cliente una distribuzione che include i file dell'applicazione, il manifesto dell'applicazione e un manifesto di distribuzione che funge da modello. Il cliente eseguirà il programma di installazione, che richiederebbe un URL di distribuzione (il percorso del server o della condivisione file da cui gli utenti installeranno l'applicazione ClickOnce), nonché un certificato digitale. L'applicazione di installazione può anche scegliere di richiedere altre opzioni di configurazione ClickOnce, ad esempio l'intervallo di controllo degli aggiornamenti. Dopo aver raccolto queste informazioni, il programma di installazione genererà il manifesto della distribuzione reale, firmarlo e pubblicare l'applicazione ClickOnce nel percorso del server designato.

In questa situazione il cliente può firmare il manifesto della distribuzione in tre modi:

  1. Il cliente può usare un certificato valido emesso da un'autorità di certificazione (CA).

  2. Come variante di questo approccio, il cliente può scegliere di firmare il manifesto della distribuzione con un certificato autofirmato. Lo svantaggio è che l'applicazione visualizzerà le parole "Server di pubblicazione sconosciuto" quando all'utente viene chiesto se installarlo. Tuttavia, il vantaggio è che impedisce ai clienti più piccoli di dover dedicare tempo e denaro necessario per un certificato emesso da un'autorità di certificazione.

  3. Infine, lo sviluppatore può includere il proprio certificato autofirmato nel pacchetto di installazione. In questo modo vengono presentati i potenziali problemi relativi all'identità dell'applicazione descritti in precedenza in questo argomento.

    Lo svantaggio del metodo del progetto di distribuzione di installazione è il tempo e le spese necessarie per compilare un'applicazione di distribuzione personalizzata.

Chiedere al cliente di generare il manifesto della distribuzione

Una terza possibile strategia di distribuzione consiste nell'distribuire solo i file dell'applicazione e il manifesto dell'applicazione al cliente. In questo scenario, il cliente è responsabile dell'uso di .NET Framework SDK per generare e firmare il manifesto della distribuzione.

Lo svantaggio di questo metodo è che richiede al cliente di installare gli strumenti .NET Framework SDK e di avere un amministratore di sistema o uno sviluppatore esperto nell'uso. Alcuni clienti possono richiedere una soluzione che richiede poco o nessun impegno tecnico da parte loro.

Contenuto correlato