Ricciolo.NET - Il blog di Cristian "Ricciolo" Civera

Styles Explorer: decompilatore BAML

Vi ricordate quando vi parlai di come viene compilato lo XAML e quale struttura ha? Beh è un po' che avevo più o meno pronta quella classe e mancava qualcosa per usarla a dovere. Portando avanti a singhiozzo il progetto, finalmente posso farvi vedere qualcosa di Styles Explorer.

E' uno strumento che ti permette di aprire qualsiasi DLL, enumerare le risorse BAML che contiene e decompilare (se ce la fa) fornendo l'XML. E' principalmente improntato sui ResourceDictionary, perciò è in grado di fornire un'anteprima di un oggetto o di uno style.

Siccome i tempi cambiano, invece degli screenshot vi metto un bel filmato

Video: Styles Explorer

Ovviamente il progetto è ancora in corso e va migliorato, ma fino adesso mi son divertito a fare alcune cose carine, come usare più AppDomain per isolare il caricamento degli assembly, o fare una nuova message pump solo per la preview così da evitare problemi con il resto dell'applicazione.

Ah dimenticavo, potete installarlo da qua.

Tags: .NET Framework, .NET Framework 3.0, .NET Framework 3.5, Windows Presentation Foundation, XAML

Le evoluzioni del Web che non capisco

Chi mi conosce sa che non sono un gran simpatizzante di AJAX e riconoscendo che in effetti serve qualcosa di più del buon vecchio HTML, trovo Silverlight decisamente una soluzione migliore. Ma non è di questa moda che voglio parlare, ma bensì di REST e POX.

Con il primo termine si intende il voler sfruttare a pieno le capacità di HTTP, mediante i suoi method, per ampliare l'applicazione web e fornire servizi aggiuntivi usufruibili al di fuori dell'HTML e della semplice navigazione. In pratica, siccome esistono i metodi GET, POST, PUT e DELETE si è pensato di sfruttarli per eseguire le classiche operazioni CRUD, magari aggiugendo dei parametri nell'URI o nel contenuto della richiesta. Tutto questo ovviamente esiste da sempre, ma veniva marginalmente sfruttato e solo ora, e ben venga, siti come Amazon, Google, Live, ecc permettono di interrogare e di usufruire dei loro servizi mediante REST.

POX invece vuol dire Plain Old XML e in pratica vuol dire usare XML semplice senza fronzoli, da utilizzare nelle richieste o risposte REST.

Cosa non mi piace di tutto questo? Il fatto che si sta reinventando la ruota. Per esempio, chi espone operazioni REST si trova a dover fornire della documentazione per spiegare come chiamare le varie operazioni, come dev'essere passato l'XML e spesso in maniera superficiale, limitandosi ad un esempio di XML o ad un esempio di parametro in query string. Beh a tutto questo qualcuno ci aveva già pensato e vedendo che non era sufficiente aveva pensato ai WebService, a SOAP, ai consorzi per renderli i più interoperabili possibili. Per XML esistono gli schema XSD che sono molto più completi, mentre per conoscere quali operazioni espone un servizio c'è WSDL e WS-Metadata Exchange. Senza contare che con framework come WCF basta semplicemente fare un "Add Service reference" e ci si può persino permettere di ignorare questi linguaggi e di esporre della documentazione aggiuntiva.

E' vero che non tutti fanno applicazioni enterprise ed usare WCF/WebService può sembrare un carro armato per uccidere le mosche, ma sono del parere che alcune problematiche sono presenti anche in semplici siti web. Tra questi il già citato, come chiamare un'operazione, ma anche quali errori mi può eventualmente dare e come li gestisco. Poi man mano ci sono altri aspetti, come l'autenticazione, spesso affidata ad un token rilasciato da chi espone il servizio da inserire nella querystring, mentre in WS-* tutto questo è già definito. Sono inoltre definiti come rendere le operazioni sicure, criptate, transazionali, come gestire le policy ed inviare file di grosse dimensioni. Ovviamente se tutto questo non serve basta non abilitarlo e l'XML resta contenuto, senza offenderlo chiamandolo POX :-).

E' per questo che storto un po' il naso e che il diffondersi di questi termini sia più dovuto o ad ignoranza su certe tecnologie (almeno io so il loro nome :-) ) oppure ad una pigrizia nell'affrontarle ed impararle. Detto questo, sicuramente ci sono ambiti in cui una normale richiesta GET basta e avanza; l'importante che vengano valutate anche le altre strade e che non venga coniato qualche nuovo termine o nuova era del web.

Tags: Silverlight, XAML

Un'occhiata a Silverlight 2.0

Come probabilmente saprete è stata rilasciata la beta Silverlight 2.0.

Ovviamente da fan di WPF non ho resistito dal provarla subito. Sinceramente, delle scorse preview ero rimasto un po' deluso, poiché conoscendo WPF mi rendevo conto di quante cose mancassero diventando così frustrante giocarci. Beh invece con Silverlight 2.0 mi ritengo soddisfatto e entusiasta come un bambino che scarta i regali a Natale :-D

Per prima cosa il setup installa runtime, template per Visual Studio 2008 e SDK. Una parte del SDK è rivolta al server e l'altra al client.

