[section label=\"ASP.NET ed IIS\"] ASP.NET ed IIS<\/h3>\r\nA prima vista questa modifica potrebbe sembrare ininfluente ma segna un cambiamento piuttosto importante se si\u00a0considera che\u00a0sin dalla sua introduzione con IIS 6 e Windows Server 2003, ASP.NET\u00a0\u00e8 stata eseguita da IIS come ISAPI, la configurazione che garantiva le prestazioni migliori sulla piattaforma. Lo stesso avveniva ed avviene per altre tecnologie come ASP classico mentre storicamente altri framework o estensioni provenienti dal mondo Unix usavano invece una tecnologia meno sofisticata a cui si fa riferimento in generale come CGI.\r\n\r\nLe perplessit\u00e0 potrebbero sorgere proprio perch\u00e9 da sempre l'esecuzione ISAPI \u00e8 considerata la pi\u00f9 efficiente e quella capace di fornire prestazioni di molto pi\u00f9 elevate sulla piattaforma Windows Server, soprattutto perch\u00e9 la creazione di nuovi processi \u00e8 in effetti una operazione onerosa sui sistemi Windows, molto pi\u00f9 di quanto lo sia sui sistemi Unix.\r\n\r\nIn realt\u00e0 sin da Windows Server 2003 Microsoft ha affinato il supporto per le tecnologie CGI, in particolare per garantire la compatibilit\u00e0 con framework molto popolari come PHP. La tecnologia FastCGI<\/em> \u00e8 in effetti l'antesignana del modulo HTTPPlatformHandler<\/em> e, sebbene con FastCGI la piattaforma Windows Server abbia efficacemente ottenuto l'esecuzione di framework come PHP con prestazioni pari o addirittura superiori a quelle dei sistemi Unix, fino a poco tempo fa era considerato impossibile che Microsoft decidesse di passare ad una modalit\u00e0 di esecuzione diversa per le proprie tecnologie.\r\n

[section label=\"HTTPPlatformHandler : l'evoluzione della specie\"] HTTPPlatformHandler : l'evoluzione della specie<\/h3>\r\nLa notizia non pu\u00f2 che significare che Microsoft ha ormai ottenuto una parit\u00e0 di performance tra l'esecuzione ISAPI e quella CGI e la chiave \u00e8 senza dubbio il modulo HTTPPlatformHandler<\/em>. Anticipando le perplessit\u00e0 di qualcuno, Edwards aggiunge che Microsoft si aspetta una differenza di prestazioni tra le due modalit\u00e0 solo per applicazioni triviali come una Hello World<\/em>, cio\u00e8 piccole applicazioni che fungono pi\u00f9 da esempio che da reali implementazioni. Per tutti gli altri casi, probabilmente Microsoft crede di raggiungere prestazioni uguali o anche maggiori a quelle ottenibili con la tecnologia ISAPI. Certamente cos\u00ec facendo ottiene una flessibilit\u00e0 notevolmente maggiore, soprattutto in un contesto nel quale ASP.NET \u00e8 diventato open-source ed in teoria qualsiasi utente potrebbe compilare la propria versione della tecnologia.\r\n\r\nIl modulo HTTPPlatformHandler<\/em> \u00e8 l'evoluzione\u00a0di quello\u00a0FastCGI<\/em> che ha consentito a Windows Server di diventare una piattaforma ideale anche per PHP a partire dalla versione 2003 e da IIS 6. FastCGI risolve il problema dell'onerosit\u00e0 della creazione di nuovi processi con l'attivazione di una singola istanza che verr\u00e0 usata in modo efficace da IIS per gestire un numero variabile di richieste, isolandole da quelle degli altri siti Web ma gestendole sempre con un processo unico. Di tanto in tanto, in modo configurabile, IIS disattiva poi questa istanza comune per attivarne un'altra, evitando che i problemi di tecnologie come PHP che funzionano efficacemente solo in modalit\u00e0 CGI possano poi intaccare il funzionamento del Web Server. La chiusura del processo consente di azzerare qualsiasi problema l'interprete CGI possa avere e ripartire da una situazione inziale, risolvendo il problema dell'instabilit\u00e0 che tecnologie come PHP potevano portare a server come IIS.\r\n\r\nIl modulo HTTPPlatformHandler<\/em> \u00e8 stato pubblicato da Microsoft solo all'inizio dell'anno e rappresenta il perfezionamento di FastCGI<\/em>. Al contrario di quest'ultimo, utilizzabile a fini pratici quasi esclusivamente con PHP, HTTPPlatformHandler<\/em> nasce per fornire alla piattaforma Windows Server la possibilit\u00e0 di utilizzare tutti i framework a linea di comando. Microsoft ha creato questa tecnologia per utilizzare su Azure<\/em> tecnologie come Java<\/em>, Ruby on Rails <\/em>(RoR), Python<\/em> e molte altre. Per farlo serviva un modulo pi\u00f9 generico di FastCGI, qualcosa che fosse adattabile a qualsiasi framework ed il nuovo modulo risolve perfettamente il problema, consentendo di eseguire in modo efficace praticamente qualsiasi framework a linea di comando, mantenendo alte le prestazioni per poter fornire una reale alternativa a piattaforme come Linux.\r\n\r\nIl modulo viene utilizzato con successo su Azure ed \u00e8 stato integrato anche da molti altri service provider per consentire l'esecuzione di Java e RoR su piattaforma Windows Server. Si tratta quindi di una tecnologia che, sebbene abbia pochi mesi di vita,\u00a0ha gi\u00e0 provato di poter\u00a0fornire alte prestazioni.\r\n

[section label=\"Addio Helios, soluzione di breve durata\"]\u00a0Addio Helios, soluzione di geniale ma senza futuro<\/h3>\r\nParleremo pi\u00f9 avanti degli obiettivi della nuova versione di ASP.NET ma soffermiamoci prima su una tecnologia di collegamento che Microsoft aveva sviluppato per la nuova versione, la tecnologia che consentiva alla nuova versione di essere eseguita al posto della precedente senza danneggiare la compatibilit\u00e0 della piattaforma. Si chiama Helios<\/em>, ed \u00e8 sostanzialmente un hook con cui Microsoft consentiva alle applicazioni ASP.NET 5 di prendere il posto del framework 4.5 e 4.6 senza dover installare nulla sul server. Questa soluzione, decisamente geniale, consentiva di \"delegare\" l'esecuzione della richiesta corrente ad un runtime diverso, in particolare le versioni beta di ASP.NET 5 che negli scorsi mesi sono state fornite come pacchetto completo, con la possibilit\u00e0 quindi di usarle side-by-side<\/em>. Helios consente quindi di cambiare completamente la pipeline di ASP.NET, eliminando la famosa System.Web<\/em> e sostituendola con quella nuova, gestendo autonomamente l'esecuzione della richiesta da quel momento in poi.\r\n\r\nNon sappiamo se dal punto di vista della sicurezza l'uso di Helios avrebbe complicato le cose, anche se \u00e8 improbabile visto che ASP.NET 5 avrebbe comunque girato nel contesto del processo chiamante, ad ogni modo il team di ASP.NET ha deciso di passare ad una modalit\u00e0 di esecuzione del tipo CGI basata su Kestrel, <\/em>il server Web open-source usato in molti esempi per ASP.NET 5 e riconoscibile con il file dnx.exe. <\/em>Probabilmente questa scelta dipende anche dal fatto che utilizzare una singola modalit\u00e0 di attivazione consentir\u00e0 di unificare lo sviluppo sia per Windows che per gli altri sistemi su cui ASP.NET 5 potr\u00e0 essere eseguita e cio\u00e8 Linux e MacOS. Inoltre, \u00e8 indubbio che l'uso di una applicazione CGI alla quale IIS sostanzialmente girer\u00e0 la gestione della richiesta consenta maggiori possibilit\u00e0 di configurazione da parte dell'utente che pu\u00f2 decidere di utilizzare anche configurazioni diverse per applicazioni diverse, decidere quali informazioni passare alle singole richieste, modificare o sostituire il runtime in ogni momento e cos\u00ec via.\r\n\r\nDa questo punto di vista i gateway CGI si sono dimostrati molto flessibili ma come succede per PHP, la possibilit\u00e0 di introdurre variazioni o personalizzazioni all'interno dei componenti principali della tecnologia rischia di frammentarla, introdurre incompatibilit\u00e0 e rendere in generale tutto pi\u00f9 instabile. Su ASP.NET gli sviluppatori sono sempre stati abituati al fatto che ci fosse un runtime di base e poi eventuali personalizzazioni ad un livello pi\u00f9 alto. Oggi corriamo il rischio che \"la mia ASP.NET non sia pi\u00f9 la tua ASP.NET\", anche se indubbiamente molti utenti avanzati si gioveranno delle possibilit\u00e0 di personalizzazione, addirittura di ricompilazione autonoma della tecnologia.\r\n\r\nMeno preoccupante la situazione dal lato prestazioni perch\u00e9 \u00e8 evidente che se il team ha scelto di usare HTTPPlatformHandler<\/em>, le prestazioni del modulo consentiranno di eguagliare, se non superare in futuro, quelle della ISAPI.\r\n\r\nCi chiediamo a questo punto se IIS non vada verso una evoluzione nella quale diventer\u00e0 un semplice forwarder di richieste, un proxy un po'\u00a0come nginx, <\/em>pi\u00f9 che rimanere un Web Server a tutto tondo. E' probabile che nelle prossime versioni di Windows Server IIS possa essere sostituito da un proxy pi\u00f9 snello oppure addirittura Nginx<\/em> stesso, visto che Microsoft ha dimostrato di poter integrare tecnologie diverse, se lo riteneva utile, lasciando magari al vecchio Web Server il compito di gestire la compatibilit\u00e0 con i vecchi stadard, ad esempio l'autenticazione di Windows.\r\n\r\nA questo proposito, Edwards ha dichiarato che una delle modifiche che HTTPPlatformHandler introdurr\u00e0 con la nuova versione \u00e8 proprio il supporto per l'autenticazione di Windows, che sar\u00e0 necessario indirizzare al processo di gestione di ASP.NET, essendo ora quest'ultimo esterno al processo di IIS.\r\n

[section label=\"Cosa aspettarsi da ASP.NET 5\"] Cosa aspettarsi da ASP.NET 5<\/h3>\r\nArticoli su ASP.NET 5 compariranno spesso su The Server-Side Technology<\/em> da qui in avanti, soprattutto in concomitanza con il rilascio della versione definitiva prevista per il primo trimestre del prossimo anno. Un breve accenno per\u00f2 sulle novit\u00e0 di ASP.NET va fatto, come antipasto a ci\u00f2 di cui parleremo nei prossimi mesi.\r\n\r\nE' intanto singolare che Microsoft abbia sostanzialmente separato i cicli di rilascio del framework .NET e di ASP.NET visto che fino ad adesso le due componenti sono sempre andate di pari passo. Con Visual Studio 2015 \u00e8 stato invece rilasciato il framework .NET 4.6 e la beta di ASP.NET 5. Anche la non corrispondenza della numerazione (v4.6 contro v5 e nessun dettaglio sul .NET framework v5) sono particolari ma riflettono il cambio di rotta introdotto con la decisione di far diventare .NET e ASP.NET open-source.\r\n\r\nCon ASP.NET 5 Microsoft cambia completamente l'organizzazione di ASP.NET, distanziandosi dal modello introdotto nel 2003 con la v1.0 per creare un runtime che dia pi\u00f9 controllo allo sviluppatore. Come abbiamo accennato in precedenza, sparisce la vecchia pipeline basata su System.Web e sulla quale, incrementalmente, Microsoft aveva poi costruito tutte le altre tecnologie di ASP.NET, a vantaggio di un runtime la cui configurazione \u00e8 completamente personalizzabile attraverso l'inserimento dei diversi moduli in modo esplicito. L'obiettivo di questa modifica \u00e8 piuttosto evidente: consentire agli sviluppatori di lavorare solo con i moduli \/ servizi \/ tecnologie \/ estensioni di cui hanno bisogno per la propria applicazione, velocizzando l'esecuzione del codice grazie all'assenza di tutta quella parte del framework che non \u00e8 necessaria per l'utente. ASP.NET (e .NET in generale) consentono gi\u00e0 la distribuzione solo delle librerie usate ma questo avveniva per le estensioni al framework principale. Con ASP.NET 5 il runtime caricher\u00e0 solo le componenti necessarie per l'applicazione in esecuzione.\r\n\r\nAlcune tecnologie, come la tanto vituperata WebForms<\/em> che godeva in modo immeritato davvero di cattiva stampa, spariscono del tutto e rimarranno disponibili solo nelle versioni legacy come ASP.NET 4.5. In generale tutta l'organizzazione delle applicazioni cambia, con l'introduzione di file di configurazione basati principalmente su JSON (anche se XML continuer\u00e0 ad essere supportato), una pi\u00f9 chiara separazione dei file di configurazione in modo da rendere dichiarative e configurabili molte delle funzionalit\u00e0 relative al funzionamento dell'applicazione. Inoltre, ci sar\u00e0 una pi\u00f9 netta separazione tra gli asset necessari per l'esecuzione Web (come immagini, CSS etc.) e la parte di codice, isolando i primi nella classica cartella wwwroot<\/em> ma portando al suo esterno gli altri file. Con l'introduzione del supporto per Kestrel anche con IIS, sparir\u00e0 anche il vecchio file web.config<\/em>, non pi\u00f9 necessario.\r\n\r\nAccanto a nuget<\/em>, troveremo poi l'integrazione con altre tecnologie come bower<\/em> e gulp <\/em>ed in generale tutta la parte di configurazione ed esecuzione dell'applicazione sar\u00e0 dipendente da impostazioni gestite dallo sviluppatore piuttosto che da quelle definite a livello di amministrazione di sistema. Questo dar\u00e0 pi\u00f9 controllo agli sviluppatori e li metter\u00e0 meno in conflitto con i sysadmin<\/em>.\r\n\r\nDel resto, la stessa possibilit\u00e0 di usare un proprio runtime consente di ridurre le incompatibilit\u00e0 ed assicurare che ci\u00f2 che lo sviluppatore\u00a0crea sulla propria macchina sia poi al 100% compatibile con l'applicazione pubblicata sul server di destinazione.\r\n\r\nCi sono molte altre novit\u00e0 che fanno parte di ASP.NET 5, tra cui la possibilit\u00e0 di usare quel sottoinsieme del framework .NET chiamato CoreCLR<\/em> che consente di assicurare la compatibilit\u00e0 con sistemi Linux e MacOS, ma avremo modo di parlare di queste novit\u00e0 in futuro.\r\n\r\nNel frattempo vi segnalo che potete gi\u00e0 usare ASP.NET 5 (fino alla beta7) con uno dei pacchetti di cloud hosting offerti da VaiSulWeb<\/a>. Non fatevi quindi sfuggire l'occasione per provare la nuova tecnologia ed iniziare a progettare le vostre applicazioni di nuova generazione.","_en_post_name":"asp-net-5-verra-eseguito-su-iis-attraverso-il-modulo-httpplatformhandler","_en_post_excerpt":"","_en_post_title":"ASP.NET 5 verr\u00e0 eseguito su IIS attraverso il modulo HTTPPlatformHandler","_it_post_content":"","_it_post_name":"","_it_post_excerpt":"","_it_post_title":"","edit_language":"it"},"categories":[91],"tags":[114,164,172,170,173,166,171,169,131,165,104,174,167,168,115],"_links":{"self":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts\/608"}],"collection":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/comments?post=608"}],"version-history":[{"count":19,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts\/608\/revisions"}],"predecessor-version":[{"id":629,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts\/608\/revisions\/629"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/media\/610"}],"wp:attachment":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/media?parent=608"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/categories?post=608"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/tags?post=608"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}