asp.net comments edit

Il web.config è sicuramente familiare a tutti noi sviluppatori web, ma ci sono alcuni attributi che valgono la scrittura di un post ad hoc.

Oltre al classico connectionstrings e appsettings, in tutti i file di configurazione per applicazioni web esiste una sezione chiamata “compilation”, che permette di impostare un set di parametri che andranno ad influenzare la compilazione delle nostre pagine web.

Alcuni di questi attributi parlano da soli - inutile spiegare a cosa serve l’attributo debub=”true” - , ma ce ne sono altri che spesso si tralasciano o non si conoscono affatto.

Per esempio recentemente ho scoperto l’esistenza dell’attributo optimizeCompilations che, se impostato su true, può aumentare in maniera significativa i tempi di compilazione delle pagine web (maggiori informazioni qui http://blogs.msdn.com/b/davidebb/archive/2009/04/15/a-new-flag-to-optimize-asp-net-compilation-behavior.aspx).

Anche l’attributo batch ha lo scopo di migliorare le performance di compilazione ma, a differenza dell’attributo optimizeCompilations, questo è impostato di default su true, quindi possiamo omettere questo attributo nel nostro file di configurazione.

Un altro interessante attributo è numRecompilesBeforeAppRestart che, se impostato con dei valori corretti, può evitare alcuni noiosi restart dell’applicativo.

In ogni caso il mio preferito resta l’attributo tempDirectory Smile. Questo attributo permette di specificare la directory dove verranno salvati i file temporanei di compilazione.
Il perché mi piace particolarmente questo attributo è dovuto al fatto che uso un RAM Disk (personalmente uso questo http://memory.dataram.com/products-and-services/software/ramdisk) e, impostando la compilazione dei file di ASP.NET su questo particolare drive, si ottengono delle performance notevoli, specie in fase di startup.

Concludo con un pezzo della mia configurazione :

<compilation tempDirectory="G:\aspnet.temp\" 
                    optimizeCompilations="true" 
                    batch="true" 
                    debug="true" 
                    defaultLanguage="c#" 
                    numRecompilesBeforeAppRestart="250" 
                    targetFramework="4.0">
    <assemblies>
        <add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
    </assemblies>
</compilation>

Ciauz!

asp.net comments edit

Con il mio consueto ritardo (scusate ma è un periodo pienissimo), volevo postare alcuni webcast miei e di Simone Chiaretta riguardanti il mondo del web developer in generale.

Gli argomenti trattati infatti coprono la parte di sviluppo, ma anche argomenti come SQL CE con Entity Framework Code First ed IIS Express.

Come sempre feedback e domande sono i benvenuti, anche in base alle vostre esperienze!

Buona Visione

IIS Express

ASP.NET MVC Razor

ASP.NET MVC 3 - Dependency Injection(DI)

ASP.NET MVC 3 - SQL CE 4

ASP.NET MVC 3 - Le novità

various comments edit

Nonostante lo scherzetto di Google (vedi immagine sotto), anche quest’anno ho ricevuto la mail che mi comunicava il rinnovo dell’Award Microsoft MVP su ASP.NET/IIS.

SNAGHTML35e584a4

Inutile parlare ancora di quanto è un piacere per me far parte di questo gruppo che, oltre ad essere un insieme di professionisti, si sta dimostrando anche un insieme di amici.
Un super grazie al mio lead ed amico Alessandro!

Grazie ancora a tutti.

asp.net comments edit

build_logo_2Nel precedente post avevo elencato le principali novità presentate durante la keynote del primo giorno del //build, conferenza di Microsoft orientata principalmente su Windows 8, ma non solo.

Anche con questo post arrivo in netto ritardo rispetto a molti altri blogger, ma purtroppo non ho avuto modo di vedere la presentazione prima di oggi; quindi eccomi qui a parlare di Azure, MVC4 e Visual Studio 2011, i protagonisti della seconda Keynote.

MetroUI+Azure

La prima demo ha mostrato come lo sviluppo di applicazioni Metro UI non si limiti al semplice HTML+JS o C#, ma è possibile sfruttare le potenzialità del Cloud Computing (Azure nel caso di Microsoft) per creare applicazioni molto più spinte. Nell’esempio è stato mostrato un gioco in cui i due giocatori utilizzavano come device un computer da una parte ed un Windows Phone dall’altra, il tutto in tempo reale. Direi una demo davvero sbalorditiva in quanto apre scenari sicuramente interessanti.

 

image

 

Visual Studio 2011

Già un po’ se ne parlava in rete, però qui viene effettivamente mostrato e le novità sono molte.
In primis i Productivity Power Tools sono integrati nella versione finale di Visual Studio, al contrario di oggi che sono scaricabili come plugin separatamente.
Un’altra interessante feature è il “find matching clones”, che ha lo scopo di trovare blocchi di codice duplicati. Devo dire che questa feature mi incuriosisce veramente tanto: vorrei capire lo scope in cui effettua le ricerche, e di conseguenza capire se si sovrappone ad un qualcosa di molto simile offerto da Resharper.

ASP.NET

Nell’ambito web ci sono veramente tante novità, alcune di notevole interesse, come la possibilità di affiancare del codice Server Side con del codice renderizzato.

image

Funzione sicuramente utile a capire dove stiamo sbagliando nella costruzione del markup.
Altra caratteristica molto importante è la possibilità di effettuare il minify dei file .js e .css, semplicemente aggiungendo come risorsa la folder: come per magia, a runtime verrà creata un'unica risorsa contenente tutti i file presenti all’interno della folder. In questo modo l’unica accortezza che si deve avere è la creazione delle folder in maniera razionale rispetto alle risorse necessarie.

ASP.NET MVC 4 Developer Preview

Come per Visual Studio e Windows, la next release di ASPNET MVC è ricca di novità, a partire dai nuovi template per il mondo mobile (utilizzando jQuery Mobile) e dal supporto per View differenziate semplicemente utilizzando l’estensione .mobile.cshtml.
Un’altra interessante novità è il supporto alla keyword async di C# 5.0 che, tramite degli attributi, risulta facilmente estendibile e configurabile.

Download:

eventi comments edit

build_logoChe il //build fosse una conferenza dalle grandi novità ce lo aspettavamo un po’ tutti, ma che oltre a Windows 8 fossero mostrate tutte le next release dei principali tool e framework mi ha lasciato un po’ spiazzato; talmente spiazzato che questo post esce in ritardo rispetto a molti blogger in quanto ho dovuto metabolizzare tantissime informazioni J.

In ogni caso procediamo con ordine e vediamo tutte le novità lato dev che ci riguardano:

Retrocompatibilità

Steven Sinofsky durante la keynote ha dichiarato che tutte le applicazioni funzionanti in Windows 7 saranno funzionanti anche nella prossima release del sistema operativo. Questo vuol dire che, nonostante le importanti novità che elencherò di seguito, non dobbiamo allarmarci J.

Metro UI, Store ed altre novità

Sicuramente come news principale c’è la nuova Metro UI, ossia una nuova interfaccia inizialmente pensata per il mondo touch, ma poi effettivamente utilizzabile anche da chi come me non ha un device touch. A dimostrazione, il menù start non esiste più e, premendo il pulsate cuore di Windows, si accederà direttamente alla nuova Metro UI, dove è possibile effettuare ricerche o eseguire applicazioni.
Inizialmente questo nuovo comportamento può lasciare l’utente un po’ spiazzato ma poi, una volta abituatisi, risulta molto comodo e pratico.

image

Oltre ad essere molto reattiva, la parte Metro si può “unire” al classico desktop creando così un’ibrido dove, sulla parte sinistra possiamo tenere un’applicazione Metro Style e dall’altra una comunissima applicazione o il desktop stesso. Oltre a ciò è possibile “pinnare” sulla Welcome Page (e quindi la Metro UI) un po’ tutto, da applicazioni Metro a Visual Studio, un po’ come avviene per Windows Phone.

Per quanto riguarda la parte desktop, rimane (per ora) un po’ tutto come prima, ci sono alcune novità ma diciamo pure che l’habitué Windows non si troverà spiazzato.

Oltre alle novità legate alla UI, ne sono state mostrate parecchie altre: lo Store App (non ancora disponibile se si installa Win8), il Sync dei Settings (sfruttando Windows Live si avranno a disposizione le stesse cose per i differenti device, tablet, pc, phone, etc), Hyper-V direttamente nel sistema operativo, mount delle iso (stile Daemon Tool per intenderci), supporto al multi-monitor migliorato, controllo ortografico su tutto il sistema operativo, un minor consumo della ram (circa il 20% in meno rispetto a Windows 7), un avvio in pochi secondi (dai 4 agli 8 a seconda dell’hardware), un nuovo task-manager e, grazie ad una sorta di hibernate delle applicazioni (zero cicli di clock ma l’applicazione rimane aperta) sembra che la durata della batteria sia migliorata.

Sviluppo.

Con Windows 8 è stato introdotto un nuovo stack chiamato Metro Style che, come è facilmente intuibile dal nome, serve a realizzare applicazioni per la UI Metro. Ovviamente, per garantire la retro compatibilità sopra citata, il classico stack Win32/.NET rimane, ma non sarà possibile realizzare un’applicazione che utilizzi entrambi gli stack. Questo vuol dire che se si vogliono coprire entrambi gli scenari, Metro e Win32, è necessario realizzare due applicazioni.

C/C++, XAML, C#, VB, HTML, Javascript

Chi più ne ha più ne metta! Sono questi i Framework/linguaggi che si possono utilizzare oggi per sviluppare applicazioni metro style, e tutti fanno capo ad un “sotto strato” chiamato WinRT (Windows Runtime) che altro non è che un set di API verso il kernel di Windows.
La slide seguente mostra un po’ più nel dettaglio come è strutturato lo sviluppo in Windows 8.

image

Come potete vedere, lo XAML ora non è più parte del .NET Framework ma è presente direttamente nel sistema operativo, offrendone così la possibilità di utilizzo anche da linguaggi unmanaged come il C, o il C++.

Un’altra novità che mi ha colpito in questa slide è l’assenza di Silverlight per lo sviluppo di applicazioni Metro Style, rilegandolo così nell’angolino in basso a destra.

HTML + Javascript


Direi che è il vero protagonista (devside)! Di fatto ha molto più spazio ed importanza rispetto a Silverlight e apre nuove opportunità a tutti gli sviluppatori di frontend (HTML/Javascript). Ad oggi conosco diversi sviluppatori di frontend che, dopo la presentazione di Windows 8, si sono dimostrati interessati a sviluppare applicazioni per Windows.

Quale linguaggio scegliere?


Beh difficile dirlo. In primis lo skill la fa da padrone. Se si è abituati a scrivere solo codice C# (non tutta la BCL è disponibile per le Metro Apps) e non si conosce il Javascript, la risposta vien da sola J.
Personalmente vedo una grande crescita del C++ nello sviluppo di applicazioni Windows e, volendo azzardare un po’, scegliere il Javascript+HTML5 per applicazioni che non necessitano di performance o calcoli troppo complessi, ed il C++ per le applicazioni in cui la velocità è il primo pillar, può essere la scelta giusta.
Un altro vantaggio del C++ e della coppia HTML+JS è la non necessità del .NET Framework. Questo offre vantaggi in fase di deploy e dipendenze.

WinRT

Sopra ho accennato di cosa si tratta, ma è giusto approfondire un po’, riportando alcuni punti scritti da SuperRaf in questo post.

    • È il Windows Runtime che espone le funzionalità del sistema operativo in modo Object Oriented.

    • Non è codice managed e non necessita del .NET Framework. (Javascript, HTML, C e C++ non lo richiedono)

    • Ha delle "Projection" che permettono ai vari linguaggi di interagire con il sistema operativo (C++, C#, VB.Net, Javascript)

    • I linguaggi managed sopra WinRT hanno sempre bisogno del CLR e il Framework fornito con Win8 è la versione 4.5

    • WinRT è costruito con tecnologia COM e conserva tutti i relativi meccanismi (IUnknown, AddRef/Release, Apartment per i modelli di threading, la message pump per gestire le STA).

    • È possibile estenderlo, ma solo per una singola applicazione e quindi non condivisibile.

    • Il versioning di WinRT è basato sui concetti COM e prevede le estensioni che verranno nelle future versioni del sistema operativo

    Domande, dubbi e perplessità:

    • Ma WPF che fine ha fatto?
    • Perché Silverlight è stato escluso dalla parte Metro UI?
    • Il .NET non la fa più da protagonista come prima?

    Un grande passo in avanti e veramente tante novità...non saprei da dove partire! Anzi si, dal download disponibile qui e dalle sessioni qui.

    eventi comments edit

    Per chi come me è in overflow da news tecnologiche, e non vuole perdersi neanche un minuto del Build, ecco gli step da seguire per scaricarsi tutte le sessioni:

    • Creare una folder dove verranno scaricati i video (nell’esempio è chiamata build11);
    • Creare un file .ps1 (downloadall.ps1 nell’esempio) ed editarlo con il notepad incollando il seguente codice:

    cd "C:\build11"
    [Environment]::CurrentDirectory=(Get-Location -PSProvider FileSystem).ProviderPath
    $a = ([xml](new-object net.webclient).downloadstring("http://channel9.msdn.com/Events/BUILD/BUILD2011/RSS/wmvhigh"))
    $a.rss.channel.item | foreach{ 
        $url = New-Object System.Uri($_.enclosure.url)
        $file = $url.Segments[-1]
        $file
        if (!(test-path $file))
        {
            (New-Object System.Net.WebClient).DownloadFile($url, $file)
        }
    }

    • avviare Powershell e digitare Set-ExecutionPolicy unrestricted (necessario all’esecuzione dello script);
    • avviare lo script da powershell c:\build11\downloadall.ps1

     

    Il tutto è basato su questo post che si appoggia a sua volta in un post di Scott Hanselman.

    Buon download.

    various comments edit

    È sicuramente una domanda che ci siamo fatti in molti e sfortunatamente solo pochi avranno la possibilità di darci un’occhiata da vicino.

    Dove non si può arrivare fisicamente c’è internet Smile

    Buona visione.

    asp.net comments edit

    Come era facilmente intuibile da uno dei miei ultimi post, ultimamente sto lavorando ad un’applicazione “hostata” su Windows Azure. Oltre ai “problemi” di continuous deployment descritti qui, ho riscontrato un altro piccolo problema riguardante la configurazione di IIS.
    IIS ha un’interessante configurazione (idle timeout) nata allo scopo di ridurre al minimo le risorse utilizzate dalle applicazioni web; tale configurazione consiste nello “spegnere” un sito web, nel caso non vi siano richieste da parte di utenti per un tempo di 20 minuti.

    Questo valore è ovviamente configurabile dalla console di IIS e lo si può ridurre, aumentare o addirittura disabilitare. Nel caso ci si trovi nell’ambito di un’installazione locale, è sufficiente cambiare la configurazione dell’application pool che “hosterà” il nostro sito web.

    Ma se ci si trova in Windows Azure?

    In Azure non è possibile accedere in terminal server alla macchina contenente il nostro sito e cambiare l’Idle Timeout. Esiste però un escamotage che abilita tale accesso al server sul cloud; tale “hack” risulterebbe in ogni caso inutile, in quanto al riavvio della macchina virtuale (ma anche alla creazione di una nuova istanza) sarebbe necessario reimpostare di nuovo il valore, obbligandoci così a collegarci nuovamente in terminal server.

    Fortunatamente all’interno del package di Azure possiamo definire dei task di avvio, che verranno eseguiti ad ogni riavvio della macchina virtuale (o alla creazione di una nuova istanza). All’interno di questi task possiamo eseguire applicazioni, comandi DOS e quant’altro possa servirci per far funzionare la nostra applicazione.

    In questo post Steve Marx spiega come eseguire dei task e, proprio in questo esempio, mostra come cambiare il timeout di default di IIS.

    Per prima cosa è necessario modificare il file ServiceDefinition.csdef ed inserire il seguente codice:

    <Startup>
        <Task commandLine="Tasks\startup.cmd" executionContext="elevated" taskType="simple" />
    </Startup>

    Per questo esempio il task type sarà di tipo simple, ma in un futuro post vedremo le differenti tipologie ed eventuali scenari di utilizzo.

    Da qui in poi è sufficiente creare un file .cmd con all’interno il comando DOS per per disabilitare il timeout di IIS, come mostrato di seguito.

    %windir%\system32\inetsrv\appcmd set config -section:applicationPools
        -applicationPoolDefaults.processModel.idleTimeout:00:00:00

    A questo punto l’applicazione hostata in Azure sarà sempre reattiva, anche in caso di poco traffico (molto comodo in fase di testing).
    Ciauz

    web dev comments edit

    È già da diverso tempo - almeno un anno - che mi chiedo come sia possibile gestire (magari tramite il markup) le varie sezioni che Google propone per alcuni siti a fronte di una ricerca. Vuoi per pigrizia, vuoi per mancanza di tempo, non ho mai indagato fino a pochi giorni fa, quando ho scoperto che non è possibile gestire tali sezioni J.

    Lo screenshot seguente mostra meglio cosa intendo io per “sezioni”, che Google chiama Sitelinks:

    SNAGHTML8417eda

    Questa frase “At the moment, sitelinks are automated.” mi toglie tutte le speranze di poter organizzare i Sitelinks a mio piacimento, salvo che per un aspetto: rimuovere due brutti ceffi (mimì e cocò) dal risultato della ricerca per il mio dominio :D.
    Come tutti i sistemi automatici, anche quelli fatti da Google possono sbagliare; fortunatamente BigG (soprannome di Google) offre la possibilità di segnalare possibili malfunzionamenti.

    Accedendo al pannello di controllo per i webmaster (qui), è possibile specificare i link da rimuovere tra i SiteLinks per specifiche ricerche.

    Ora mi aspetto che, entro 90 giorni, le due brutte persone dovrebbero sparire dai miei Sitelinks.

    asp.net comments edit

    Ultimamente sto lavorando parecchio per migrare un’applicazione MVC3 su Azure. Una delle cose che trovo più noiose in Azure è il dover ricreare il package di deploy per ogni singola modifica; questo vuol dire che se si vuole cambiare un testo in una View occorre rifare il package e ripubblicarlo.
    Devo dire che, lato Azure, è più che comprensibile come comportamento. Essendo questo basato su macchine virtuali, nel momento in cui una di queste “cade” o l’utente ha la necessità di aumentare la forza lavoro, l’infrastruttura di Azure non fa altro che caricare una nuova macchina virtuale e deployare il package all’interno, perdendo però un’eventuale modifica fatta su un file (come la View dell’esempio precedente).

    Proprio per questo motivo, tutto ciò che necessita di essere modificato frequentemente e deve essere accessibile da tutte le istanze attive di Azure dovrebbe risiedere nel blob storage.

    Dato che il progetto a cui sto lavorando è in continua evoluzione, e le view cambiano più è più volte nell’arco di una giornata, ho deciso di far “pescare” le View ad MVC direttamente dal blob storage di Azure e non dal filesystem della macchina virtuale, evitando così la scomodità di dover “rideployare” continuamente l’applicazione.

    Con questo scenario il vantaggio è notevole, posso caricare un singolo file della View in pochi secondi con un qualsiasi tool (io personalmente uso Cerebrata Cloud Storage Studio, ma ne esistono molti altri gratuiti come questo).

    Fortunatamente tutto questo è facilmente implementabile, senza dover modificare la nostra applicazione. Di fatto ci basta registrare un nostro VirtualPathProvider all’interno del Global.asax.cs ed il gioco è fatto.

    Proviamo a dare un’occhiata al codice:

    using System;
    using System.Collections;
    using System.Web.Caching;
    using System.Web.Hosting;
    using Dexter.Storage;
    
    namespace Dexter.Web.Mvc.ViewEngines {
        public class DexterVirtualPathProvider : VirtualPathProvider {
            readonly IStorageProvider storageProvider;
    
            public DexterVirtualPathProvider ( IStorageProvider storageProvider ) {
                this.storageProvider = storageProvider;
            }
    
            public override bool FileExists ( string virtualPath ) {
                var fullPath = storageProvider.GetPublicUrl ( virtualPath );
    
                if (storageProvider.FileExist ( fullPath ))
                    return true;
    
                return Previous.FileExists ( virtualPath ); 
            }
    
            public override VirtualFile GetFile ( string virtualPath ) {
                var fullPath = storageProvider.GetPublicUrl ( virtualPath );
    
                if (storageProvider.FileExist ( fullPath ))
                    return new DexterVirtualFile ( virtualPath, storageProvider );
    
                return Previous.GetFile ( virtualPath ); 
            }
    
            public override CacheDependency GetCacheDependency ( string virtualPath , IEnumerable virtualPathDependencies , DateTime utcStart ) {
                return null;
            }
        }
    
        public class DexterVirtualFile : VirtualFile {
            readonly IStorageProvider storageProvider;
    
            public DexterVirtualFile ( string virtualPath , IStorageProvider storageProvider ) : base ( virtualPath ) {
                this.storageProvider = storageProvider;
            }
    
            public override Stream Open ( ) {
                var fullPath = storageProvider.GetPublicUrl ( VirtualPath );
                return storageProvider.GetFile ( fullPath ).OpenRead ( );
            }
        }
    
    }

     

    Ovviamente in questo codice non c’è nessuna reference verso Azure, ma l’implementazione di IStorageProvider si occupa di accedere al blob del could. La cosa carina di quest’implementazione è che permette di “manipolare” il path delle view in un unico punto con un effort molto basso.

    La registrazione sulla nostra HttpApplication avviene in questo modo:

    public void ApplicationStart ( ) {
        //....
        System.Web.Hosting.HostingEnvironment.RegisterVirtualPathProvider ( new DexterVirtualPathProvider(azureStorageProvider) );
    }

    Da questo momento in poi le view verranno lette direttamente dal blob storage.