Il 13 settembre del 2011 sono state rilasciate la preview del .NET Framework 4.5 e di Visual Studio 2011, anche noti come .Net Framework e VS vNext.
Sicuramente la feauture più attesa è il supporto diretto alle nuove tecnologie che verranno introdotte con Windows 8, riunite sotto il cappello di Windows Runtime (WinRT). Si tratta di un framework multi-linguaggio che affianca il CLR e che può essere assimilato ad una evoluzione degli “odiati” COM in chiave moderna, con cui programmare il nuovo gioiello di Redmond tramite markup web (HTML 5) e relativi linguaggi di programmazione (javascript), senza però tagliare fuori lo sviluppo con gli strumenti classici. La nuova API è pensata per abbracciare le esigenze del “sempre connesso”, nate dalla diffusione del concetto di “APP” e dell’esplosione del mercato dei dispositivi Mobile.
La nuova architettura relativa alle App Metro
Una volta sviluppata la propria APP, sarà possibile creare il “package” di deploy, una sorta di componente atomico indipendente (ad esclusione ovviamente del .Net Framework stesso) che potrà essere installato in diversi modi: da Visual Studio a PowerShell fino al futuro Windows Store.
Ovviamente il concetto focale è quello di Markup, ovvero programmare utilizzando un paradigma già presentato con XAML, ed ora esteso ad HTML5/JavaScript, creando interfacce basate sul nuovo look Metro (leggasi Windows Phone 7) e su una intrinseca gestione asincrona dell’App stessa, isolata all’interno della propria sandbox.
Metro e Windows 8 (preview edition)
C# 5 e VB 11 puntano, perciò, a semplificare al massimo l’invocazione asincrona dei metodi/servizi grazie alle nuove keyword async e await che utilizzano implicitamente le funzionalità di Task proprie del Parallel Framework, introdotto come componente aggiuntivo della precedente versione del framework per sfruttare appieno le capacità multi-core dei processori.
Ritornando al framework 4.5, troviamo un migliorato Garbage Collector (Background Server GC), che sfrutta le CPU multi-core e gestisce più efficacemente la de-allocazione di oggetti di grandi dimensioni (Large Object), una diminuzione del tempo di avvio delle applicazioni ASP.NET (stimato da Microsoft introno al 35%), l’inclusione della libreria AntiXSS e la gestione degli handler e del binding sul modello delle WebForm.
Restando in ambito web, a settembre Microsoft ha rilasciato inoltre la preview release di ASP.NET MVC 4 (la prima release è stata presentata ad aprile del 2009), il framework che offre un approccio alternativo al disegno di applicazioni web tramite la declinazione “model2” del pattern architetturale MVC. Ovviamente la nuova versione è in grado di sfruttare appieno le nuove feauture dei linguaggi, oltre ad abbracciare il mondo HTML5/CSS3.
Passando al mondo desktop, anche le applicazioni WPF 4.5 sono decisamente più reattive, ed il layer si arricchisce dei Ribbon, di nuove funzioni sul Data Binding ed una rivista interoperabilità con Win32.
Novità interessanti arrivano anche per quanto riguarda WCF 4.5, con il supporto ai WebSocket, che consentono di ottimizzare la comunicazione (bidirezionale) su rete, diminuendo la richiesta di banda e il tempo di latenza nella trasmissione grazie ad un sistema di Compressione Binaria. Le attività di Configurazione vengono ulteriormente semplificate, soprattutto in ambito IIS, mentre l’engine produce ora un WSDL “atomico”, ossia contenuto in un unico file senza reference esterni.
Workflow Foundation 4.5 reintroduce ufficialmente le State Machine, oltre a presentare nuove funzioni per il Designer, il supporto alle Espressioni in C# e lo sviluppo Contract First. Purtroppo sembra che anche in questa versione il versioning non sarà supportato.
Il nuovo framework includerà nativamente anche il Managed Extensibility Framework (MEF), utile per realizzare applicazioni leggere, estensibili e ben strutturate che favoriscono il riuso del codice.
Passando a Visual Studio vNext, come si può facilmente intuire, l’IDE ora supporta pienamente HTML 5 e CSS3, ponendosi come soluzione naturale per lo sviluppo di soluzioni Windows 8, ma anche per applicazioni cloud pensate per la piattaforma Windows Azure.
VS 2011 Developer Preview Installer
Un fastidioso bug che dovrebbe essere risolto con questa nuova release è quello dei frequenti blocchi (freeze) della versione 2010.
VS 2011 Developer Preview, Start Page
Dal punto di vista della UI, il componente che ha subito una modifica radicale è Solution Explorer (in italiano Esplora Risorse), grazie al quale è ora possibile Cercare Tipi, Proprietà dei Tipi, Simboli e Relazioni tra essi. Arriva, inoltre, la finestra Quick Launch, per eseguire direttamente comandi, e l’ highlighter del codice.
VS 2011 Developer Preview, Solution Explorer
A fare la parte da leone, però, sono le nuove funzionalità dedicate al miglioramento dell’intero ciclo di gestione delle applicazioni, a partire dalla migliore gestione del TDD (Test Drive Development) in stretta simbiosi con il Test Impact Analysis. Centrale risulta il nuovo Test Runner, che permette di lanciare direttamente test di MsTest, nUnit e xUnit, oltre ad introdurre gli extensibility point per agganciare altri framework di test.
VS 211 Test Explorer
Quello che risulta più oscuro, invece, è il futuro di Silverlight, che quasi sicuramente verrà accantonato da Microsoft in favore di HTML 5, non prima però del rilascio della versione 5. La scelta non sorprende, vista anche la decisione (non ufficiale) di Adobe di bloccare lo sviluppo di Flash per le piattaforme Mobile. Le indiscrezioni sono inoltre avvalorate dal fatto che Scott Guthrie, vice presidente della visione Microsoft Developer, nel corso di un webcast è stato molto vago circa le domande relative proprio al futuro di Silverlight e alle versioni successive alla 5.
Si chiude qui il nostro lungo viaggio attraverso l’evoluzione dei linguaggi e degli ambienti di sviluppo Microsoft, che, volenti o nolenti, hanno caratterizzato e condizionato l’evoluzione del software e, sicuramente, continueranno a farlo.
Infatti la situazione di Silverlight la trovo assurda e offensiva per chi ha creduto in questo strumento e vi ha investito tempo e denaro.
Comunque una sua dismissione la troverei incredibile per due motivi: il primo è che Silverlight è figlio di WPF, e quest’ultimo non è stato certo dismesso (e lo spero proprio!).
Il secondo è che proprio Silverlight è alla base di Windows Phone 7 e della sua interfaccia Metro, che sarà portata a breve anche sulla XBox 360.
Vedremo come andrà finire, ma spero che Microsoft non faccia questo passo falso.
Articolo molto interessante come sempre.
A quando un bell’articolo su Java 7 e Java EE?
Incredibile…ancora Visual Basic in giro…non ho parole! :D
Non ho mai amato VB, l’ho sempre ritenuto un linguaggio confuso e con una sintassi prolissa e appesantita. Si vede da un miglio che non è nato per le moderne metodologie e le estensioni aggiunte per renderlo “a passo coi tempi” hanno creato – secondo il mio modesto parere – un’immane “porcheria”. Oramai C# è bello che maturo e cresciuto, sabbe ora che lo soppianti definitivamente.
8,28 GB di installazione??! Mamma mia, ma che reinstalla windows! :D
@Crick
Purtroppo almeno in Italia ci sono ancora tante stimate aziende che realizzano e vendono gestionali basati sul vecchio VB 6, altro che migrazione a c#. E sto parlando di aziende note in tutta italia e che fatturano centinaia di milioni, come TeamSystem o Esa Software…
@Cesare Di Mauro
Staremo a vedere, ma a mio avviso già da molti anni Microsoft ha dimostrato di coinvolgere molto poco gli sviluppatori nelle sue scelte e temo che agirà senza dover rendere conto a nessuno. Questo è il principale motivo che mi ha portato ad abbandonare definitivamente i suoi strumenti.
Secondo me Microsoft ha sbagliato anche a promuovere e basarsi così tanto una tecnologia che è nata fondamentalmente per rompere le scatole a Flash…
@betalab
Su Java EE si potrebbero fare una cinquantina di articoli :). Purtroppo, anzi per fortuna, io non ho visuto i primi anni dei famigerati EJB2
nooooooooo!!!
ancora COM no! vi preeeeeeeego!!!!
vabbe’, pensiamo positivo. forse riescono a farne una tecnologia decente e piu’ semplice da sviluppare.
@Crick
vedi, e’ questione di punti di vista.
io ad esempio considero la sintassi C-like, quanto di piu’ demente si possa immaginare.
il vb.net (da non confondere col 6, 2 pianeti diversi) ha livelli di produttivita’ che il C# si sogna, nonostante la prolissita’.
Tutti i tool di azure sono in silverlight, anche quelli di amministrazione interni, vedi qualche video di BUILD 2011 :D
Silverlight per app LOB è la manna, produttività e controllo del compilatore ad ogni livello, una goduria :D
@Andrea del bene
Hai ragione, ci sono centinaia di aziende, grandi e piccola che sviluppano ancora in vb6, ma fortunatamente la transizione è davvero dietro l’angolo, d’altronde anche a loro interessa essere su win8 (e con vb6 non ci sarai proprio)
@dubbioso:
con com non dovrai avere a che fare.
Produttività di VB che il C# si sogna? LOL ma cosa stai dicendo, oramai c’è un rapporto 1:1, le uniche differenze sono di sintassi e sinceramente la sintassi C-Like è quanto di più naturale da chiedere ad un programmatore.
Da quando la sintassi del C è “naturale” per un programmatore?
@Daniele
purtroppo, con i com ho a che fare tutti i giorni dato che molto del mio lavoro consiste nel creare oggetti com in c++ (e non dimentico mai di “ringraziare” stroustrup e microsoft, ognuno per la sua parte, per il “bel” regalo che ci hanno fatto).
il fatto che paragoni la produttivita’ del c# con quella del vb dimostra che non hai mai usato quest’ultimo, del resto il c# ha il peccato originale della sintassi c-like e, per quanto migliore di quella del c++ (e non ci vuole molto), tanto di piu’ non si puo’ fare.
un consiglio, se vuoi una sintassi naturale per il programmatore prova python (anche ruby mi piace molto)
Del fatto che molte aziende usino ancora vb6… questo purtroppo lo so e ne sono cosciente. Ma considero anche che andrebbe fatto un investimento per la migrazione verso le attuali piattaforme e anche verso le nuove piattaforme che si affacceranno a breve (w8 ecc), dove il codice sia più gestibile e la manutenzione sia semplificata. Pensiamo che a breve molte nuove “reclute” che sono sul mercano non sanno manco cosa sia vb6 (buon per loro, imho) ma probabilmente conoscono il vb.net! Ora ammettiamo una situazione di turnover in un’azienda…pian piano ti ritroverai una base di codice che sarà ingestibile perchè non ci sarà quasi nessuno capace di tenerla. Senza contare la forte incompatibilità dei progetti con gli ide futuri…insomma credo che il passo debba essere fatto.
Sul fatto che la sintassi del basic sia più immediata (altrimenti non si sarebbe chiamato basic) non ci sono dubbi ma è anche vero che è molto più pesante in termini di keywords e grammatica. Le sintassi c-like sono oramai prese come base per una stragrande maggioranza di linguaggi presenti e futuri (vedi c#, java, javascript, php, ecc chi più chi meno) mentre il basic è oramai relegato praticamente al solo vb e qualche compilatore di nicchia per creare giochi tipo darkbasic, ecc.
In sostanza è più facile trovare chi conosce un linguaggio c-like che basic oggigiorno e inoltre sarà più facile, un domani, migrare verso un nuovo linguaggio.
Questa è una mia opinione, ovviamente.
Per il resto concordo con voi.
Ciao ragazzi!
@Daniele, Crick, dubbioso
La cosa che mi spaventa è che molte delle aziende che hanno il loro business basato su vb6 non hanno nessun piano serio di migrazione verso qualcosa di più moderno, e lo dico avendoci lavorato per anni.
Ho visto nascere e morire piani faraonici di migrazione di gestionali da 1 GB da vb6 a .NET. La verità è che le aziende non ne voglio sapere di affrontare i costi di riscrittura del loro software (la riscrittura è di fatto la cosa più sensata) e in molti casi non hanno neppure le competenze tecniche interne per farlo, visto che i loro programmatori “senior” vengono da 10 anni di tecnologia COM.
Quello che temo, anzi ne sono certo, è che continueranno ancora con vb6 e COM per tanti anni, proponendo soluzioni virtualizzate che permettano di far girare queste tecnologie legacy su infrastrutture moderne.
microsoft mette nel calderone tutti gli strumenti di sfiluppo possibili, ma sennuno di questi è di produzione enterprise ossia la maggior parate deglli sviluppatori continuerà ad usare visual c+ o intel c++….per le applicazioni performance mentre bisogna vedere l’aderenza allo standard non ancora rilasciato di html5+javascript….
ormai la babele regna sovrana e nessuno sa effettivamente quale software utilizzare per sviluppare i suoi programmi….
io continuo con il buon vecchio c CHE AD OGGI NON HA MAI TRADITO…per quanto riguarda il resto , html5 come front end per applicazioni client serve ci puo’ sicuramente stare una volta definito e rispettato lo standard dal client…per il resto siamo al paradosso che o si utilizza gnu C che è prediletto da amd…o si utilizza il compilatore intel….tutto il resto è soltanto una grande confusione…..quante volte mi sonno travato a provare un nuogo ilnguaggio ed abbandonareilprogetto per varie ragioni, con il C sono sempre arrivato fino in fondo a volte 6 mesi piu’ tardi ma fino in fondo…..
microsoft oggi porta ancora .net alla ribalda un framework pesante quanto un’intero sistema operativo….
credo che l’era dei framework debba terminare….e l’os debba riprendersi il ruolo che gli spetta…
in un mondo in vui molti primpiangono ancora XP….windows8 sarà un flop totale….
sono anni che non tocco piu’ microsoft…se solo linux avesse un windows manager snello e veloce…..batterebbe tutti senza colpo ferire….
Che dire: come chiromante avresti un futuro. :D
Comunque di WM che soddisfano le tue richieste ne esistono diversi per Linux: basta cercare. E accontentarsi.
L’alternativa a .NET poi quale sarebbe? Perché un paio di giorni fa ho installato le Qt a 32 bit, e mi sono ritrovato con 1,2GB di spazio occupato, di cui la sola cartella bin con più di 500MB e il resto di cianfrusaglie inutili (compresi 250MB di sorgenti; e no, non era l’SDK, ma il runtime che ho installato).
Praticamente poco più di .NET a 32 bit al completo (tutte le versioni, dalla 1.1 alla 4.0).
E quanto a pesantezza le Qt si fanno sentire.
Poi se hai qualche altro esempio di framework completo come .NET o Qt, che non faccia impiegare “soltanto” 6 mesi in più nello sviluppo, non hai che da presentarcelo.
Il C tientelo pure stretto, ma paghi sempre in termini di produttività rispetto ai linguaggi più moderni.
Vattelo a fare in C un web server di un certo spessore, e incrocia le dita che l’azienda non fallisca nel frattempo ad aspettare che tu completi il progetto col tuo fido C che non ti tradisce mai (tranne quando ti manda in segmentation fault nei posti e momenti più inaspettati, o con bug intermittenti che ti fanno disperare per cercare di capire dove diavolo capitano).
@homero: quello che manca a Linux è un IDE decente (soprattutto DEBUGGER) per C/C++, non certo un WM leggero (io mi trovo bene con LXDE).
dove sta scritto che la sintassi c like sia più “naturale” per un programmatore? Forse per un programmatore che ha visto solo c/c++/c#/java ecc..
Sono ormai 10 anni che programmo in c++/c#/vb6/vb.net e la sintassi “prolissa” del vb.net la trovo molto più naturale di quella simbolica e abbreviata dei linguaggi c-like.
Per molte cose preferisco quella vb.net, per altre (lambda expression, linq/plinq e qualcos’altro) il c#
Ma affermare che la sintassi c like sia più naturale per un programmatore dimostra solo di essere enormemente di parte.
Un pò di apertura mentale ed obiettività signori miei, non fate tutti i programmatori c puristi del cavolo.
Mi fate venire in mente un tipo che affermava: “Non capisco a cosa diavolo serva la gui in un SO server, questo windows server (sia parlava del 2008) è sempre più insulso”.
@homero: Dai non puoi dire queste cose. Basta pensarci un pò su.
Ogni linguaggio ha il suo ambito di utilizzo.
Non potrei mai investire tempo, denaro e risorse nello sviluppo di un Web Service in C o in un’applicazione form “bella” per un utenza generica… rischi di metterci anni…
E non oserei mai fare complessi calcoli, elaborazioni pesanti e delicate in C# o con qualche linguaggio non completamente compilato… rischio di attendere svariati ordini di grandezza piu del dovuto.
@Mauro, si è il 90.