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

Reflection: migliorare le performance

La reflection è quello strumento che permette di interrogare a runtime i metadati di un assembly, analizzare i tipi, i membri ed invocare dinamicamente metodi, proprietà ed eventi. Il namespace System.Reflection c'è dal .NET Framework 1.0 e l'importanza di questo strumento si è fatta sempre più sentire, da una parte perché il framework è sempre più configurabile, dall'altra perché framework come NHibernate, Linq to SQL o Entity Framework lo pongono al centro di una questione importante: le performance.

Infatti la reflection è lenta. Tanto per dare un'idea con un semplice esempio, se dobbiamo creare un'istanza di una classe possiamo farlo chiamando il costruttore nel canonico modo oppure via reflection:

for (int x = 0; x < max; x++) p = new Product();

Type t = typeof(Product); for (int x = 0; x < max; x++) p = Activator.CreateInstance(t);

Sulla mia macchina, con 10milioni di iterazioni ottengo questi tempi:

00:00:00.1892963 00:00:01.8751132

Ci mette ben 10 volte di più. Per non parlare di come impostare le proprietà:

for (int x = 0; x < max; x++) p.Description = "ciao";

PropertyInfo pi = typeof(Product).GetProperty("Description", BindingFlags.Public | BindingFlags.Instance); for (int x = 0; x < max; x++) pi.SetValue(p, "ciao", null);

Escludendo i tempi di ricerca della proprietà con il metodo GetProperty, i dati sono:

00:00:00.1141661 00:00:16.4958957

Ovviamente questi sono dati indicativi ed è ovvio che il confronto con il codice compilato è ingiusto. Con la reflection abbiamo più dinamicità sui tipi e possiamo creare strumenti come gli ORM citati prima.

Come si possono quindi aumentare le performance? Una possibilità è quella di generare dinamicamente codice specifico per quel tipo e per certi membri. Infatti all'interno del namespace System.Reflection.Emit c'è tutto quello che serve per emettere IL al volo godendo delle stesse performance del codice compilato.
Una delle accuse che si fanno a NHibernate o LINQ to SQL è che sono lenti per via della reflection. In realtà, sia il primo (dalla versione v2) che il secondo, tolto il lavoro che fanno inizialmente di analisi delle classi e dei mapping, non usano reflection, ma a regime istanziano e impostano campi e proprietà con IL generato ad hoc. L'overhead semmai risiede nella gestione dei delegate e nel lavoro di mapping. In fondo se si pretende di lavorare indipendentemente dal database e instanziare tipi dinamicamente, non si può neanche pretendere di non pagare qualcosa per questa ulteriore stratificazione.

Comunque non è delle implementazioni degli ORM che mi interessa parlare, ma bensì di come generare codice IL. Lo mostrerò nel prossimo post dove farò vedere alcuni extension method che usano la System.Reflection.Emit e la classe LambaExpression per velocizzare le operazioni di reflection.

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

Riutilizzare porzioni di espressioni LINQ

Se anche voi usate in alcuni progetti LINQ to SQL come DAL, vi troverete un domain model e le classi create tramite il DBML. Questo perché le prime vengono usate nello strato di presentazione e in quello business, mentre le seconde utilizzate all'interno del DAL realizzato con LINQ to SQL.
Di conseguenza ci ritroviamo a dover mappare le due entità in modi più o meno complessi. Poniamo di avere la classe Customer di LINQ to SQL e quella del domain model (per semplificare con mapping 1:1):

public class CustomerL2S { public int ID { get; set; } public string Description { get; set; } }

public class Customer { public int ID { get; set; } public string Description { get; set; } }

In un ipotetico metodo GetSingle che dato l'ID ti dà l'entità, scriviamo qualcosa del genere:

var customer = from c in customers where c.ID == 1 select new Customer { ID = c.ID, Description = c.Description };

Poi magari un metodo di List restituisce tutti i Customer, senza filtrarli e purtroppo ci tocca duplicare l'intera query, compreso tutto il mapping, senza la clausola where. Potremmo essere tentati di fare una funzione, così:

var customer = from c in customers where c.ID == 1 select GetCustomer(c);

Purtroppo questa tecnica non funziona, perché passiamo una funzione managed al motore di LINQ to SQL che non può passarla a SQL Server. Il problema non sta nella funzione, ma in ciò che essa fa. Infatti la soluzione sta nel lavorare sempre a livello di expression tree. Potremmo infatti creare un extension method (solo per comodità nella chiamata) specifico per il Customer che effettua il mapping che ci permetta di riutilizzarlo più volte:

public static class Extentions { public static IQueryable<Customer> SelectToCustomer(this IQueryable<CustomerL2S> source) { return source.Select(c => new Customer { ID = c.ID, Description = c.Description }); } }

Nella funzione accettiamo un IQueryable specifico per l'entità CustomerL2S e sfruttando l'extension method select effettuamo il mapping, ma sempre a livello di espressione, consentendola di portarla su SQL Server. L'utilizzo poi è semplice:

var customer = (from c in customers where c.ID == 1 select c).SelectToCustomer();

Il doppio select è d'obbligo per via della query syntax, ma non è un problema poiché la query SQL generata è corretta.

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

LINQ to SQL: Chiamare extension method non implementati

Credo che qualcuno si sia già imbatutto in un problema dovuto ad una query LINQ to SQL simile a questa:

bool MiaFunzione(Customer c) { return true; } var customer = from c in dc.Customers where MiaFunzione(c) select c;

Se lo eseguiamo otterremo un exception perché MiaFunzione è un metodo managed e non può essere valutato tramite una query SQL. L'esempio può sembrare palese, ma in realtà questo problema c'è anche con extesion method come Contains o tutti quelli che accettano un IEqualityComparer, non portabile sul SQL Server.

Poiché quando chiamiamo un extension method il compilatore individua il metodo che come argomento vuole il tipo più vicino alla variabile, quando interroghiamo dc.Customers, la cui proprietà è di tipo Table<T> che a sua volta implementa IQueryable<T>, andiamo a chiamare i metodi contenuti nella classe System.Linq.Queryable i quali lavorano sull'espressione, per poi essere valuta, trasformata in query SQL ed eseguita, all'effettivo consumo dell'enumeratore.
Se però il tipo è IEnumerable<T> andiamo a chiamare i metodi della classe System.Linq.Enumerable, non lavorando più sull'espressione, ma aggiungendo nuovi iteratori che valuteranno T ad ogni ciclo.

Di conseguenza, per risolvere i problema basta effettuare un downcast su IEnumerable<T> o meglio ancora l'extesion method AsEnumerable.

var customer = from c in dc.Customers.AsEnumerable() where MiaFunzione(c) select c;

Attenzione però, così facendo l'extension method Where consuma l'intero dc.Customers ottenuto da SQL Server, di conseguenza viene scaricata l'intera tabella dal DB per poi essere filtrata con LINQ to Object. Il alcuni casi potrebbe andare bene, in altri no; basta saperlo.

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

Extension method ricorsivo per LINQ

Ultimamente sto giocando parecchio con LINQ e trovo incredibile come possa cambiare il modo di scrivere parti di codice: tutto diventa più leggibile e si ha subito l'idea di cosa una query faccia.

Oggi dovevo sfogliare tutte le sezioni di configurazioni e per ognuna chiamare il metodo ProtectSection per criptarla. Siccome ogni gruppo di configurazione ha delle sezioni e a sua volta dei sotto gruppi di configurazione, dovevo fare una funzione da richiamare in modo ricorsivo per ogni gruppo, ma non mi piaceva. La domanda che ormai mi pongo è: si può fare in LINQ? In questo caso no o almeno io non ho trovato un extension method o una combinazione di essi che facesse al caso mio. Perciò ne ho creato uno mio generico, per rendere flat una struttura ad albero:

public static class Extensions { public static IEnumerable ToFlat(this IEnumerable source, Func<T, IEnumerable<T>> childPredicate) { foreach (T t in source) { yield return t;

IEnumerable children = childPredicate(t); foreach (T child in ToFlat(children, childPredicate)) yield return child; } } }

In pratica, prende una lista e la sfoglia restituendo ogni elemento della lista stessa. Poi attraverso un predicato ottiene i figli di ogni elemento e per ognuno chiama ricorsivamente la funzione. In questo modo si ottiene un enumeratore piatto che sfoglia tutti gli elementi di una struttura ad al albero.

L'utilizzo poi è banale. Per esempio per sfogliare tutti i controlli di una pagina (il cast serve perché ControlsCollection non implementa IEnumerable):

var allControls = this.Controls.Cast().ToFlat(c => c.Controls)

Semplice ed efficace, vero?

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

Uso improprio dei generics

I generics sono tanto belli bellini. Senza di essi non esisterebbe LINQ, gli extension method non avrebbero trovato così ampio spazio e non potremmo scrivere classi generiche utilizzabili per più tipi.

Ci sono alcune pratiche però che mi capitano di vedere e io non ritengo corrette. Per esempio capita di vedere metodi che accettano un tipo generico ed effettuano un cast al loro interno, celandolo al chiamante:

public static T GetValue<T>() { object obj = ....; return (T)obj; }

L'esempio è banale, ma sufficiente per illustrare il mio dubbio. I generics son nati per tipizzare e migliorare anche in performance (evitano cast e box/unbox). Nel passato si usava un ArrayList e la cosa principalmente brutta era non avere una tipizzazione e si rischiava di cadere in InvalidCastException. Con i generics questo problema è stato risolto. Ciò che non mi piace del codice precedente è che celiamo al chiamante il fatto che io faccio un cast e per chi usa questo metodo sembra tutto sicuro e tipizzato.
In LINQ to DataSet hanno messo l'extesion method Field<T> che data la colonna ti restituisce il valore tipizzato, così:

