asp.net comments edit

L’altro giorno mi è stato chiesto se era possibile configurare il routing di ASP.NET MVC tramite file di configurazione. Purtroppo al momento non ho saputo rispondere ma, dopo una breve ricerca su internet, ho trovato un articolo che spiega come crearsi una custom section nel file di configurazione, permettendo così di cambiare le regole di routing senza dover necessariamente ricompilare l’applicazione.

Il post è disponibile qui.
Inoltre  Phil Haack tempo fa, ha proposto una soluzione alternativa che sfrutta IronRuby per cambiare il routing.

Ciauz

asp.net comments edit

Con l’uscita di Windows Vista e Windows Server 2008 è stata introdotta la WAS (Windows Activation Service), che permette di “hostare” su IIS (Internet Information Services) servizi WCF anche per protocolli differenti dal tradizionale SOAP (basicHttpBinding e HttpBinding).
Precedentemente a queste versioni di sistema operativo era necessario realizzare un servizio Windows che “hostasse” il servizio WCF, complicando così tutta la procedura di deploy.
IIS7, con la WAS, abbatte totalmente i problemi legati al rilascio e manutenzione dei servizi in quanto è sufficiente copiare la singola assembly del servizio all’interno del nostro sito web o modificare la sua configurazione e sarà lui ad occuparsi di tutto il resto.

Sia in Windows Vista che in Windows Server 2008 la WAS non è presente di default: va quindi installata a mano nell’apposita sezione “Programs and Features”, come mostrato dagli screenshots seguenti:

8-1-2009 3-29-19 PM 8-1-2009 3-31-56 PM 8-1-2009 3-33-15 PM

Una volta completata la procedura di installazione verrà automaticamente configurato il DefaultSite per supportare i protocolli non-http, quindi NET.TCP, NET.PIPE e NET.MSMQ.

A dimostrazione di quanto appena detto, se si prova ad editare a mano il file XML contenente la configurazione di IIS7 (%windir%\System32\inetsrv\config\applicationHost.config) e si controlla l’apposita area del Default Site, si dovrebbe avere una configurazione come la seguente:

<site name="Default Web Site" id="1" serverAutoStart="true">
    <application path="/WCFService" applicationPool="DefaultAppPool" enabledProtocols="http,net.tcp,net.pipe,net.msmq">
        <virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\WCFService" />     
    </application>

    <bindings>
        <binding protocol="https" bindingInformation="*:443:" />
        <binding protocol="http" bindingInformation="*:80:" />
        <binding protocol="net.pipe" bindingInformation="*" />
        <binding protocol="net.msmq" bindingInformation="localhost" />
        <binding protocol="net.tcp" bindingInformation="808:*" />
    </bindings>
</site> 

Nel caso la configurazione non coincida con quella appena mostrata, è possibile eseguire manualmente il comando di configurazione ed abilitazione per i nostri siti web.
Di seguito potete trovare l’elenco dei comandi disponibile per i protocolli non-HTTP:

%windir%\system32\inetsrv\appcmd.exe set site "Default Web Site" -+bindings.[protocol='net.pipe',bindingInformation='*']

%windir%\system32\inetsrv\appcmd.exe set site "Default Web Site" -+bindings.[protocol='net.tcp',bindingInformation='808:*']

%windir%\system32\inetsrv\appcmd.exe set site "Default Web Site" -+bindings.[protocol='net.msmq',bindingInformation='localhost']

%windir%\system32\inetsrv\appcmd.exe set site "Default Web Site" -+bindings.[protocol='msmq.formatname"',bindingInformation='localhost']

Una volta completata la configurazione, è necessario abilitare i protocolli per tutte le applicazioni che necessitano di hostare WCF in modalità non-HTTP.
Il comando seguente mostra come fare:

%windir%\system32\inetsrv\appcmd.exe set app "Default Web Site/MyVirtual" /enabledProtocols:http,net.pipe, net.tcp, net.msmq

