• Raffaele Fanizzi su LinkedIn

Archives

Archives / 2012 / April
  • AutomationFactory in Silverlight 5

    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.

    altro

  • Microsoft .NET Framework 4.0.3

    In attesa che esca il nuovo .NET Framework 4.5 in versione definitiva, Microsoft ha rilasciato un aggiornamento del .NET Framework 4 alla versione 4.0.3. Analogamente ai precedenti aggiornamenti (4.0.1 e 4.0.2), questo introduce alcune novità ed una serie di migliorie, oltre chiaramente a risolve bug più o meno gravi. Tra le novità principali segnalo la possibilità di utilizzare l'engine di Workflow Foundation 4 anche in ambienti medium trust, il che amplia significativamente gli ambiti d'uso di questa libreria. Workflow Foundation 4 è una libreria probabilmente poco conosciuta, ma in termini di workflow engine, rappresenta un significativo passo in avanti rispetto all'ormai obsoleta versione introdotta con il framework 3.0: nel caso in cui sia a voi sconosciuta, consiglio caldamente di dargli un'opportunità.

    Altri miglioramenti riguardano la gestione di ADO.NET con configurazioni di SQL Server particolarmente care a chi utilizza SQL Azure, per le quali sono stati risolti una serie di antipatici bug.

    Maggiori informazioni sull'aggiornamento potete trovarle qui. Potete invece scaricare l'aggiornamento che include anche un'update di Visual Studio 2010 SP1 qui.

    altro

  • Visual Studio 2010 SP1 loading toolbox...

    Se avete installato i Silverlight 5 Tools per Visual Studio 2010 SP1 è molto probabile che al primo accesso alla toolbox, Visual Studio si blocchi per 50-60 secondi con il seguente messaggio nella status bar:

    Loading toolbox content from package Microsoft.VisualStudio.IDE.Toolbox.ControlInstaller.ToolboxInstallerPackage '{2C98B35-07DA-45F1-96A3-BE55D91C8D7A}'

    Il problema sembra essere causato dall'installazione dei Silverlight 5 Tools e, in particolare, dal toolkit dei WCF RIA Services e di Silverlight 5 stesso. Per risolvere questo problema potete trovare online una serie di workaround, ma quello che a mio parere è il più valido è il seguente

    1. Disinstallate WCF RIA Services V1.0 SP2
    2. Disinstallate WCF RIA Services Toolkit
    3. Disinstallate Silverlight 5 Toolkit
    4. Avviate Visual Studio 2010 -> Pulsante Destro sulla Toolbox -> Reset Toolbox
    5. Chiudete Visual Studio 2010
    6. Andate in %USERPROFILE%\Local Settings\Application Data\Microsoft\VisualStudio\10.0 ed eliminate tutti i file .TBD

    Dopo aver eseguito questa procedura, il primo avvio di Visual Studio sicuramente sarà più lento del solito, in particolare per caricare la toolbox, ma tutti i successivi avvii non vi riproporranno più l'antipatico problema. Se avete necessità di utilizzare i vari toolkit disinstallati, vi consiglio caldamente di abbracciare l'approccio NuGet e di smetterla di installarvi sull'ambiente di sviluppo e in GAC tutte le librerie che usate.

    altro

  • Banding su Windows Phone

    Anche se non sono un grafico, aver lavorato per diversi anni come redattore per Hardware Upgrade e, in particolare, fare recensioni di schede video, mi ha reso particolarmente sensibile ad alcuni artefatti grafici tipici delle schede di un tempo. Dovete sapere, infatti, che fino a quando il monopolio delle schede video acceleratrici 3D era in mano a 3dfx Interactive (e qui una lacrima riga il mio viso), buona parte delle elaborazioni grafiche veniva eseguita a 16 bit. Per chi non lo sapesse, questo significa che il numero massimo di colori visualizzabili sullo schermo era pari a 65536, tanti potreste pensare voi, ma in realtà pochissimi in molte circostanze.

    Il problema si pone in particolare quando è necessario sfruttare un'ampio spettro di sfumature di uno stesso colore. In questo specifico ambito i 16 bit mostrano tutti i loro limiti e gli oltre 16 milioni di colori che oggi ammiriamo grazie ai 32 bit diventano indispensabili. L'effetto più evidente che si nota quando il numero di colori diventa insufficiente è il cosiddetto banding.

    L'immagine sopra esposta ben evidenzia la problematica. A questo punto alcuni si staranno chiedendo: cosa c'entra il banding con i Windows Phone? Purtroppo molto perché Microsoft ha deciso di impostare 16 bit come profondità di colore predefinita delle applicazioni Windows Phone sviluppate in Silverlight. La motivazione è presto detta: 16 bit richiedono molta meno potenza di calcolo, molta meno memoria video e di sistema, oltre a rappresentare il minimo comune denominatore dei colori supportati dagli schermi sui Windows Phone.

    Ecco quindi che, esattamente come alla fine degli anni 90 abbiamo dovuto lottare per conquistare i 32 bit nella grafica tridimensionale dei videogiochi, oggi ci tocca fare altrettanto con i Windows Phone. Fortunatamente, contrariamente all'epoca, la scelta di Microsoft non è dettata da limiti hardware, ma da una scelta votata all'ottimizzazione delle risorse di un telefono, il che significa che per abilitare i 32 bit nelle vostre app per Windows Phone non dovrete fare altro che aprire il file WMAppManifest.xml ed impostare l'attributo BitsPerPixel a 32.

    Controindicazioni? In teoria vi macchierete del crimine di non risparmiare le risorse hardware del Windows Phone sul quale gira la vostra app, ma onestamente a mio parere è più alto il rischio di fare brutta figura con il banding, che non quello di perdere qualche decimale di batteria in più. Detto questo, valutate su uno smartphone (e non sull'emulatore) l'entità della problematica e, eventualmente, prendete le dovute contromisure.

     altro