Syntax check for PHP and JavaScript inside Vim

Many development tools such as Visual Studio or Eclipse have a feature to automatically detect syntax errors when writing code.

This feature is also available inside Vim using a very good plugin called syntastic (it is provided by the same author of another great plugin called The NERD Tree).
This plugin makes it possible to detect syntax and style errors of a wide range of programming languages and it highlights the affected rows of code.

In this article I will explain how to install syntastic and how to enable the syntax check for PHP and JavaScript in a Windows environment.
If you are working on a Linux or a Mac you should still be able to follow and adapt the various steps.

About Vim

This article assumes that you already know Vim's fundamentals and you are able to install a plugin.
If you would like to know more about Vim, a very good and powerful open-source editor, you can find a lot of online tutorials, for example:

• http://vim.wikia.com/wiki/Tutorial (a wiki entirely devoted to Vim)
• http://vimcasts.org/ (a series of videos about Vim)
• http://www.vim.org/ (the official site where you can download the program)

If you prefer a book to learn or know more about Vim I highly recommend a manual called Practical Vim (on Amazon.com it has more than forty 5-stars reviews). It is currently the best book around for this subject:

Installation

The best way to install syntastic is to use pathogen.vim, a plugin which can be used to manage and install other plugins while keeping them on their respective folder. If you already have installed pathogen on your system, please jump to the next section.

Installing pathogen.vim

In order to install pathogen you can take the following steps:

1. Download the file pathogen.vim from http://www.vim.org/scripts/script.php?script_id=2332
2. Open Vim's plugin directory, usually located at %USERPROFILE%\vimfiles (eg. C:\Users\Luca\vimfiles\). In a Linux environment the directory is named .vim and it's a hidden directory
3. Copy the file you downloaded in step 1 into the autoload folder
4. Create a new folder named bundle into the previous vimfiles folder
5. Open the _vimrc file (.vimrc in a Linux environment) usually located in %USERPROFILE% (eg. C:\Users\Luca\_vimrc) and add the following line:
   execute pathogen#infect()

Now all the new plugins can be easily installed by copying them into the bundle folder and pathogen will start them automatically.

In order to load the help and documentation for each installed plugin you could type:

:Helptags (Note the capital H)

Installing syntastic

In order to install syntastic you can download the main zip file from https://github.com/scrooloose/syntastic and extract it into the syntastic folder inside the bundle folder you have previously created. Alternatively you can just clone the git repository on GitHub (always into the bundle folder).

Once installed, you can type :Helptags to load the documentation. In this way you can type :h syntastic to see the help.

Basic usage

Once installed, syntastic is automatically activated, assuming that it manages to find a suitable checker for the current programming language.
As already mentioned, in this article I will show how to install a checker for PHP and JavaScript, but you should be able to install a checker for another language with little effort.

PHP checker

Open a new terminal window with cmd and write php -v on the command line.
If you can see a result similar to the one in the picture below, then the php intepreter is already on your system path and you can skip to the following paragraph.

If you receive an error which says that php is not a valid command, then you must add the php interpreter path to the system environment variables. I use Xampp so php is located in C:\xampp\php. You should add the following string to the PATH variable:

Once added to the PATH variable, restart the terminal and try again digit php -v. You should now see the installed version of PHP.

Now open a PHP file and digit :SyntasticInfo to see which checkers can be enabled:

The default PHP checker is phpcs (PHP CodeSniffer di Pear) but it turns out to be a bit too picky for my taste (e.g. it will highlight as an error the fact that the line terminator is \r\n instead of \n).
In order to set another default checker for PHP files open the _vimrc file and add the following line:

let g:syntastic_php_checkers = ['php']

Reload the _vimrc file with :source $MYVIMRC (or close and reopen Vim).

By default syntastic will automatically activate every time a file is written to the disk (for example when you write :w myfile.php) or manually when typing the :SyntasticCheck command. Please note that syntastic will analyze saved files only, it will not consider unsaved changes!