Lato server una nuova System.Web.Silverlight.dll contiene i controlli Silverlight e MediaPlayer. Il primo semplicemente crea il markup per istanziare il plugin, include il codice JavaScript e non è più necessario includere script esterni ecc. MediaPlayer è un controllo più evoluto che permette con due click di inserire un player di video con tanto di marcatori e capitoli basandosi su Silverlight. Il tutto completamente skinnabile, con una decina di skin già presenti nel SDK. Molto maschio.

Lato client l'architettura è rimasta invariata e il runtime, di soli 4,3MB, è installato in %ProgramFiles%\Microsoft Silverlight\2.0.30226.2. Rispetto alla alpha abbiamo in più System.ServiceModel (WCF quindi) con BasicHttpBinding, supporto a REST e JSON. L'assembly System.Windows è stato ampliato con altre classi base con niente popo di meno che: StackPanel, Grid, Border, TextBox, ItemsControl (i principali).

Incredibile, c'è la classe Binding con IValueConverter, BindingMode, Source, ma nessun altra tipologia di binding. In molti aspetti Silverlight assomiglia da fuori a WPF, ma dentro l'implementazione è decisamente diversa, tendente al risparmio (non poteva essere diversamente). I controlli sono basati su DependencyProperty (anche Attached Property), ma non è presente nessun meccanismo di triggering o metadati aggiuntivi, mentre gli eventi invece sono quelli normali del CLR; quindi niente Attached Event, niente bubbling o tunneling ed eventi di preview.

I controlli si basano su Template che vengono caricati tramite Style avente come TargetType il tipo del controllo da personalizzare. Gli Style non hanno trigger, quindi nel metodo ApplyTemplate ogni controllo cerca elementi nel template dal nome prefissato (es: RootElement), ne intercettono gli eventi e interagiscono in base a quest'ultimi. Questa tecnica esiste in modo identico anche in WPF, ma si usa raramente preferendo l'uso di trigger in modo da legare il meno possibile il codice al markup. Continuando con il paragone con WPF, niente Command, CollectionView e WeakEvent.

Tutto sommato quindi, le cose che si potevano implementare sono state copiate da WPF e questo non può farmi che piacere :-), ma ovviamente per non esagerare nella dimensione degli assembly è stato sacrificato qualcosa.

Da Visual Studio o Blend 2.5 possiamo creare un progetto Silverlight 2.0 e rispetto a prima, si sviluppa una specie di class library avente già pronti i file App.xaml, che è l'entry point, e un file Page.xaml: lo UserControl principale. Ovviamente hanno il relativo code-behind dove possiamo scrivere in C# 3.0 o VB 9.
Il risultato della compilazione è un file .xap, l'unico file da distribuire, che è un file .zip contenente un file di metadati, i file che abbiamo incluso nel progetto con target Content e la nostra dll compilata. Quest'ultima contiene nelle risorse i file XAML, ma non compilati in BAML (diversamente da WPF). Probabilmente questa scelta è dovuta al fatto che l'ottimizzazione di caricamento del markup è stata ritenuta sacrificabile, mentre la compressione è già ottenuta grazie allo ZIP.

Per ultimo una cosa inaspettata: nel progetto di Visual Studio troveremo referenziati altre dll che verranno poi incluse nel file xap. Queste normalmetne sono: System.Windows.Controls e System.Windows.Controls.Extended. Queste dll, più altre, si trovano normalmente nella cartella del SDK (C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client) e non sono incluse nel setup di Silverlight. Peccato che quest'altre 18 dll contengano: Ruby, Python, Managed JScript, le classi Syndacation RSS/Atom di WCF, Linq To Xml, controlli come Thumb (per il drag&drop), Button, CheckBox, ListBox, RadioButton, Slider, ScrollBar, ScrollViewer, ToolTip, ToggleButton, DataGrid, Calendar, DateTimePicker, GridSplitter, WatermarkedTextBox.

Prima di tutto stupisce che ci siano controlli che WPF non ha e sia Silverlight il primo ad implementarli, ma soprattutto ecco spiegato perché il runtime è piccolo. Infatti tutte le altre dll le mandiamo noi all'utente inglobandole nel file xap. Così l'installazione del plugin è piccola, mentre l'utente navigando su più siti si ritrova a scaricare solo le dll che effettivamente l'applicazione usa, con il rischio ovviamente di scaricare più volte la stessa dll in pacchetti diversi. Furbini vero? :-D

Non l'ho ancora guardato benissimo, ma Silverlight così mi piace decisamente e non ha rivali sul web. Se volete vederlo all'opera potete venire al Real Code Launch che terremo a Roma. Dovete assolutamente venire; chi c'è, c'è, chi non c'è... eh non c'è.

Tags: .NET Framework 3.0, Microsoft Expression, Silverlight, Silverlight - animazioni, Silverlight 2.0, Windows Presentation Foundation, XAML

Ho aperto un nuovo blog

Probabilmente vi domanderete perché abbia aperto un altro blog visto che a mala pena scrivo su questo. Semplice, per scrivere le mie esperienze in inglese. Quindi niente paura, le tematiche sono le stesse e se sfortunatamente leggete già questo blog resterete sempre aggiornati: tutto quello che scriverò in inglese verrà scritto in italiano e forse anche viceversa.