A questo punto da Visual Studio, per aggiungere il servizio net.tcp hostato in IIS basta aggiungere l’indirizzo del file .svc presente nel web server ed il gioco è fatto, come mostrato di seguito:

8-3-2009 9-12-37 PM

Anche se si specifica un indirizzo http, questo non vuol dire che il servizio viene esposto in http o il proxy punta ad un binding http, ma sarà direttamente IIS a comunicare al client il protocollo utilizzato.

asp.net comments edit

Quando si costruiscono url dinamici in base a delle variabili di applicazione, è bene utilizzare l’apposito metodo UrlEncode della classe statica HttpUtility, che ha il compito di effettuare il replace di tutti i caratteri non compatibili con gli url.

Per esempio l’url seguente http://imperugo.tostring.it/Categories/Archive/Windows Communication Foundation dovrebbe diventare http://imperugo.tostring.it/Categories/Archive/Windows+Communication+Foundation
Di fatto HttpUtility.UrlEncode("Windows Communication Foundation") sostituisce lo spazio con il carattere “+”.

Quando la propria applicazione risiede su un web server come IIS7.x (Windows Vista, Windows Server 2008, Windows 7, Windows Server 3008 R2) si possono riscontrare dei problemi con questo tipo di url in quanto per default sono bloccati tutti gli url contenenti più di un carattere di escape - nel nostro esempio il “+” - sollevando un’eccezione come la seguente:

HTTP Error 404.11 - Not Found
The request filtering module is configured to deny a request that contains a double escape sequence.

Per disabilitare questa protezione e poter sfruttare l’urlEncode è necessario agire sulla configurazione di IIS nell’apposito file di configurazione (%windir%\System32\inetsrv\config\applicationHost.config) o nell’apposita sezione del web.config dell’applicazione come mostrato di seguito

<system.webServer>
  <security>
      <requestFiltering allowDoubleEscaping="true" />
  </security>
  <!-- ..... --> 
</system.webServer>

In questo modo non si avranno eccezioni per tutti gli url contenenti caratteri di escape.

asp.net comments edit

Da oggi è disponibile la Preview 1 della prossima versione di ASP.NET MVC, il cui download è disponibile qui.

Nel Release Notes sono elencate le numerose novità che sono state introdotte, come i Templated Helpers, le Areas, HttpPostAttribute, DataAnnotations.

Anche nella Roadmap, che trovate qui, sono state elencate alcune delle novità che saranno presenti nella Preview 2 di ASP.NET MVC disponibili insieme alla Beta 2 di Visual Studio 2010.
Tra queste novità troviamo i Client Validation, Strongly-typed input helpers, Strongly-typed link helpers e le Asynchronous Controller Actions.

Maggiori info sono disponibili qui, mentre di seguiti potete trovare un video su questa prima preview del PM di ASP.NET MVC Phil Haack.

continue...

asp.net comments edit

Da poche settimane è stata rilasciata la versione 3.0 della libreria Microsoft Anti-Cross Site Scripting, che introduce numerose novità.
Per chi non la conoscesse, si tratta di una libreria che facilita l’utente nella prevenzione di attacchi di tipo XSS (Cross Site Scripting) alle proprie applicazioni web.

Nello specifico questa libreria è composta da una serie di metodi come l’HtmlEncode, UrlEncode, JavascriptEncode, ecc, che offrono un controllo maggiore sulle stringhe rispetto agli analoghi metodi presenti nel .NET Framework.

Maggiori informazioni sono presenti sul blog del Team qui, il download è invece disponibile direttamente sul sito Microsoft qui, mentre sotto potete trovare un video che ne descrive le nuove funzionalità.

continue...

.net comments edit

Il Throttling è quella parte di configurazione di Windows Communication Foundation che permette di impostare l’impatto che il servizio WCF avrà verso il sitema operativo. Nello specifico è possibile modificare i valori dei parametri MaxConcurrentSessions, MaxConcurrentCalls  e MaxConcurrentInstances.
Nelle versioni antecedenti alla 4.0 i valori di default erano i seguenti:

  • MaxConcurrentSessions (default: 10);
  • MaxConcurrentCalls (default: 16);
  • MaxConcurrentInstances (default: 26);