int c = row.Field<int>("colonna")

Qual'è la differenza rispetto a quest'altro codice?

int c = (int)row["colonna"]

Di fatto nessuna. Entrambi sono potenzialmente vittime di un InvalidCastException, solo che il primo codice è stilisticamente più bello da vedere. Non trovate? Ormai avere un cast nel codice è come avere qualcosa di sporco e infatti nella maggior parte dei casi secondo me è così. Con l'extension method generic hanno reso più bello il codice, ma di fatto il problema resta.
E' vero che nella documentazione c'è giustamente scritto che tra le probabili eccezioni c'è tale eccezione, ma a questo punto allora mi domando: perché implementare un metodo del genere?

Viceversa trovo molto bello l'uso dei metodi generic per effettuare downcast. Per esempio:

public static IEnumerable<TSource> AsEnumerable<TSource>(this IEnumerable<TSource> source) { return source; }

In questo caso non viene coinvolto nessun cast, cosa che dovrei usare (seppure in modo sicuro) se non avessi questo metodo, ma semplicemente diciamo al compilatore su che tipo riferirsi se poi eventualmente chiamiamo altri metodi.

Ok, ci sono problemi ben più seri nella vita, ma comunque rendo pubblica questa mia riflessione.

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

Le novità di WPF 3.5 nel service pack 1

Come sappiamo è in corso lo sviluppo del service pack 1 del .NET Framework 3.5 e anche WPF non immune da nuove funzionalità.

Cominciamo dai controlli che si arricchiscono dei nuovi DataGrid, WebBrowser e in futuro anche di Office Ribbon. Il primo, fortemente richiesto, supporta modifiche in place transazionali, ordinamento, multi selezione, validazione e la virtualizzazione delle righe e delle colonne come già avviene, per esempio, per la ListBox. Il WebBrowser invece, in alternativa al Frame, permette di accedere al DOM della pagina, avere un maggior controllo del componenti IE e consente di incorporare anche applicazioni in Silverlight.

Ai nuovi controlli si aggiungono piccoli ritocchi:

supporto StringFormat nelle espressioni di Binding;
template per righe alternate negli ItemsControl;
la virtualizzazione delle righe per gli ItemsControl può ora reciclare (attached property VirtualizationMode) gli elementi non più visibile e permettere lo scrolling e relativa creazione degli elementi solo quando l'utente rilascia il mouse (attached property IsDeferredScrollingEnabled), così da risparmiare memoria. Anche la TreeView supporta ora la virtualizzazione degli elementi. Per maggiori informazioni sull'attuale funzionamento è disponibile questo articolo;
nuova interfaccia IEditableCollectionView per intervenire tramite viste sulle sorgenti dati;
supporto al binding con sorgenti Linq To Sql e Linq To Entities migliorando inoltre le performance con IEnumerable;
miglioramenti di performance nel rendering di testo, nella grafica 2D e nella classe WriteableBitmap;
alla proprietà BitmapEffect si affianca Effect che a differenza dell'altra permette di utilizzare effetti come blur e shadow mediante l'accelarazione grafica e sfruttando le capacità di pixel shader delle GPU, rendendolo di fatto di gran lunga più performance rispetto all'elaborazioni bitmap basate su CPU;

A tutto questo non mancano miglioramenti all'ambiente di sviluppo in Visual Studio 2008, costituiti da un completo supporto agli eventi e agli style, al refactoring e references degli elementi, ad una migliore segnalazione dei problemi in caso di eventuali errori a runtime nel markup, non rilevati in fase di compilazione.

Per ultimo vi sono novità sul fronte client (quindi anche WinForms) e al deployment degli applicativi. E' prevista una nuova modalità "Client profile" che consente di distribuire l'applicativo richiedendo solo un sotto insieme degli assembly contenuti nel framework escludendo quelli che trovano utilità solo in applicazione server, come per esempio la parte di ASP.NET, riducendo il setup a circa 20MB (rispetto a 270MB totali).
Ad esso si unisce un piccolo bootstrapper, compatibile con ClickOnce (interfaccia ora personalizzabile), che si occupa di installare l'intero .NET Framework 3.5 o se richiesto solo il sotto insieme client e in un secondo momento, se richiesto da un'ulteriore applicazione, di installare il restante Framework. Anche Visual Studio 2008 supporta questa modalità e presenta degli errori in fase di compilazione nel caso dovessimo usare assembly non presenti nel Framework ridotto.

Non ci sono eclatanti novità a dimostrazione del fatto che già WPF nella sua prima versione era già un ottimo framework, ma devo dire che mi soddisfano. Forse resta l'ambiente di sviluppo ancora un po' indietro e manca ancora di molte funzionalità, ma a piccoli passi forse ce la faremo :-)

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

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>