If there are any errors, syntastic will highlight the corresponding lines and will show a tooltip with a descriptive message. In the next picture I have omitted a parenthesis and syntastic is highlighting the row. If you put your mouse over the line you will see a tooltip.

Using the command :Errors you can open a list with all the errors along with their descriptive message and line number. To close the list, simply type the command :lclose.

Now you just have to fix all the errors found by syntastic!

We'll see in the next section how to install a checker for JavaScript files.

Checker per JavaScript e jQuery

As for JavaScript (and jQuery of course!) the process will be similar but we're going to install JSHint as the default checker.

First you will need to install Node.js. You can download the Windows installer at http://nodejs.org/download/

Once installed, open the Node.js command prompt and use the npm package manager to install JSHint by typing the following statement:

npm install jshint -g

Open a JavaScript file and type :SyntasticInfo to see which checker are enabled:

As mentioned before By default syntastic will automatically activate every time a file is written to the disk (for example when you write :w jquery-myplugin.js) or manually when typing the :SyntasticCheck command. Please note that syntastic will analyze saved files only, it will not consider unsaved changes!

Lines with syntax errors, warnings or coding hints will be underlined and a tooltip will appear when placing the cursor above them.

The :Errors command will open a list with all the error messages and the corresponding line numbers.
Pressing enter or when you double click on a line will move you directly to the corrisponding position of the error.
To close the list, simply type the command :lclose.

Now you just have to eliminate all the errors, rinse and repeat until your code will not be ready!

Set the syntax check manually

Sometimes it can be too much the fact that the syntax check is activated every time you save a file, but it's possible to configure Vim to execute it only on demand (for example by binding it to a specific hotkey).

First you need to set syntastic in passive mode; in this way the check will be run only when you execute the command :SyntasticCheck.
You also need to set a variable to avoid running the command every time you save a file.
You will need to add the following two lines to the file _vimrc:

let g:syntastic_check_on_wq = 0
let g:syntastic_mode_map = { 'mode': 'passive' }

Now if you want to bind the check to a specific hotkey (F6 in my case), you can do a remap by adding the following line:

nnoremap <silent> <F6> :SyntasticCheck<CR>

Now the syntax check will be only executed when you press the F6 key.

Automatically open the list of errors

As we saw before, you need to type :Errors to open a list with all the errors found in the file.
In order to automatically open the list every time the syntax check is run, you just need to add the following line to the file _vimrc:

let g:syntastic_auto_loc_list = 1

Ignore style errors

Many of the checkers (e.g. JSHint) are able to distinguish between three different type of errors:

• Errors
  The real errors (for example a missing bracket)
• Warnings
  Warning messages which do not usually stop the execution of the code but it is recommended to fix
• Style
  These are style "errors" (such as indenting rules or best practices)

Sometimes you just want to detect real errors or warnings, maybe because you are using different conventions and you don't want to be "bothered" by unnecessary messages (in the case of PHP, the checker phpcs will detect a style error if your line terminating characters will be \r\n by default in Windows instead of just \r).

Although they can be useful, you can silence these warnings by adding the following line to our _vimrc file::

let g:syntastic_quiet_messages = { "type":  "style" }

All the instructions added so far by this post are the following:

To view the additional options available for this plugin and for more information about the available checkers you can always read the very good documentation by typing h: syntastic

I hope this article will help you developing quality code in a better way and expecially help you finding your code error faster!

Check della sintassi per PHP e JavaScript in Vim

Una funzione molto utile presente in numerosi strumenti di sviluppo (i cosiddetti IDE come Visual Studio, Eclipse, NetBeans ecc…) è la possibilità di individuare eventuali errori di sintassi durante la scrittura del codice.

Questa funzionalità è disponibile anche per Vim utilizzando un ottimo plugin chiamato syntastic (l’autore è lo stesso di un altro plugin molto famoso e utilizzato: The NERD Tree).
Questo permette infatti di individuare eventuali errori di sintassi o di stile evidenziando le righe interessate e supporta una grande varietà di linguaggi.

