E' da diverse versioni che Silverlight supporta la possibilità di richiamare Automation Server mediante l'API AutomationFactory. In Silverlight 5, tuttavia, la possibilità di avere applicazioni in browser di tipo Trusted, consente un più ampio ventaglio di utilizzi di questa tecnologia. Fino a Silverlight 4, infatti, qualsiasi operazione che richiedesse un aumento dei privilegi poteva essere eseguita solo ed esclusivamente se l'applicazione era di tipo out of browser il che, soprattutto dal punto di vista commerciale/marketing, potrebbe rappresentare un problema. Diciamolo chiaramente: gli addetti al settore sanno benissimo che Silverlight, così come Flash, non possono essere definite tecnologie puramente web. Se si vuole fare un sistema web puro, si deve usare HTML, Javascript e qualche linguaggio server side. Tuttavia, benché con HTML 5, CSS 3 e tutto ciò che gira attorno, tale tendenza sembra essere quella che inevitabilmente da qui a qualche anno si diffonderà, utilizzare ambienti di sviluppo come Silverlight rappresenta a mio parere, almeno fino ad ora, un notevole vantaggio nei seguenti aspetti:
- linguaggio di programmazione - con tutto il rispetto per javascript, usare C# garantisce una netta superiorità dal punto di vista della produttività, degli strumenti di sviluppo/debug, degli strumenti per test automatici e dell'implementazione di design pattern
- accesso a risorse locali - non tutte le applicazioni possono astrarsi dalla macchina su cui lavorano, alcune necessitano si accedere a dispositivi hardware e molto spesso non possibile accedervi usando javascript
In Silverlight 5 è possibile, quindi, lavorare con applicazioni Trusted in browser e questa peculiarità ci permette di eseguire operazioni come, per esempio, il deploy in locale di un pacchetto Windows Installer che, una volta installato, potrebbe esporci mediante una libreria COM visible, funzionalità normalmente non accessibili. Di seguito un esempio di codice che recupera il pacchetto di installazione da risorse dello XAP stesso (ma potreste scaricarlo da un web server o in qualunque altro modo), lo scrive sul disco (la funzione WriteStreamIntoStream non fa altro che travasare gli stream) e poi lo esegue utilizzando l'oggetto COM WScript.Shell e, in particolare, il metodo Run:
StreamResourceInfo srMSI = Application.GetResourceStream(new Uri("Test;component/Packages/Test.msi", UriKind.Relative));
var filePath = System.IO.Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "Test.msi");
using (var setupStream = File.Open(filePath, FileMode.OpenOrCreate))
{
WriteStreamIntoStream(srMSI.Stream, setupStream);
}
var shell = AutomationFactory.CreateObject(“WScript.Shell”);
var result = shell.Run(filePath, 1, true);
return result == 0;
Chiaramente se il pacchetto di installazione richiede privilegi di amministratore, in ambienti come Windows Vista o Windows 7 con UAC attivo, verrà richiesta l'elevazione dei privilegi e, a tal proposito, vi consiglio caldamente di firmare con un certificato digitale il pacchetto MSI in modo che il cliente abbia ben chiara l'origine dell'operazione.
