Flex nel mondo .NET

L'innegabile crescente successo del framework open source Adobe Flex (per applicazioni RIA) ha portato, oltre al famoso Flex Builder, alla creazione di diversi ambienti utili allo sviluppo e al debugging.
Si pensi ad IntelliJ IDEA, un IDE Java, che recentemente ha aggiunto il supporto per Adobe Flex oppure alla recente partnership di Abobe con SAP.  SapphireSteel, che chi sviluppa in Ruby avrà sicuramente sentito nominare, ha presentato Ametista per lo sviluppo in Visual Studio usando Flex. Merita di essere segnalato anche un framework: WebORB in versione .NET per l'accesso ai dati da Flex/Flash.
Le feature sono diverse, si passa dal supporto per Silverlight, ai template per Visual Studio, supporto per MSMQ queue ecc.
Questa soluzione si affianca ad un altro framework: FluorineFx che implementa Flex/Flash Remoting, Flex Data Services sempre per il .NET Framework.

Ovviamente dal canto mio trovo più interessante osservare alcuni casi che riguardano più da vicino .NET. Nonostante non abbia mai scritto una riga di codice con le API di Flex, ho voluto provare a togliermi la curiosità di sapere se per noi sviluppatori .NET la scelta di Silverlight sia proprio scontata, quindi per eseguire qualche esperimento ho utilizzato Tofino, plugin per Visual Studio 2008 presentato da Ensemble.

Il setup del plugin pesa all'incira 83 MB e per funzionare necessita che Java sia installato. Tramite i template aggiunti possiamo creare facilmente un progetto Flex:

 
Ed è qui che sono iniziati i "problemi".

Pur trattandosi di una plugin in beta, trovarsi senza supporto per l'intellisense per i file MXML o per l'ActionScript è stato un pò "sconfortante". Per il momento non è previsto neanche un editor visuale per MXML.  Con questo non voglio assolutamente sminuire il lavoro svolto, anzi sono certo che continuerò con interesse a seguire l'evolversi non solo di questo plugin ma di tutti gli esempi di integrazione del mondo Flash nel mondo .NET ma, trovo che per il momento, sviluppare tramite il framework Flex in ambiente .NET non sia praticabile o per meglio dire la strada da percorrere è sicuramente più in salita rispetto ad uno che si avvicina per la prima volta a Silverlight.