In questo articolo vedremo come installare syntastic e come abilitare il controllo della sintassi per PHP e JavaScript in ambiente Windows.
Se lavorate in ambiente Linux o Mac dovreste comunque essere in grado di seguire e adattare i vari passaggi.

Premessa su Vim

Questo articolo parte dal presupposto che conosciate già le basi Vim e che siate in grado di installare un plugin.
Se vi interessa sapere di più su Vim, un editor molto potente free e open source, potete trovare numerosissimi tutorial in rete, ad esempio:

• http://vim.wikia.com/wiki/Tutorial (una wiki interamente dedicata a Vim)
• http://vimcasts.org/ (una serie di video a proposito di Vim)
• http://www.vim.org/ (il sito ufficiale da cui scaricare il programma)

Se invece volete un libro per conoscere o approfondire Vim vi consiglio caldamente questo manuale chiamato Practical Vim (su Amazon.com ha 44 recensioni tutte da 5 stelle). Credo che attualmente non esista un libro migliore disponibile sull’argomento:

Installazione

Il modo migliore per installare syntastic è sicuramente quello di utilizzare pathogen.vim, un plugin che permette di gestire e installare facilmente altri plugin mantenendoli ordinati nelle loro rispettive cartelle. Se avete già installato pathogen.vim saltate pure alla sezione seguente.

Installazione di pathogen.vim

Per installare pathogen basterà seguire i seguenti step:

1. Scaricate il file pathogen.vim all’indirizzo http://www.vim.org/scripts/script.php?script_id=2332
2. Aprite la cartella contenente i plugin di Vim, solitamente situata in %USERPROFILE%\vimfiles (es. C:\Users\Luca\vimfiles\). In ambiente Linux la cartella è nascosta e si trova nella home con il nome di .vim
3. Copiate il file scaricato al punto 1 all’interno della cartella autoload
4. Tornate nella cartella vimfiles e create una nuova cartella di nome bundle
5. Aprite il file _vimrc (.vimrc in ambiente Linux) che si trova sempre in %USERPROFILE% (es. C:\Users\Luca\_vimrc) o nella home e aggiungete la seguente linea
   
   execute pathogen#infect()

In questo modo tutti i plugin potranno essere installati semplicemente inserendoli all’interno della cartella bundle e pathogen.vim li caricherà automaticamente.

Per caricare anche gli help e la documentazione di ciascun plugin installato tramite pathogen basterà digitare:

:Helptags (notare la H maiuscola)

Installazione di syntastic

Per installare syntastic basterà scaricare lo zip all’indirizzo https://github.com/scrooloose/syntastic ed estrarlo nella cartella syntastic all’interno della cartella bundle creata al punto precedente. In alternativa potete anche effettuare un clone con git del repository presente su Github (sempre all’interno della cartella bundle).

Una volta installato aprite Vim e digitate :Helptags per caricare la documentazione di syntastic. In questo modo sarà possibile digitare :h syntastic in qualunque momento per consultare l’help.

Utilizzo

Una volta installato syntastic si attiva automaticamente, supponendo che riesca a trovare un checker per il linguaggio che si vuole utilizzare.
Come già detto, in questo articolo installeremo un checker per PHP e JavaScript, ma una volta capito il concetto è molto semplice installare un checker per altri linguaggi.

Checker per PHP

Aprite una nuova finestra del terminale con cmd e scrivete php -v sulla linea di comando.
Se compare un risultato simile a quello nell’immagine seguente significa che php è già all’interno del vostro PATH e non dovete fare altro.

Se il comando invece non viene invece riconosciuto, sarà necessario aggiungere alla variabile di ambiente PATH il percorso in cui si trova l’interprete php. Nel mio caso, utilizzando Xampp, si trova in C:\xampp\php, pertanto ho dovuto aprire le proprietà di sistema e aggiungere la seguente stringa alla variabile PATH:

Una volta aggiunta la variabile al PATH, riavviate il terminale e riprovate a digitare php -v. Dovrebbe comparire la versione installata di PHP.