Purtroppo questi valori possono non essere adeguati a molte realtà applicative, obbligando così l’utente a modificarli per evitare che alcuni client vadano in errore o non riescano a connettersi verso il servizio.
Sfortunatamente, per un utente normale non è facile capire il problema se non attivando il Trace di WCF che, superato il limite impostato di default, logga un’apposita eccezione che ne permette l’individuazione.

Come già detto qui, uno degli obiettivi di Microsoft per Windows Communication Foundation è di ridurre il più possibile la parte di configurazione per i servizi WCF e, proprio per questo motivo, la casa ha deciso di aumentare i sopracitati valori di default già dalla prossima release, come mostrato nell’elenco seguente:

  • MaxConcurrentSessions (default: 100 * ProcessorCount);
  • MaxConcurrentCalls (default: 16 * ProcessorCount);
  • MaxConcurrentInstances (default: è il totale del MaxConcurrentSessione e MaxConcurrentCalls);

Per maggiori informazioni rimando a questo post.

silverlight comments edit

Brad Abrams è l’autore di una serie di articoli interessantimi sui .NET RIA Services e SilverLight.
Di seguito riporto una specie di “percorso formativo” su l’uso combinato di queste due tecnologie; infatti si parte da un’articolo introduttivo che spiega cosa sono i .NET RIA Services, fino ad arrivare ad una vera e propria applicazione sviluppata in Silverlight 3 e RIA Services, con tanto di codice scaricabile.

Di seguito gli articoli:

Ciauz

.net comments edit

Su Channel9 è presente un interessantissimo video che introduce l’Historical Debugger di Visual Studio 2010.

IMHO è una delle feature più interessanti della prossima release del tool Microsoft dedicato agli sviluppatori.

Di seguito trovate il video.

continue...

asp.net comments edit

Nello sviluppare Dexter ho avuto diversi problemi con la cache che, per cause non mie, non ne voleva sapere di andare, al contrario di quello che succede nell’ambiente di sviluppo dove funziona alla grande.

Nello specifico il problema consiste nel fatto che, spesso, gli oggetti inseriti precedentemente in cache risultano nulli, venendo quindi rimossi.

I motivi per cui un oggetto può essere rimosso dalla cache sono decisamente pochi:

  • rimozione manuale tramite codice;
  • Shoutdown causa riciclo o crash del worlprocess;
  • fine della memoria disponibile.

Dato che sono certo di non aver svuotato la cache via codice J, la ricerca del problema si è subito spostata sulla seconda ipotesi, e mi son messo a loggare lo shoutdown lato applicativo, non avendo accesso al server.

Sfortunatamente questa non è cosa semplice perchè non è detto che il WorkProcess non venga “killato” manualmente sul server, oppure che un’altra applicazione presente all’interno dello stesso application pool non provochi un’eccezione che termini il processo.

ScottGu, nel suo blog, propone una possibile soluzione che consiste nell’invocare via reflection i metodi _shutDownMessage e _shutDownStack, che forniscono tutte le informazioni per capire il motivo che ha scatenato lo shoutdown, come mostrato di seguito.

public void Application_End()
{

    HttpRuntime runtime = (HttpRuntime)typeof(System.Web.HttpRuntime).InvokeMember("_theRuntime",BindingFlags.NonPublic| BindingFlags.Static| BindingFlags.GetField,null,null,null);

    if (runtime == null)
        return;

    string shutDownMessage = (string)runtime.GetType().InvokeMember("_shutDownMessage",BindingFlags.NonPublic| BindingFlags.Instance| BindingFlags.GetField,null,runtime,null);

    string shutDownStack = (string)runtime.GetType().InvokeMember("_shutDownStack",BindingFlags.NonPublic| BindingFlags.Instance| BindingFlags.GetField,null,runtime,null);
    
    Logger.Error(shutDownMessage, shutDownStack);
}

Maggiori info le trovate qui.