Il blog si trova qua, aggregato sul sito di windowsclient.net.

DirectShow e WPF: soluzione finale

o quasi... :-) Nel precedente post ho parlato delle problematiche e possibili soluzioni per mostrare sorgenti video personalizzate in WPF. Ho accennato ad una possibile terza soluzione e sebbene non perfetta la reputo la migliore.

Partiamo dal risultato. Nella figura sottostante potete ammirare un esemplare maschio homo sapiens sapiens:

L'esempio è ottenuto usando come VisualBrush di un cubo 3D, un mio oggetto:

<ricciolo:WebcamElement Source="webcam://WebcamElement/Video%20Camera" />

Questa classe eredita da una classe base AdvancedMediaElement (eredita dalla standard MediaElement) che offre le funzionalità base per supportare qualsiasi grafo DirectShow. Nello specifico, per l'intera applicazione uso una libreria Microsoft di nome detours che permette di sovrascrivere le funzioni Win32 ed eventualmente chiamare la funzione originale. Per il mio scopo intercetto la chiamata a CoCreateInstance, usata per instanziare gli oggetti COM, e quando il MediaElement carica l'URL coercizzo il valore ad un file fisico vuoto creato al volo nella temp dir. Windows Media Player carica DirectShow, crea il grafo e crea l'AsyncReader standard. Io che sono infame, mediante detours, restituisco un mio oggetto che implementa IAsyncReader e non presenta nessun pin. L'intelligent connect passa il nome del file IFileSourceFilter::Load al mio filtro e poi si ferma, mentre quest'ultimo tramite callback notifica all'AdvancedMediaElement di caricare il grafo. Mediante l'associazione URI/istanza chiamo un metodo virtuale OnGraphLoad(IGraphBuilder graph) nella quale le varie implementazioni (nel mio caso WebcamElement) possono popolare il grafo con i fitri che vogliono lavorando via interop con l'ausilio di librerie tipo DirectShowLib.

La soluzione è in parte in C++ CLI, in parte in C#, è aperta ad altre implementazioni e non richiede nessuna registrazione di DLL (le detours sono inglobate nel mio assembly) o di protocol handler. L'unica nota dolente è quel finto file vuoto temporaneo che devo creare per costringere WMP ad usare DirectShow; se qualcune conosce quindi un'alternativa sarò ben contento di ascoltarla.

Presto sorgenti e applicazione di test nel lab

Sorgenti custom per MediaElement di WPF

L'elemento MediaElement è un gran bell'oggettino :-) Permette di mostrare e ascoltare video e audio, il tutto perfettamente integrato con WPF permettendoci di ridimensionarlo come ci pare, usarlo come brush, trasformarlo, applicare trasparenze, ecc...

L'unico problema è che al di là di file su disco o uri http, non si può andare. Per esempio può essere utile usare come sorgente la webcam, un tuner TV o una fonte analogica esterna. Per ottenere ciò ci sono vari modi:

Usare l'elemento HwndSource così da avere una finestra Win32. Tramite la proprietà Handle abbiamo il suo puntatore e possiamo quindi usare DirectShow effettuando il rendering puntando la finestra con l'interfaccia IVideoWindow. Se vi interessa è disponibile questo progetto pieno di classi interop per usare DirectShow in .NET.
Questo approccio ha dei limiti dovuti al fatto che HwndSource è sì un elemento WPF, ma poiché contiene al suo interno una nuova finestra Win32 non permette di effettuare trasformazioni, trasparenze, ecc.
Costruire un protocol handler per un proprio schema (esempio webcam://qualcosa) che faccia uso di un source filter personalizzato per DirectShow. Questo è possibile perché MediaElement utilizza al suo interno Windows Media Player che a sua volta si basa su Windows Media Foundation che a sua volta usa (se necessario) DirectShow.

Ho provato entrambi le modalità e ovviamente la seconda è la migliore (esiste una terza che sto ancora sperimentando). Nella seconda ho scritto in C++ un source filter che implementa IFileSourceFilter, così da essere da essere chiamato per caricare il mio schema custom. Non entro troppo nei dettagli, ma è compito di WMP caricare il mio filtro e, una volta aggiunto al grafo DirectShow, renderizzare il pin video in uscita sfruttando l'Intelligent Connect. Questo sistema in pratica si mette a guardare i pin del filtro sorgente e prova le possibili combinazioni tra filtri di decodifica e di rendering fino a quando non riesce a mostrare il video e/o ad emettere il suono. In WPF il filtro sorgente quindi dipende dal protocol handler, mentre il rendering video viene effettuato mediante Enhanced Video Renderer: un filtro nuovo e più evoluto che permette l'integrazione in WPF.

Nella mia prova ho usato il tipico filtro Ball presente nel SDK, costituito da un pin che restituisce uno stream video che mostra una palla rimbalzare. Una volta pronto il filtro, va poi registrato sia come dll, sia mappando lo schema custom al filtro. Possiamo poi usarlo sia in WMP che in GraphEdit (un tool per testare i filtri). Ecco uno screenshot:

A questo punto possiamo usare il filtro anche in WPF:

<MediaElement Source="ball://test" />

E questo è il risultato che si ottiene applicandoci il tipico effetto riflesso, per far vedere che possiamo trattare il video come vogliamo:

Quindi in teoria possiamo fare un pin che prenda lo stream da un grafo interno oppure possiamo fare un filtro senza pin, ma che sul metodo Load inserisce nel grafo un nuovo filtro sorgente (webcam, tuner ecc). Ci pensa poi l'intelligent connect ad ignorare il nostro filtro custom, proseguendo sull'altro da noi creato. Questa variante è stilisticamente meno carina, ma più semplice.

Tags: .NET Framework, .NET Framework 3.0, .NET Framework 3.5, Windows Presentation Foundation, XAML

Anonymous type di C# 3.0

Giocando con LINQ avrete senz'altro usato gli anonymous type: quei tipi creati al volo per contenere varie informazioni. Poniamo questo semplice esempio:

var v = new {Language = "IT", Age=30};

Prima di tutto, v è visibile solo all'interno dello stack in cui l'abbiamo dichiarato. Quindi all'interno di una funzione o metodo, ma mai a livello di classe. Possiamo anche ritornarlo come valore da una funzione, ma potremmo limitarci a ritornare un tipo object generico e non potremmo fare riferimento al nome del tipo, facendo cast o quant'altro (se non via reflection, bleah bleah). Quindi ques'ultima opzione è fortemente sconsigliata.

Quando compiliamo, viene automaticamente generata una classe internal sealed dal nome f__AnonymousType[numero] sul namespace root. La classe eredita da Object definisce n proprietà e n campi per memorizzare i valori e dispone di un costruttore che accetta come parametri i valori da impostare sulle proprietà. Non c'è modo di cambiarne visibilità ai tipi o ai membri, ne di rendere in sola lettura le proprietà. Questa classe ha la particolarità di essere generica, nel senso che i tipi string e int delle proprietà Language e Age del nostro esempio, sono generici. Questo per evitare di creare copie della medesima classe. Quindi se utiliziamo nel medesimo assembly un anonymous type simile:

var v = new {Language = 1, Age=3d};

verrà utilizzata la medesima classe autogenerata, ma con generics argument diversi: int e double.

Tale classe inoltre sovrascrive ToString per mostrare facilmente il contenuto, Equals e GetHashCode così da rendere comparabile il tipo quando viene utilizzato, per esempio da LINQ To Objects:

[DebuggerHidden] public override string ToString() { StringBuilder builder = new StringBuilder(); builder.Append("{ Language = "); builder.Append(this.<Language>i__Field); builder.Append(", Age = "); builder.Append(this.<Age>i__Field); builder.Append(" }"); return builder.ToString(); } [DebuggerHidden] public override int GetHashCode() { int num = 0x5b485bf4; // Numero casuale num = (-1521134295 * num) + EqualityComparer<<Language>j__TPar>.Default.GetHashCode(this.<Language>i__Field); return ((-1521134295 * num) + EqualityComparer<<Age>j__TPar>.Default.GetHashCode(this.<Age>i__Field)); } [DebuggerHidden] public override bool Equals(object value) { var type = value as <>f__AnonymousType0<<Language>j__TPar, <Age>j__TPar>; return (((type != null) && EqualityComparer<<Language>j__TPar>.Default.Equals(this.<Language>i__Field, type.<Language>i__Field)) && EqualityComparer<<Age>j__TPar>.Default.Equals(this.<Age>i__Field, type.<Age>i__Field)); }

Sono interessanti l'uso di DebuggerHidden per evitare di far vedere dal debugger tali metodi e l'uso di EqualityComparer.Default per ottenere l'hashcode o comparare i tipi primitivi utilizzati. EqualityComparer.Default restituisce un IEqualityComparer<T> (fondamentale in LINQ) a seconda che il tipo implementi IEquatable<T>, sia nullabile o come ultima spiaggia, sovrascriva Equals e GetHashCode. Per comparare le stringhe (utile sempre in LINQ) abbiamo a disposizione la classe StringComparer che permette diversi modi di comparazione delle stringhe: CurrentCulture, CurrentCultureIgnoreCase, InvariantCulture, InvariantCultureIgnoreCase, Ordinal, OrdinalIgnoreCase.

Tags: .NET Framework, .NET Framework 3.5, LINQ

Habemus CardSpace!

E' un po' che io e Daniele ci stiamo lavorando (circa due mesi), ma finalmente abbiamo implementato CardSpace nella nostra community. Questo significa che da ora in poi potete fare login utilizzando le card self-issued. Una guida su come funziona l'ambaradam la trovate qua e se avete già a disposizione una card e non siente registratati, allora create un profilo qua, oppure associate la card ad un account pre esiste, dopo aver fatto il login, andando qua. In generale la vostra card personale è utilizzabile in tutti i portali dove compare questo logo standard:

Ovviamente la domanda è: perché supportare l'identity metasystem?

Risposta:

perché adeguarsi ad un sistema standard ed interoperabile ci permette di accogliere nuovi utenti molto più facilmente. Basta selezionare la card utilizzata già su altri portali e le informazioni sono già disponibili;
perché non serve più ricordarsi di password, utenti ed email;
perché un'unica interfaccia di selezione basata su comunicazioni sicure, è sicuramente meglio dei mille sistemi inventati da ogni programmatore del mondo, abbattendo inoltre così, fenomeni come phishing;
perché questo sistema di autenticazione è utilizzabile anche al di fuori dal web: applicazioni windows, webservice ecc.

Non temete, implementare identity metasystem nei vostri portali è facile e fattibile. L'unica difficoltà è il certificato per il canale SSL, ma dal .NET Framework 3.5 non è più obbligatorio se il nostro sito non è una banca :-) La difficoltà che abbiamo incontrato è stata nel cercare di implementare un STS (Security Token Server) per rilasciare delle nostre card marcate ASPItalia.com/WinFXItalia.com, da utilizzare nelle nostre community. Beh dunque, fare un STS non è affatto semplice e il materiale a disposizione non è completo. Parlando comunque con Vittorio Bertocci, che lavora in Microsoft e si sta dando parecchio da fare per diffondere l'adozione dell'identity metasystem, abbiamo maturato l'idea che fare da STS è troppo per noi. STS che rilascia managed card deve essere un ente, una banca, uno stato. Per la nostra community bastano le semplici self-issued card. Maggiori dettagli tecnici sull'argomento li trovate qua.

Tags: ASPItalia.com

WPF: attenzione ai template predefiniti

Certo, si può dormire lo stesso anche non sapendolo, ma sul nostro forum è stata posta un'interessante domanda relativa ai Content di WPF. Purtroppo la comodità di certi elementi presenti ci fa ignorare il dietro le quinte e a volte ci porta a risultati inaspettati. E' il caso delle classi ContentControl e HeaderedContentControl che dispongono delle proprietà Header e Content di tipo Object e ci consentono di fare questo:

<Button>Ciao!</Button>

Innanzitutto tramite l'interfaccia IAddChild la stringa "Ciao!" viene impostata sulla proprietà Content ed equivale quindi a scrivere:

<Button> <Button.Content>Ciao!</Button.Content> </Button>

I vari skin applicati a Button o controlli simili, utilizzano l'oggetto ContentPresenter per includere il contenuto nel layout. Quest'oggetto applica dei template predefiniti a seconda del tipo presente in Content:

Se è una stringa e RecognizesAccessKey è a true, utilizza un template che crea un AccessText e con Text valorizzato con il Content stesso; altrimenti utilizza un normale TextBlock con Text valorizzato con il Content stesso;
Se è un UIElement, inserisce l'elemento stesso direttamente come figlio;
Se è un XmlNode, utilizza un TextBlock con Binding XPath = "."
Per gli altri restanti tipi, utilizza un TextBlock cercando di convertire prima con un TypeConverter e poi con un ToString il tipo impostato come Content.

Detto questo, quali possono essere i risultati inattesi? Prendiamo questo esempio:

<Menu> <MenuItem Header="_One" /> <MenuItem Header="_Two" /> </MenuItem>

L'uso degli underscore è riconosciuto da AccessText (il ContentPresenter del MenuItem ha RecognizesAccessKey a true) e permette l'utilizzo dello shorcut effettuando la sottolineatura della lettera che lo segue. Se usiamo però il Binding XML, per esempio, gli underscore non vengono più rinosciuti:

<MenuItem Header="{Binding XPath=/item/@text}" />

Questo perché non viene più usato il template predefinito riservato alle stringhe. Per ovviare a questo problema, occorre creare in modo esplicito l'oggetto AccessText:

<MenuItem> <MenuItem.Header> <AccessText Text="{Binding XPath=/item/@text}" /> </MenuItem.Header> </MenuItem>

Curiosità sui Thread

In questi giorni grazie ad un esigenza di Rob e Paolo, ho voluto approfondire un aspetto di cui ero già a conoscienza, ma del quale non avevo mai fatto test.
Come sapete, un campo dichiarato in una classe può teoricamente subire contemporaneamente l'accesso da più thread e spesso per rendere la classe thread-safe si ricorrono a tecniche di sincronizzazione per evitare che più thread cambino contemporanemante il campo. Non è detto infatti che una singola istruzione di assegnazione sia una singola istruzione di CPU e questo può portare ad inaspettati risultati. Questo problema si fa inoltre più frequente se si dichiara static (o shared in VB) il campo, condividendo il valore del membro per l'intero AppDomain.

A volte però, si vuole rendere l'istanza del campo accessible da chiunque purché dal medesimo thread, togliendo quindi il problema dell'accesso concorrente. L'attributo ThreadStatic permette di marcare un campo e di avere questo comportamento:

[ThreadStatic] private static object threadState;

Questa tecnica viene sfruttata per esempio dall'oggetto Transaction (System.Transactions) per mantenere l'oggetto rappresentante la transazione corrente cosicchè qualsiasi sotto chiamata possa accedere alla transazione corrente semplicemente chiamando Transaction.Current, il tutto isolato per thread (la transazione infatti non è visibile in altri thread, ma ne viene creata un'altra). Lo stesso comportamento, seppure meno comodo, si può ottenere usando Thread.AllocateNamedDataSlot, Thread.SetData e Thread.GetData che permettono di allocare per nome uno spazio, di impostarlo e di leggerlo, dove inserire un riferimento ad un oggetto.

La problematica di questo approccio è che nel caso in cui da un thread ne avviamo un altro e si vuole portare con se questi valori "speciali", occorre passarseli tramite argomenti o classi d'appoggio per poi essere copiati sul nuovo thread. Inoltre nel caso del ThreadPool, quell'insieme di thread già pronti all'uso, utilizzati quando si chiama la Begin*** di un delegate o si usa ThreadPool.QueueUserWorkItem, il campo statico risulta visibile alle operazioni che verranno prese in carico dal medesimo thread e mai rilasciato (si pensi al Dispose dell'oggetto) se non sovrascritto o impostato a null (il ThreadPool nel .NET 2.0 è composta da 25 Thread per CPU e di 500 IO Thread per CPU, in ASP.NET 2.0 sono 100/100, nel.NET 3.5 sono diventanti 250/500, mentre in ASP.NET 3.5 nella modalità AutoConfig sono rimasti invariati).

Per risolvere questo problema viene in aiuto la classe CallContext (System.Runtime.Remoting.Messaging) con i metodi LogicalGetData e LogicalSetData per leggere e impostare in base ad una chiave il riferimento ad un oggetto. Il comportamento è simile a ThreadStatic, ma questi valori sono relativi al contesto in cui sono stati impostati. Per capire meglio ho creato questa classe:

public class MyObject : Component { private readonly string _name;

public MyObject(string name) { _name = name; }

protected override void Dispose(bool disposing) { base.Dispose(disposing);

Console.WriteLine("Disposed {0}", _name); }

public override string ToString() { return _name; } }

E' una semplice classe che implementa IDisposable così da sapere quando l'oggetto, identificato con un nome, viene distrutto. Poi ho creato una ConsoleApplication che esegue su un thread del pool il controllo di un campo marcato con ThreadStatic, lo valorizza se è nullo e ne stampa il valore. La stessa operazione viene effettuata usando CallContext. Inoltre, attendo la fine dell'esecuzione per assicurarmi che le altre successive operazioni vengono effettuate nuovamente sul medesimo thread ed utilizzo GC.Collect per assicurarmi che gli oggetti, non più in uso, vengano distrutti (mi raccomando, in vere applicazioni non si deve chiamare se non in rare eccezioni):

class Program {

[ThreadStatic] private static object threadState;

static void Main(string[] args) { // Metodo da invocare su un Thread del pool WaitCallback wc = DoWork;

for (int x = 0; x < 3; x++) { // Invoco e attendo che finisca wc.BeginInvoke(null, EndWork, wc).AsyncWaitHandle.WaitOne();

// Forzo la liberazione degli oggetti GC.Collect(); GC.WaitForPendingFinalizers(); }

// Avvio l'operazione su un nuovo Thread Thread t = new Thread(DoWork); t.Start(); t.Join();

// Forzo la liberazione degli oggetti GC.Collect(); GC.WaitForPendingFinalizers();

Console.Read(); }

private static void EndWork(IAsyncResult ar) { ((WaitCallback)ar.AsyncState).EndInvoke(ar); }

const string DataKey = "test";

static void DoWork(object state) { Console.WriteLine("-----------------"); Console.WriteLine("Thread {0}", Thread.CurrentThread.ManagedThreadId);

object t = CallContext.LogicalGetData(DataKey); if (t == null) { t = new MyObject("LogicalData"); Console.WriteLine("LogicalData set"); CallContext.LogicalSetData(DataKey, t); } else Console.WriteLine("LogicalData: {0}", t);

t = threadState; if (t == null) { t = new MyObject("DataThread"); threadState = t; Console.WriteLine("DataThread set"); } else Console.WriteLine("DataThread: {0}", t); } }

Se lo si esegue, il risultato è il seguente:

----------------- Thread 6 LogicalData set DataThread set ----------------- Thread 6 LogicalData set DataThread: DataThread Disposed LogicalData ----------------- Thread 6 LogicalData set DataThread: DataThread Disposed LogicalData Disposed LogicalData ----------------- Thread 11 LogicalData set DataThread set Disposed DataThread

Come si vede, alla prima esecuzione di DoWork, entrambi i modi di memorizzare MyObject impostano il valore. Alla seconda esecuzione CallContext è di nuovo vuoto e va rivalorizzato, mentre threadState contiene il valore impostato sulla prima esecuzione. Lo stesso avviene anche alla terza esecuzione. E' interessante notare che l'oggetto impostato con CallContext viene effettivamente rilasciato e quindi ucciso dal GC solo all'avviarsi della nuova operazione sul medesimo thread (infatti il primo GC.Collect non ha sortito nessun effetto). Poiché i thread del pool non muoiono mai, DataThread non viene mai eliminato, ad eccezione di quello impostato nel Thread creato manualmente (l'esecuzione è finita e quindi il thread è inutilizzabile).
Tutto questo meccanismo è gestito dalla classe ExecutionContext (System.Threading) che è in grado di catturare, mettere a disposizione o di togliere il contesto e tutti valori ad esso associati. Quando si chiama ThreadPool.QueueUserWorkItem o il Begin*** di un metodo, viene chiamato ExecutionContext.Capture per catturare il contesto e tenerselo pronto quando il thread prende in consegna il delegate da eseguire, ripristinando quindi il contesto chiamando il metodo Run. Se avete mai dovuto creare un vostro ThreadPool, tipo questo, avrete sicuramente avuto a che fare con questa classe. Il bello di questo meccanismo è che se usiamo CallContext per mantenere dei valori ed invochiamo delegate asincroni o creiamo thread, automaticamente il contesto viene passato sull'altro thread condividendolo per la durata dell'operazione. Se nell'esempio precedente quindi si imposta prima di qualsiasi accodamento, l'istruzione CallContext.LogicalSetData(DataKey, new MyObject("test")); si ottiene a console:

Thread 6 LogicalData: test DataThread set ----------------- Thread 6 LogicalData: test DataThread: DataThread ----------------- Thread 6 LogicalData: test DataThread: DataThread ----------------- Thread 11 LogicalData: test DataThread set Disposed DataThread

Si noti che LogicalData su tutti i thread è già impostato.

Un'ultimo aspetto riguarda ASP.NET che utilizza anch'esso CallContext.HostContext ogni qualvolta si interroga HttpContext.Current, ma se si usano pagine asincrone con task ecc, i metodi asincroni non dispongono del contesto web e HttpContext.Current ritorna null. Diversamente usando CallContext.LogicalSetData si ha a disposizione l'oggetto anche sui task asincroni ed è quindi l'ideale se dovete mantenere DataContext (LINQ) o Session (NHibernate).

Perché non usate lo statement using?

Me lo chiedo perché la vedo raramente usata nei forum e nel codice che mi capita di guardare e mi domando il perché, visto che è così comoda da usare. Beh il mio consiglio è: qualsiasi oggetto create, se implementa IDisposable, usate sempre la using.
Per i seguenti motivi:

Occorre sempre chiudere risorse unmanaged in modo esplicito e il prima possibile. Se si demanda il lavoro al Garbage Collector il Dispose verrà effettuato sfruttando la Finalize e l'oggetto resterà nell'heap per un giro di GC in più e rischiamo inoltre che l'oggetto diventi più forte come generation e non venga più rimosso;
Anche se l'oggetto non fa uso risorse unmanaged, la Dispose va chiamata lo stesso. Primo perché non possiamo mai sapere se in una futura versione l'oggetto utilizzerà tali risorse e secondo perché chiamando Dispose, se la classe è scritta bene, viene chiamato GC.SuppressFinalize(this) così da togliere l'oggetto dalla finalization list, il GC lo rimuoverà dall'heap e il problema indicato nel primo punto non si verificherà.

Se scriviamo delle nostre classi che fanno uso di risorse unmanaged o di classi che a loro volta ne fanno uso, vi consiglio di ereditare da System.ComponentModel.Component. Implementa già il pattern Dispose, con l'interfaccia IDisposable, il metodo Finalize e mettendo a disposizione un metodo virtuale Dispose(bool disposing). Una tipica classe è così:

public class MiaClasse : System.ComponentModel.Component 
{ 
    private bool disposed; 
 
    public void MioMetodo() 
    { 
        if (disposed) 
            throw new ObjectDisposedException(base.GetType().Name); 
    } 
 
    protected override void Dispose(bool disposing) 
    { 
        if (disposing) { 
            risorsaunmanaged.Dispose(); 
        } 
        risorsaunmanaged = null; 
 
        this.disposed = true; 
        base.Dispose(disposing); 
    } 
}

L'uso della variabile disposed è "facoltaltiva", ma utile se vogliamo lanciare un eccezione nel caso qualcuno chiami un nostro metodo quando ne ha già chiamato il Dispose.
Quindi insomma, usiamo la using che non vi costa e scriviamo le classi nel modo giusto ;-)

Tags: .NET Framework

Spettro audio con WPF

Avete presente quei siti web che permettono di ascoltare tracce audio? E quelle barre che vanno su e giù senza senso anche se non si sente niente? Ecco, capisco che un player come quello di Flash o Silverlight possa non implementare l'analisi dell'audio, ma questa tecnica l'ho vista applicata anche in applicazioni client, anche scritte in WPF.

Mi è venuta quindi voglia di provare ad implementare una visualizzazione a barre dell'audio che si ascolta e di conseguenza ho cominciato dall'inizio: dalla teoria. Prima di tutto bisogna sapere che nel digitale le tracce audio sono campionate, un po' come i frame nei video, tantissime volte al secondo. Questi sample per esempio, a qualità CD sono 44100 al secondo e occupano 16bit per ogni canale e ovviamente più è alto il sample, maggiore è la qualità. Questa serie di byte si possono considerare come tante di sinusoidi, ciascuna delle quali possiede una frequenza e un'ampiezza. Queste informazioni si possono ottenere applicando un algoritmo di nome Fast Fourier Transform (FFT) e sfruttarle per creare spettri audio. Non sono un comuque un esperto ne di matematica ne di audio, quindi se siete interessati vi rimando a questa buona guida.

A questo punto mi serviva un modo per caricare i byte delle tracce audio e un sistema veloce per applicare FFT. In giro si trovano esempi che usano le API waveIn*** e waveOut***, ma sono limitati ai file wav che contengono solamente campionature pure. Ho deciso quindi di usare DirectShow che, sebbene sia più complesso, è potentissimo, ci sono filtri di ogni genere e tramite un SampleGrabber posso intercettare i sample in uscita dopo che sono stati decodificati. Questo mi permette quindi di aprire qualsiasi file audio compatibile con DirectShow. Considerando che FFT può essere applicato solo ad un set che sia una potenza di 2, che più sample prendo e più è preciso, ma che ad ogni secondo devo garantire una certa fluidità delle barre, ho deciso di campionare 4096 sample al secondo, così da garantire circa 11 frame al secondo.

Ovviamente, visto che ve ne ho parlato qualche giorno fa, ho usato C++ CLI per creare una DLL mixed dove una classe managed utilizza una unmanaged la quale crea il grafo DirectShow, prepara i filtri ed esegue l'analisi dell'audio, limitando quindi al minimo l'interop e ottenendo il massimo delle prestazioni. Ogni sample ottenuto viene raggruppato per range di frequenza e memorizzato il picco. Ho creato poi un element AudioVisualization in WPF che ad intervalli regolari interroga i picchi e tramite animation mostra le barre. Il risultato è buono e il rendering basato su WPF permette di realizzare qualsiasi tipo di visualizzazione.

Ho creato inoltre un'applicazione demo dallo skin molto semplice; purtroppo il mio grafico di fiducia ultimamente è molto occupato (a giocare :-D). Ecco un video dimostrativo:

Video: Reyalp

Tags: Silverlight, XAML

Interoperabilità .NET con C++ CLI

In quest'ultimo periodo mi sono addentrato in un mondo che ho sempre ammirato, ma che non ho mai avuto il coraggio di provare: il C++ CLI. Ammirato perché già non ho mai usato C++, figuriamoci un linguaggio più evoluto. Per chi non lo sapesse, infatti, C++ CLI è un linguaggio standard ECMA evoluzione delle Managed Extensions C++ e quindi di C++ che permette di mettere in comunicazione il mondo managed .NET con quello unmanaged.

Questo vuol dire che è possibile scrivere DLL che contengano sia codice nativo che lavori con qualsiasi API, sia codice managed che faccia uso poi di classi native. Oltre a ciò è possibile ottenere il codice di interop in automatico scrivendo direttamente da codice managed chiamate a tipi o funzioni native. Così facendo si riduce al minimo il marshaling dei tipi e C++ CLI diventa l'ideale per scrivere classi che permettano di beneficiare dei pregi dei due mondi.
Se avete avuto modo di usare la classe Marshal di System.Runtime.InteropServices sapete delle fatiche che si devono compiere per le strutture ecc e apprezzerete sicuramente questo nuovo strumento.

Beh insomma dopo un po' che ci sto lavorando devo dire che è ganzissimo. Ti senti come Peter Petrelli quando si ritrova tutti quei poteri. Come il personaggio nel senso che come lui non sono capace di usarli e mi fermo fra elementari ostacoli come conversione dei tipi, utilizzo delle librerie e puntatori. Pian piano però sto prendendo possesso di questi poteri, quindi più avanti vi illustrerò cosa sono riuscito a fare.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5

Controllo WPF: AdvancedListBox

Colto da un momento di creatività o meglio, rubando l'idea a Zune2, ho voluto creare una ListBox che avesse un effetto transitorio nella selezione. In pratica invece di avere il background del Border colorato e basta, avvio un'animazione che porta alla colorazione totale del Border. Nello stesso tempo decoloro l'elemento precedentemente colorato.

Per farlo ho dovuto estendere la ListBox e la ListBoxItem per avere tre nuove proprietà che mi dicono se l'elemento sta per essere selezionato, se sta per essere deselezionato e qual'è la direzione di navigazione.

Ecco il risultato. Ovviamente non è l'unico effetto che si può fare.

Video: WPF AdvancedListBox

Sorgenti e applicazioni di test qui.

Tags: .NET Framework, .NET Framework 3.0, .NET Framework 3.5, Windows Presentation Foundation, XAML

Multithreading WPF nel Binding

Devo segnalarvi un errore nello script #17 dove spiego come implementare INotifyPropertyChanged. Di sbagliato c'è la frase in cui dicevo che è obbligatorio invocare l'evento tramite il Dispatcher, quindi sul thread principale, e mostravo come chiamare la BeginInvoke.

In realtà il motore di Binding sull'evento PropertyChanged internamente controlla già se il thread corrente è quello principale. In caso contrario accoda l'evento sul Dispatcher con priorità DataBind. Quindi quello che proponevo non era sbagliato, ma inutile, risparmiando solo del lavoro al motore di Binding.

C'è da dire comunque che non è dato sapere chi utilizza le nostre proprietà, ma non è altrettanto bello mettere della logica specifica di WPF nelle classi (infatti non lo proponevo per il Domain Model). Va comunque fatta attenzione che solo l'oggetto Binding gestisce questo aspetto. Per esempio le CollectionView che lavorano sulle collezioni, s'arrabbiano generando un'eccezione se modichiamo le liste da altri thread. Possiamo però aggirare il problema invocando PropertyChanged e CollectionChanged sul thread principale affidandoci al Dispatcher. Se usate ObservableCollection<T>, vi basta sovrascrivere OnPropertyChanged e OnCollectionChanged.

Mi scuso per la mala informazione...

Tags: .NET Framework, .NET Framework 3.0, .NET Framework 3.5, Windows Presentation Foundation