Apriamo ora un file PHP qualsiasi e digitiamo :SyntasticInfo per vedere quali checker sono attualmente utilizzati:

Il checker di default per PHP è phpcs (PHP CodeSniffer di Pear) che però risulta essere un po’ troppo intrusivo per i miei gusti (ad esempio segnalerà come errore il fatto che il terminatore di riga non sia \n ma \r\n). Per impostare php invece di phpcs come checker predefinito per i file PHP apriamo il file _vimrc e aggiungiamo la seguente linea:

let g:syntastic_php_checkers = ['php']

Ricarichiamo il file _vimrc con :source $MYVIMRC (oppure chiudendo e riaprendo Vim).

Di default syntastic si attiva automaticamente ogni volta che un file viene scritto su disco (ad esempio quando scriviamo :w myfile.php) oppure su richiesta con il comando :SyntasticCheck (da notare che il programma analizzerà comunque solo i file già salvati, non terrà conto di eventuali modifiche non ancora salvate!).

Se sono presenti degli errori e il file viene salvato, syntastic evidenzierà le linee interessate e mostrerà dei tooltip con dei messaggi descrittivi. Nell’immagine successiva ho di proposito omesso una parentesi e al momento del salvataggio il programma ha sottolineato la riga interessata. Mettendo il mouse sopra la riga viene mostrato un tooltip.

Utilizzando il comando :Errors, verrà aperta una lista contenente tutti gli errori con indicato il numero di riga e il messaggio di errore. Per chiudere la lista è sufficiente digitare il comando :lclose.

A questo punto non resta che correggere tutti gli errori rilevati e riprovare fino a quando non saranno stati tutti debellati :)

Vediamo adesso come installare un checker i file JavaScript.

Checker per JavaScript e jQuery

Per quanto riguarda JavaScript (e jQuery naturalmente!) il procedimento sarà abbastanza simile anche se andremo a installare JSHint come checker.

Per prima cosa sarà necessario installare Node.js, scaricando l’installer per Windows all'indirizzo http://nodejs.org/download/

Una volta installato apriamo la console di Node.js (troverete Node.js command prompt nella lista dei programmi se avete scaricato l’installer) e usiamo il package manager per installare JSHint digitando la seguente istruzione:

npm install jshint -g

Come per PHP apriamo un file JavaScript qualunque e digitiamo :SyntasticInfo per vedere quali checker sono attualmente utilizzati:

Come detto precedentemente, syntastic si attiva di default al momento del salvataggio del file (ad esempio quando scriviamo :w jquery-myplugin.js) oppure su richiesta con il comando :SyntasticCheck (da notare che il programma analizzerà comunque solo i file già salvati, non terrà conto di eventuali modifiche non ancora salvate!).

Le righe che presentano eventuali errori di sintassi, warning o semplicemente consigli sullo stile verranno sottolineate e comparirà un tooltip posizionando il cursore o il mouse sulla riga corrispondente.

Con il comando :Errors verrà aperta una lista contenente tutti gli errori con indicato il numero di riga e il messaggio di errore.
Premendo invio o anche solo facendo doppio clic su una riga si arriverà direttamente alla posizione corrispondente dell’errore.
Per chiudere la lista è sufficiente digitare il comando :lclose.

Non resta quindi che debellare tutti gli errori, controllare e ripetere fino a quando il nostro codice non sarà pronto!

Impostare il controllo della sintassi manualmente

A volte può risultare troppo “invasivo” il fatto che il controllo della sintassi venga eseguito ad ogni salvataggio del file, ma è possibile configurare Vim per eseguirlo solamente su richiesta (ad esempio associandolo a uno specifico hotkey).

Per prima cosa è necessario impostare syntastic in modalità passiva; in questo modo il controllo dei file sarà eseguito soltanto tramite il comando :SyntasticCheck.
Bisogna inoltre impostare una variabile per evitare di eseguire il controllo al salvataggio del file. Nel dettaglio le due istruzioni da aggiungere al file _vimrc sono le seguenti:

let g:syntastic_check_on_wq = 0
let g:syntastic_mode_map = { 'mode': 'passive' }

Se adesso vogliamo associare il controllo a un determinato hotkey (nel mio caso F6), basta effettuare un remap aggiungendo la seguente istruzione:

nnoremap <silent> <F6> :SyntasticCheck<CR>

In questo modo il controllo verrà eseguito solamente premendo il tasto F6.

Aprire automaticamente la lista degli errori

Come abbiamo visto, è necessario digitare :Errors per far comparire la lista con tutti gli errori rilevati all’interno del file.
Per fare sì che la lista venga aperta automaticamente dopo ogni controllo di sintassi basta aggiungere la seguente istruzione al file _vimrc:

let g:syntastic_auto_loc_list = 1

Ignorare gli errori di “stile”

Molti dei checker (come ad esempio JSHint) sono in grado di distinguere 3 tipi diversi di errori:

• Errori
  Gli errori veri e propri (esempio una parentesi obbligatoria mancante)
• Warning
  Avvertimenti che normalmente non bloccherebbero l’esecuzione del programma ma che è comunque consigliato correggere
• Style
  Questi sono “errori” di stile (come ad esempio le best practice sull’indentatura)

Alle volte si è interessati solamente agli errori e ai warning veri e propri, magari perché si usano convenzioni diverse da quelle consigliate e quindi non si vuole essere “disturbati” da eventuali messaggi non strettamente necessari (nel caso di PHP, ad esempio phpcs segnalerà come errore di stile il fatto che le linee terminano con \r\n di default in Windows, invece che in \n).

Anche se spesso utili, è possibile mettere a tacere questi warning aggiungendo la seguente istruzione al file _vimrc:

let g:syntastic_quiet_messages = { "type":  "style" }

In definitiva, tutte le istruzioni viste finora da aggiunge al file _vimrc per quanto riguarda syntastic sono le seguenti:

Per consultare le altre opzioni relative al plugin e per avere ulteriori informazioni sui vari checker è sufficiente leggere l’ottima documentazione fornita digitando h: syntastic

Spero che questo articolo vi possa aiutare a sviluppare codice di qualità in maniera migliore e soprattutto a trovare eventuali errori più velocemente!

Recensione di RegexBuddy

Nella carriera di un ogni programmatore capita almeno una volta di doversi scontrare con un problema che richiede l’utilizzo delle regular expression.
Personalmente amo particolarmente le regex e trovo stimolante risolvere problemi che ne richiedono l’uso, al pari della risoluzione di un buon sudoku :)

Se avete cercato qualche volta un disperato aiuto su Google oppure se utilizzate le regex di frequente, vi sarà probabilmente capitato di visitare l’ottimo sito http://www.regular-expressions.info/ dove si possono trovare una marea di informazioni, guide ed esempi anche specifici per linguaggio di programmazione.

Proprio dall’autore di questo sito viene il programma oggetto di questa recensione: RegexBuddy.
Il programma è a pagamento e il costo per una singola licenza è di circa 30 € (sono disponibili sconti per l’acquisto di licenze multiple).

Aprendo per la prima volta il programma, l’interfaccia iniziale risulterà abbastanza complessa, ricca di funzionalità e non molto intuitiva, ma dopo qualche utilizzo comincerete a sentirvi a vostro agio.

