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

Riutilizzare porzioni di espressioni LINQ

Cristian "Ricciolo" Civera — Fri, 04 Jul 2008 05:31:00 +0100

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

Cristian "Ricciolo" Civera — Mon, 30 Jun 2008 18:31:00 +0100

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

Cristian "Ricciolo" Civera — Mon, 30 Jun 2008 09:12:00 +0100

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

Cristian "Ricciolo" Civera — Sat, 28 Jun 2008 17:56:00 +0100

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

Cristian "Ricciolo" Civera — Tue, 13 May 2008 19:56:00 +0100

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

Cristian "Ricciolo" Civera — Fri, 04 Apr 2008 23:57:00 +0100

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

Cristian "Ricciolo" Civera — Tue, 18 Mar 2008 17:51:00 +0100

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

Cristian "Ricciolo" Civera — Sat, 08 Mar 2008 17:29:00 +0100

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

Cristian "Ricciolo" Civera — Sat, 16 Feb 2008 18:34:00 +0100

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

Cristian "Ricciolo" Civera — Mon, 28 Jan 2008 17:20:37 +0100

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

Cristian "Ricciolo" Civera — Wed, 23 Jan 2008 12:49:59 +0100

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

Cristian "Ricciolo" Civera — Fri, 04 Jan 2008 14:21:18 +0100

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!

Cristian "Ricciolo" Civera — Thu, 03 Jan 2008 14:51:00 +0100

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

Cristian "Ricciolo" Civera — Wed, 02 Jan 2008 13:48:16 +0100

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

Cristian "Ricciolo" Civera — Sun, 16 Dec 2007 23:45:00 +0100

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).