Carissimi lettori ben trovati. Oggi tratteremo ClickOnce, argomento discusso in un post precedente, poiché voglio condividere con voi un’interessante quesito che mia ha sottoposto uno dei clienti con cui ho avuto il piace di lavorare. Prima di andare al cuore della faccenda, consentitemi di compiere una breve premessa:

Com’è noto, ClickOnce consente non solo di pubblicare la nostra applicazione su un server web in internet o intranet, una share interna all’azienda, ma permette anche di specificare tutti i prequisiti software necessari per il corretto funzionamento del nostro applicativo. Per ognuno dei prerequisiti, lo sviluppatore ha la possibilità di indicare l’URL dove scaricare automaticamente i file durante l’installazione. Tale URL può essere:

  • Il link pubblico per il download fornito dal produttore
  • Una share interna all’azienda, qualora l’utilizzatore finale del software non abbia la possibilità di accedere ad internet.

Lo scenario è il seguente:

Immaginiamo di aver sviluppato un’applicazione .NET e di aver pensato di distribuire la medesima ed i suoi prerequisiti in un Server Web di sviluppo tramite la tecnologia ClickOnce.

Compiti i dovuti test, si ha la necessità di migrare l’applicazione pubblicata in sviluppo in un ambiente di produzione. Per compiere tale migrazione, non occorre ripubblicare il software nella nuova machina di produzione, poiché è possibile introdurre errori. Si preferisce migrare il lavoro compiuto in sviluppo nel server di produzione.

Ovviamente non si può pensare di migrare brutalmente l’output di un progetto ClickOnce dato che eventuali aggiornamenti del software e tutti i prerequisiti del medesimo, sarebbero ricercati nel primo web server utilizzato per la pubblicazione, ovvero il server di sviluppo.

Esiste una procedura che ci consente di modificare il path in cui l’applicazione ClickOnce ricerca gli aggiornamenti e i prerequisiti. V’invito a tal fine a visionare i seguenti link:

Ovviamente aggiornare il manifest e il file exe della nostra applicazione implicherà la corruzione della firma digitale che automaticamente il Visual Studio applica durante la pubblicazione. E’ necessario dunque rifirmare digitalmente gli assembly.

Riporto nel seguito i passi da compiere per perseguire tale obiettivo indicando con: 157.58.177.238 l’ip della nuova macchina di deploy.

setup.exe -componentsurl=http://157.58.177.238
setup.exe -url=http://157.58.177.238
mage.exe -update TEST.application -ProviderUrl http://157.58.177.238/test.application
mage.exe -update ".\Application Files\TEST_1_0_0_1\TEST.application" -ProviderUrl http://157.58.177.238/test.application
mage -sign TEST.application -certfile c:\Users\carmelop\Desktop\TEST\TEST\TEST_TemporaryKey.pfx
mage -sign ".\Application Files\TEST_1_0_0_1\TEST.application" -certfile c:\Users\carmelop\Desktop\TEST\TEST\TEST_TemporaryKey.pfx
mage -sign ".\Application Files\TEST_1_0_0_1\TEST.exe.manifest" -certfile c:\Users\carmelop\Desktop\TEST\TEST\TEST_TemporaryKey

Grazie,

Carmelo Pulvirenti
Support Engineer
Windows Mobile & Embedded Developer Support
.NET & Visual Studio Technology