Nell’area in alto a sinistra è possibile scrivere la propria regex con un piccolo editor dotato di syntax highlighting e inserimento guidato dei caratteri (premendo il tasto destro del mouse).
Per la creazione della regex è possibile scegliere tra più di 30 “flavor” diversi a seconda del linguaggio di programmazione che si sta utilizzando (es. C#, Java o Ruby) e selezionare le classiche impostazioni per le maiuscole e minuscole, il match multilinea ecc…
I tasti Copy e Paste sono molto avanzati e permettono di copiare e incollare stringhe diverse a seconda della codifica del linguaggio di programmazione; selezionando ad esempio da Visual Studio la stringa "\\w^[0-9]{3}$", è possibile incollarla già decodificata con Paste -> Paste Regex from a C# String e verrà quindi inserita come \w^[0-9]{3}$.
Oltre alla funzionalità di match è chiaramente diponibile anche il replace per effettuare sostituzioni e lo split per dividere la stringa di prova in chunk.

Durante la scrittura si aggiornerà in tempo reale l’area Create in basso, dove è possibile vedere la scomposizione in token di tutte le parti che compongono la regex. Il grafico è molto utile per chi è alle prime armi e sta cercando di capire cosa sta succedendo oppure in caso di espressioni particolarmente lunghe e complicate. Ogni token viene infatti spiegato dettagliatamente e si ha una visuale gerarchica che scompone la regex.

Nell’area Test è possibile inserire il testo di prova e vedere gli eventuali match o gruppi di cattura premendo il tasto List All. È anche possibile inserire il testo specificando l’indirizzo di un sito web oppure utilizzare quelli della sezione Library (esaminata più avanti).
Premendo il tasto Debug si aprirà la schermata di debug che permette di vedere tutti i passi che vengono eseguiti dall’interprete per effettuare il match di un’espressione regolare.

La tab Library è davvero uno dei fiori all’occhiello del programma e contiene decine e decine di regular expression di uso comune già pronte, tutte comprensive di spiegazione e testi di prova (indirizzi e-mail, carte di credito, tag HTML ecc…). È anche possibile arricchire questa libreria inserendo le proprie regex “preferite”.

Nella sezione Use è possibile creare parti di codice già pronte per oltre 30 linguaggi di programmazione diversi da usare per il match oppure il replace. Per convertire una regex da un linguaggio a un altro è invece possibile utilizzare la tab Convert.

Infine come bonus è incluso anche un potente strumento di ricerca simile al comando grep presente nelle shell Unix. Per usarlo basta selezionare la cartella in cui si vuole cercare, un’eventuale filtro sul nome e il programma cercherà (o eventualmente sostituirà) le occorrenze della nostra regex su file system.

Come avrete capito dalla recensione più che positiva mi sento proprio di consigliare questo software, anche considerato il suo costo più che ragionevole.

Corredate il tutto con un help offline completo che attinge e integra i contenuti del sito e l’acquisto diventa automaticamente molto interessante per chi lavora con le regex 5-10 volte l’anno, quasi obbligato se invece vi imbattete spesso in questo genere di problemi.

Pro

• Tonnellate di funzionalità interessanti
• Inserimento "guidato" di classi e caratteri
• Libreria piena di regex già pronte
• Help offline completo

Contro

• Ottimo prezzo
• Interfaccia un po' affollata e non molto intuitiva
• Alcuni "freeze" (in particolare cambiando il layout delle finestre)

Returning an HTTP 403 Forbidden error with ASP.NET MVC

Sometimes it can be useful, in case of error, to return a custom error message to the user along with the HTTP 403 (Forbidden) status code.
This usually indicates that the access to the requested resource is denied for some reason and the server cannot proceed. Unlike the 401 Unauthorized status, which means an unauthorized access, correct credentials will not allow you to view the page.

To handle this scenario in ASP.NET MVC we can create a custom helper which must meet the following conditions:

• It must be easy and straightforward to use
• It must return a 403 status code along with the Forbidden status
• It must not perform a redirect but the page URL should stay the same
• It must display a custom view to the user

My HttpForbiddenResult class inherits from the HttpStatusCodeResult class which already exists in ASP.NET MVC. In this way, the framework will automatically set the status code and the description. The complete code of the class is the following:

public class HttpForbiddenResult : HttpStatusCodeResult
{
    public override void ExecuteResult(ControllerContext context)
    {
        base.ExecuteResult(context);

        // creates the ViewResult adding ViewData and TempData parameters
        ViewResult result = new ViewResult
        {
            ViewName = "AccessDenied",
            ViewData = context.Controller.ViewData,
            TempData = context.Controller.TempData
        };

        result.ExecuteResult(context);
    }

    // calls the base constructor with 403 status code
    public HttpForbiddenResult()
        : base(HttpStatusCode.Forbidden, "Forbidden")
    {
    }
}

I have also created a view called AccessDenied within the Shared folder, which contains a custom message for the users who will view the page:

@{
    ViewBag.Title = "Access Denied";
}

<h2>Access Denied</h2>

<p>Sorry, the access to this page is denied.</p>

In order to use the helper you need just the following lines of code:

public class HomeController : Controller
{
    public ActionResult DoSomething(string taskName)
    {
        // access denied if taskName is empty
        if (string.IsNullOrEmpty(taskName))
        return new HttpForbiddenResult();

        return View();
    }
}

If you visit the URL for the previous controller without the taskName parameter, you will see the following result:

Of course, with little modifications you can create a custom helper for all the HTTP error codes!

Restituire un errore HTTP 403 Forbidden con ASP.NET MVC

Alle volte può essere utile, in caso di errore, restituire all'utente un messaggio personalizzato insieme al codice HTTP 403 (Forbidden).
Questo indica solitamente che l'accesso alla risorsa richiesta è vietato per qualche ragione e il server non può procedere altrimenti. Diversamente dallo stato 401 Unauthorized, che indica un accesso non autorizzato, le credenziali non servono e non permetterebbero comunque di visualizzare la pagina.

Per gestire questa situazione in ASP.NET MVC possiamo creare un helper personalizzato che deve soddisfare le seguenti condizioni:

• Deve essere facile e immediato da utilizzare
• Deve restituire al browser il codice di errore 403 insieme allo stato Forbidden
• Non deve effettuare un redirect ma la pagina deve rimanere la stessa
• Deve mostrare all'utente una view personalizzata

Ho creato la classe HttpForbiddenResult ereditando dalla classe HttpStatusCodeResult già esistente in ASP.NET MVC. In questo modo il framework si occuperà automaticamente di impostare il codice di errore e la descrizione. Il codice completo della classe è il seguente:

public class HttpForbiddenResult : HttpStatusCodeResult
{
    public override void ExecuteResult(ControllerContext context)
    {
        base.ExecuteResult(context);

        // crea il ViewResult impostando anche i parametri ViewData e TempData
        ViewResult result = new ViewResult
        {
            ViewName = "AccessDenied",
            ViewData = context.Controller.ViewData,
            TempData = context.Controller.TempData
        };

        result.ExecuteResult(context);
    }

    // richiama il costruttore base con il codice 403
    public HttpForbiddenResult()
        : base(HttpStatusCode.Forbidden, "Forbidden")
    {
    }
}

Ho creato quindi una view chiamata AccessDenied all'interno della cartella Shared, contenente un messaggio per gli utenti che visualizzeranno la pagina di errore:

@{
    ViewBag.Title = "Access Denied";
}

<h2>Access Denied</h2>

<p>Sorry, the access to this page is denied.</p>

Per utilizzare l'helper appena creato saranno sufficienti le seguenti linee di codice:

public class HomeController : Controller
{
    public ActionResult DoSomething(string taskName)
    {
        // accesso negato quando il parametro taskName è vuoto
        if (string.IsNullOrEmpty(taskName))
        return new HttpForbiddenResult();

        return View();
    }
}

Andando quindi con il browser alla URL del controller precedente senza il parametro taskName il risultato sarà questo:

Chiaramente con le opportune modifiche è possibile realizzare un helper per tutti i codici di errore HTTP che ci interessano!

Debugging into ASP.NET MVC 4 source code

Introduction

As you may know, ASP.NET MVC 4 it's an open source project and the code is freely available on CodePlex.
You can download and explore it to see how they have implemented some of the classes we are interested in or just to understand a little more about the entire framework.
In my case, for example, it has been very useful to see how the HandleError attribute is automatically serving the Error view in case of exception.
Sometimes it could be more useful to directly enter into the source code at runtime and see which operations are performed, watch or change the values of the variables and jump from one part of the code to another.
Today I will show then how to debug a web application into the source code of ASP.NET MVC 4 without the need to download and compile the whole project from CodePlex.
In order to do this we will use the SymbolSource server, which publicly provides the PDB symbols required to perform remote debugging in Visual Studio.
The PDB files are automatically created when the source code is compiled in debug mode and they contain information used to debug the code at runtime. These files are not usually included when we download the DLL files for an external library.
To obtain the PDB files of an external library (ASP.NET MVC 4 in this case) there are two ways:

• Download and compile the source code of the library (if available)
• Use SymbolSource and remote debugging

If you want to learn more about the PDB files you can read this this post.

Visual Studio Configuration

First you need to configure Visual Studio so that it can connect to the SymbolSource server and download the PDB files.
To do that, follow these steps:

• Go to Tools -> Options -> Debugger -> General
• Uncheck the option Enable Just My Code (Managed Only)
• Uncheck the option Enable. NET Framework source stepping (this is optional)
• Check the option Enable source server support
• Uncheck the option Require source files to exactly match the original version

The options screen should look like this:

Now you must set the servers from which to download the PDB files:

• Go to Tools -> Options -> Debugger -> Symbols
• You should see only one item: Microsoft Symbol Servers
• Click the exlamation mark icon to the right and add the following addresses:
• http://referencesource.microsoft.com/symbols
• http://srv.symbolsource.org/pdb/Public
• http://srv.symbolsource.org/pdb/MyGet
• http://msdl.microsoft.com/download/symbols
• If needed, select a folder for the cache: in my case it is set to C:\Users\Luca\AppData\Local\Temp\SymbolCache

The screen should look like this:

Finally you need to specify the DLL files you want to load, otherwise Visual Studio will load all the modules and debugging becomes very slow.
In this case we are only interested in ASP.NET MVC, so click on Only specified modules, then click on Specify modules and insert System.Web.Mvc.dll:

Press OK and exit from the options screens.
Now we're almost done and we just need to open or create a new ASP.NET MVC 4 application, place a breakpoint and start debugging with Debug -> Start Debugging.
If everything went well, in the Call Stack window you should see the ASP.NET MVC modules in black:

Now when you press Debug -> Step Into on an ASP.NET MVC statement you will enter directly into the source code of the framework, with a lot of comments too!

Help me! It doesn't work!

If the modules in the Call Stack window are still appearing in gray and you can't enter into the source code of the framework, you can try the following solutions:

Make sure you followed all the steps and you have checked all the required options. In particular, make sure that you have removed the check from Require source files to exactly match the original version and entered all the SymbolSource addresses in the right order.

Try uninstalling and reinstalling the ASP.NET MVC 4 NuGet package (you don't have to reinstall the program, just the package!).

If you still cannot run the debugger, there is a final solution that worked fine for me.

It appears that in some cases the DLL files in the GAC (Global Assembly Cache) prevent Visual Studio from loading the PDB files from the remote server.

Reinstalling ASP.NET MVC did not help in my case (I just lost a lot of time) but I solved this problem in the following way:

• Go to C:\Windows\Microsoft.NET\assembly\GAC_MSIL
• Find the folder called System.Web.Mvc
• Rename it, for example _System.Web.Mvc

In this way, the DLL files for ASP.NET MVC will not be searched in the GAC allowing you to connect to the SymbolSource server and download the PDB files.

Welcome to my blog

Welcome to my blog dedicated to two of my favorite passions: programming and cooking.

It's a rather strange combination and it will not be easy to write quality content for both categories.

The recipes won't be complex but fairly quick and easy to make! The other posts will span from .NET programming to Ruby on Rails, from Windows to Xubuntu.

About me, I'm a web programmer with a big passion for computing. I am currently working in a company as a .NET developer but in my free time I like to explore new programming languages ​​and technologies.

Let's begin this little adventure!