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

Lambda Expression in Windows Presentation Foundation

Preso da LINQ, Expression e compagnia bella, mi è venuto in mente di provare ad applicare LINQ anche in WPF, la mia primissima passione. Ho pensato al Binding, che è bellissimo, ma spesso mi trovo a dover usare converter che, anche se molto stupidi, richiedono di creare una classe che implementi IValueConverter, referenziarla e instanziarla nel markup.

Ho creato quindi una MarkupExtension personalizzata che imposti in fase di inizializzazione un converter basato su espressioni inserite direttamente nel markup. Partiamo quindi dalla fine; l'utilizzo è il seguente e permette di mettere in maiuscolo ciò che è stato immesso nella TextBox txt:

<TextBox x:Name="txt" Text="Testo" />

<TextBlock Text="{Binding Path=Text,ElementName=txt, Converter={m:Expression value.ToString().ToUpper(culture)}}" />

Creare una MarkupExtension è abbastanza semplice. Basta ereditare dalla classe e implementare ProvideValue, chiamato in fase di inizializzazione del markup. La mia implementazione effettua il parsing dell'espressione, ottiene un delegate e la passa ad una nuova istanza di una mia ExpressionValueConverter che implementa IValueConverter e semplicemente chiama questo delegate:

public delegate object ExpressionConverterDelegate(object value, object target, Type targetType, object parameter, CultureInfo culture);

Il parsing dell'espressione l'ho poi affidato ad una serie di classi contenute nell'esempio DynamicLinq presente nel SDK del .NET Framework 3.5. Fatte alcune piccole modifiche, chiamando DynamicExpression.ParseLambda possiamo ottenere una lambda expression, in questo caso con la nostra firma, da poter compilare così da ottenere il delegate:

public override object ProvideValue(IServiceProvider serviceProvider) { IProvideValueTarget provideValueTarget = (IProvideValueTarget)serviceProvider.GetService(typeof(IProvideValueTarget));

LambdaExpression le = DynamicExpression.ParseLambda<ExpressionConverterDelegate>( new ParameterExpression[] { Expression.Parameter(typeof(object), "value"), Expression.Parameter(typeof(object), "target"), Expression.Parameter(typeof(Type), "targetType"), Expression.Parameter(typeof(object), "parameter"), Expression.Parameter(typeof(CultureInfo), "culture") }, typeof(object), this.ConvertExpression, null);

ExpressionConverterDelegate converter = (ExpressionConverterDelegate)le.Compile(); return new ExpressionValueConverter(provideValueTarget.TargetObject, converter); }

Figo no? Le performance poi una volta creato il delegate sono le medesime di una normale classe.

Qui il codice sorgente.

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

LINQ to reflection - Parte due

Qualche giorno fa ho parlato di come è possibile generare IL a runtime per velocizzare le operazioni che solitamente si effettuano via reflection.

Oltre alla FastCreateInstance ho implementato una FastSetValue. In questo caso il metodo dinamico generato non fa altro che ricevere l'istanza e il valore impostandola sulla proprietà. Ecco il codice dell'extension method:

public static void FastSetValue(this PropertyInfo property, object obj, object value) { if (property == null) throw new ArgumentNullException("property");

SetValueInvoker invoker = (SetValueInvoker)setValueInvokers[property]; if (invoker == null) { DynamicMethod method = new DynamicMethod(property.Name, null, new Type[] { typeof(object), typeof(object) }, typeof(object), true); ILGenerator il = method.GetILGenerator();

// ((Tipo)oggetto).Proprieta = valore il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Castclass, property.DeclaringType); il.Emit(OpCodes.Ldarg_1); if (property.PropertyType.IsClass) il.Emit(OpCodes.Castclass, property.PropertyType); else il.Emit(OpCodes.Unbox_Any, property.PropertyType); il.EmitCall(OpCodes.Callvirt, property.GetSetMethod(true), null); il.Emit(OpCodes.Nop); il.Emit(OpCodes.Ret);

invoker = (SetValueInvoker)method.CreateDelegate(typeof(SetValueInvoker)); setValueInvokers[property] = invoker; } invoker(obj, value); }

La tecnica è la stessa del FastCreateInstance. Un Hashtable mantiene il delegate specifico per la PropertyInfo e se non c'è crea il codice IL. In questo caso carica nello stack il primo argomento (l'entità) e ne effettua il cast sul tipo. Poi carica il secondo argomento (il valore da impostare sulla proprietà) e ne effettua il cast se è un tipo di riferimento o l'unboxing se è un tipo di valore (numeri, date, ecc). A questo punto chiama il metodo set_nomeproprietà (le proprietà in .NET non sono altro che metodi con una nomenclatura particolare) che preleva dallo stack i due argomenti inseriti.

Una volta pronto il delegate SetValueInvoker(object obj, object value), poi lo chiamiamo con i parametri ricevuti. Ed ecco il suo utilizzo:

PropertyInfo pi = typeof(Product).GetProperty("Description", BindingFlags.Public | BindingFlags.Instance); Product p = new Product(); pi.FastSetValue(p, "ciao");

Il risultato è che siamo passati da un'operazione più lenta 150 volte (la normale SetValue della PropertyInfo) ad un 15 volte più lento e anche in questo caso a causa del costo di ricerca nell'Hashtable e di creazione del metodo alla prima chiamata.

Una nota interessante su OpCodes.Castclass. In realtà questa operazione (obbligatoria quando scriviamo codice in C#) non è indispensabile poiché effettua solo un controllo sul tipo di puntatore presente nello stack. Se omesso, anche se sbagliamo il tipo, il CLR comunque va ad inserire un valore scorretto. Potremmo perfino inserire un numero in una stringa e tutto andrebbe senza problemi fino a quando non chiamiamo un metodo di istanza che fa saltare per aria il CLR :-). Ho preferito comunque lasciare il cast poiché non voglio fidarmi ciecamente del chiamante ed inoltre il costo di tale operazione è minimo e trascurabile.

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

Eccovi LINQ to reflection

Un bel titolo ingannevole per attirarvi a leggere alcuni extension method che ho sviluppato per risolvere in parte le problematiche di performance delle quali ho discusso qua.

Come avevo accennato, un'opzione può essere quella di generare codice dinamico. Per farlo facilmente LINQ include un namespace System.Linq.Expressions dove possiamo rappresentare un'espressione con un modello ad oggetti. Questa classi sono vitali per LINQ to SQL e simili, ma la cosa carina è che la LambdaExpression permette di compilare l'espressione e ottenere un delegate ad essa. In particolare Expression<TDelegate> ci consente di specificare qualsiasi espressione con uno specifico delegate direttamente da codice per poi ottenerne il puntatore con il metodo Compile. Per esempio:

Expression<Func<Product>> ef = () => new Product(); Func<Product> f = ef.Compile(); Product p = f();

Il codice precedente rapprenta prima l'espressione per creare una nuova istanza di Product, poi la compila per avere una funzione vera e propria che non vuole nessun parametro, ma il cui tipo di ritorno è Product. Una cosa importantissima è la prima riga: poiché vogliamo un Expression il compilatore genera codice per rappresentare la lamba expression, diversamente dal normale uso che si fa con LINQ to Object, dove viene effettivamente creato un metodo che contiene la lambda.

Quindi questa introduzione per dire che possiamo usare questa caratteristica per generare al volo un metodo che ci permetta di istanziare velocemente un tipo. Ecco quindi l'extension method che ho sviluppato:

public static object FastCreateInstance(this Type type) { if (type == null) throw new ArgumentNullException("type");

CreateInstanceInvoker invoker = (CreateInstanceInvoker)createInstanceInvokers[type]; if (invoker == null) { LambdaExpression e = Expression.Lambda(typeof(CreateInstanceInvoker), Expression.New(type), null); invoker = (CreateInstanceInvoker)e.Compile(); createInstanceInvokers[type] = invoker; } return invoker(); }

In pratica con un Hashtable mantengo una lista di delegate in funzione del tipo e se non c'è, creo una LambdaExpression, la compilo per ottenere il delegate che userò le successive volte. L'utilizzo del metodo poi è semplicissimo:

Product p = typeof(Product).FastCreateInstance();

Usando questa tecnica i tempi si dimezzano rispetto all'uso di Activator.CreateInstance, seppure mai veloce abbastanza come usare il costruttore direttamente. Il costo dell'operazioni infatti si sposta e in questo caso è dovuto più al recupero del delegate in modo thread safe dall'Hashtable.

Cosa fa il metodo Compile? Utilizza la classe DynamicMethod che consente di generare per l'appunto un metodo dinamico, mediante IL per poi darlo in pasto al jitter e renderlo così veloce quanto il normale codice. Questa classe esiste dal .NET Framework 2.0 e facilita la definizione di Assembly, Module e Type dinamici, già possibile fin dalla versione 1.0. L'unico inconveniente è che bisogna masticare un po' di IL, perciò il metodo FastCreateInstance può creare il delegate anche in questo modo:

DynamicMethod method = new DynamicMethod("method", typeof(object), new Type[0], typeof(object), true); ILGenerator il = method.GetILGenerator(); il.Emit(OpCodes.Newobj, type.GetConstructor(new Type[0])); il.Emit(OpCodes.Ret);

invoker = (CreateInstanceInvoker)method.CreateDelegate(typeof(CreateInstanceInvoker));

Definisce un metodo senza parametri, ma con tipo di ritorno Object, ed emette due istruzioni: la newobj che crea l'istanza del tipo e mette nello stack il puntatore, mentre ret lo estrae dallo stack e lo restituisce al chiamante.

Ho trovato interessante questi internal perché piuttosto importanti e perché fanno capire meglio LINQ. Nel prossimo post mostrerò l'implementazione di FastSetValue e un FastSetValues che permette di valorizzare più proprietà contemporaneamente guadagnando moltissimo in prestazioni, ovviamente tutto direttamente in IL :-)-

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

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