MVC Razor Views and automated Azure deployments

The other day, I decided that I’d publish a work-in-progress website to an Azure Website.  This was a free Website as part of the free package that Azure subscribers can use.  The website was a plain old vanilla ASP.NET MVC site.  Nothing fancy, just some models, some controllers , some infrastructure code and of course, some views.

I was deploying this to Azure via a direct connection to a private BitBucket Git repository I had within my BitBucket account.  This way, a simple “git commit” and “git push” would have, in a matter of seconds, my latest changes available for me to see in a real “on-the-internet” hosted site, thus giving me a better idea of how my site would look and feel than simply running the site on localhost.

An issue I almost instantly came up against was that, whenever I’d make a tiny change to just a view file – i.e. no code changes, just tweaks to HTML markup in the .cshtml Razor view file, and commit and push that change – the automated deployment process would kick in and the site would be successfully deployed to Azure, however, the newly changed Razor View would remain unchanged.

What on earth was going on?   I could run the site locally and see the layout change just fine, however, the version deployed to Azure was the older version, prior to the change.   I first decided that I now had to manually FTP the changed .cshtml files from my local machine to the relevant place in the Azure website, which did work, but was an inelegant solution.  I needed to find out why the changed Razor views were not being reflected in the Azure deployments.

image After some research, I found the answer.

Turns out that some of my view files (the .cshtml files themselves) had the “Build Action” property set to “None”.  In order for your view to be correctly deployed when using automated Azure deployments, the Build Action property must be set to “Content”.

Now, quite how the Build Action property had come to be set that way, I have no idea.  Some of the first views I’d added to the project had the Build Action set correctly, however, some of the newer views I’d added were set incorrectly.  I had not explicitly changed any of these properties on any files, so how some were originally set to Content and others set to None was a mystery.  And then I had an idea…..

I had been creating Views in a couple of different ways.  Turns out that when I was creating the View files using the Visual Studio context menu options, the files were being created with the correct default Build Action of Content.  However, when I was creating the View files using ReSharper’s QuickFix commands by hitting Alt + Enter on the line return View(); which shows the ReSharper menu allowing you to create a new Razor view with or without layout, it would create the View file with a default Build Action of None.

Bizarrely, attempting to recreate this issue in a brand new ASP.NET MVC project did not reproduce the issue (i.e. the ReSharper QuickFix command correctly created a View with a default Build Action of Content!)

I can only assume that this is some strange intermittent issue with ReSharper, although it’s quite probably caused by a specific difference between the projects that I’ve tested this on, thus far I have no idea what that difference may be…   I’ll keep looking and if I find the culprit, I’ll post an update here.

Until then, I’ll remain vigilant and always remember to double-check the Build Action property and ensure it’s set to Content for all newly created Razor Views.

Razor’s Conditional Attributes Bit Me!

When ASP.NET MVC 4 was released, Microsoft upgraded the Razor view engine that ships with ASP.NET MVC to version 2 and with it came a number of improvements. One of these improvements was a feature called “conditional attributes”.


Conditional Attributes are a new feature that allows you to shortcut “boilerplate” null check code when rendering an attribute to a HTML element. If you have a model property or a local variable that is used to output the “value” of a HTML element’s attribute that evaluates to NULL, the Razor engine will now automatically discard rendering the entire (empty) attribute.


Thus, whereas we’d previously have to do something like this:

<div @{ if(@Model.ClassName != null) { <text>class="@Model.ClassName"</text> } }>Content</div>

to ensure that, if @Model.ClassName was null, we wouldn’t render the entire class attribute, the new Conditional Attributes feature allows us to do this:

<div class="@Model.ClassName">Content</div>

and the Razor parser is smart enough to not render the class=”” literal attribute text if @Model.ClassName evaluates to null.  So we don’t get this:

<div class="">Content</div>

But instead we get much cleaner markup like this:



Razor’s conditional attributes also work similarly with boolean values, so you can for example, cleverly output checked attributes on an input element defined as a checkbox like so:

<input type="checkbox" checked="@IsChecked">

If @IsChecked evaluates to true, the checked attribute is rendered with a value which is the same name as the attribute:

<input type="checkbox" checked="checked">

However, if @IsChecked evaluates to false, the entire attribute is not rendered.  Andrew Nurse, a developer on Microsoft’s Razor team, has a great blog post about this and the other new features in Razor v2.


So, this is all well and good, however, there is a huge gotcha that you need to be aware of surrounding conditional attributes!  I discovered this when upgrading a project originally built in ASP.NET MVC 3 (which had Razor v1 and thus didn’t have the conditional  attributes feature) to ASP.NET MVC 4.  This previously working project suddenly developed bugs that weren’t there before.  Upon inspection, it was due to Razor’s new conditional attributes feature that introduced a breaking change in my code.


Basically, I had a ASP.NET MVC strongly-typed View that displayed a grid of data.  As part of the model for this view was an object used to hold some basic data relating to how the user had configured the grid.  This was simply non-sensitive data such as the number of records per page, the column name upon which the grid was sorted and the sort order (ascending or descending).  This was output to the View as a number of hidden input fields within the view’s form, such that they could be posted back to the server upon each page request:

<input type="hidden" name="pagesize" value="@Model.PagingInfo.ItemsPerPage" />
<input type="hidden" name="sortname" value="@Model.PagingInfo.SortName" />
<input type="hidden" name="sortasc" value="@Model.PagingInfo.SortAscending" />

The problem was within that last line.  The @Model.PagingInfo.SortAscending is a boolean that evaluates to true if the user wants to sort ascending, or false if the user wants to sort descending.  In ASP.NET MVC 3, this would work just fine with the resulting output looking something like:

<input type="hidden" name="sortasc" value="false" />

when the user had elected to sort descending.  However, upon upgrading the project to ASP.NET MVC 4, Razor v2’s conditional attributes feature saw that the @Model.PagingInfo.SortAscending model property was a boolean and that it evaluated to false, and decided not to render the value attribute at all, thus my output became:

<input type="hidden" name="sortasc" />

When the user had selected to sort in an ascending manner, and the value of the @Model.PagingInfo.SortAscending property evaluated to true, the output was even more strange:

<input type="hidden" name="sortasc" value="value" />

This was the “cleverness” of the Razor parser kicking in and outputting the attribute’s name as it’s value when my boolean property evaluated to true.  This makes lots of sense when we’re outputting a series of checkboxes and we want one of them to be checked, which requires the checked=”checked” attribute to be added to the checked element, but not so much sense when we actually want to output the string “true” or “false” as a value attribute’s value in a hidden text input form field!


So whilst the output each time was valid HTML markup with no errors being displayed, this clearly affected the functionality of my page.  POSTs of this page, which would cause the page to redisplay (for example, when the user selected a different sort column or a different sort order) would always result in the grid sorting in a descending manner, irrespective of the user’s choice.


This was due to the Razor model binder finding no suitable value with which to bind the sortasc parameter of the controller method that was invoked when the page was posted back to the server:

public ViewResult List(string searchterm, string sortname, bool sortasc = false, int id = Page, int pagesize = PageSize)

Of course, the sortasc parameter’s default value was then always used, resulting in the “grid is always descending” behaviour!


This was an interested bug to hunt down within my code, and was also a particularly annoying one too, as the code had worked perfectly in ASP.NET MVC 3.  However, once it was discovered how and why this bug reared it’s head, it was also simple enough to fix.


The fix for this is to simply append .ToString() to all boolean variables/model properties that are used purely to render a true or a false attribute’s value on a HTML element.


Thus, my above code was fixed quite simply like so:

<input type="hidden" name="pagesize" value="@Model.PagingInfo.ItemsPerPage" />
<input type="hidden" name="sortname" value="@Model.PagingInfo.SortName" />
<input type="hidden" name="sortasc" value="@Model.PagingInfo.SortAscending.ToString()" />

The addition of the .ToString() forces the evaluation of the boolean and it’s resulting conversion to a string prior to the Razor engine’s parser being able to work it’s “conditional attribute” cleverness.  It simply results in the boolean’s string value being output as the attributes value every time, like this:

<input type="hidden" name="sortasc" value="True" />

So, whilst this issue didn’t manifest itself for me until I upgraded an older ASP.NET MVC 3 project to ASP.NET MVC 4, it’s quite feasible that a developer could write code like this from scratch in MVC 4 and expect the Razor parser to simply output the value of the boolean as the attribute value.  There’s an open case for this in the ASP.NET Web Stack issue tracker on CodePlex and whilst there is a simple enough workaround for the problem, it’s the “breaking change” nature of the issue that is most concerning.


Let’s be careful out there and remember to .ToString() our booleans!

JavaScript / jQuery IntelliSense in Visual Studio 2012

I blogged a while ago about a rather ugly and hacky way in which you could get the goodness of jQuery (and general JavaScript) IntelliSense in the Razor editor in Visual Studio 2010’s IDE.


This basically involved placing code similar to the following into every MVC view where you wanted IntelliSense to show up:


@* Stupid hack to get jQuery intellisense to work in the VS2010 IDE! *@
@if (false)
   <script src="../../Scripts/jquery-1.6.2-vsdoc.js" type="text/javascript"></script>


Well, since the release of Visual Studio 11 Beta, and the recent release of Visual Studio 2012 RC (Visual Studio 2012 is now the formal name of Visual Studio 11) we now no longer have to perform the above hack and clutter up our MVC views in order to enjoy the benefits of IntelliSense.


In Visual Studio 2012 (hereafter referred to as VS2012) this has been achieved by allowing an additional file to be placed within the solution/project which will contain a list of “references” to other JavaScript files that all MVC views will reference and honour.


The first step to configuring this is to open up VS2012’s Options dialog by selecting TOOLS > OPTIONS from the main menu bar:




Once there, you’ll want to navigate to the Text Editor > JavaScript > IntelliSense > References options:




The first thing to change here, is to select Implicit (Web) from the Reference Group drop-down list.  Doing this shows the list of references and included files within the Implicit (Web) group, as shown below the drop-down. Implicit (Web) includes a number of .js files that are included with VS2012 itself (and are located within your VS2012 install folder), but it also includes the following, project-specific entry:




Of course, this is all configurable, so you can easily add your own file in here in your own specific location or change the pre-defined _references.js, but since ASP.NET MVC is based around convention over configuration, let’s leave the default as it is!  Click OK and close the options dialog.


Now, what’s happened so far is that as part of the pre-defined Implicit (Web) reference group, VS2012 will look for a file called _references.js within a web project’s ~/Scripts/ folder (the ~/ implying the root of our web application) and use the references that are defined within that file as other files that should be referenced from within each of our MVC views automatically.


So, the next step is to add this file to one of our MVC projects in the relevant location, namely the ~/Scripts/ folder.  Right-click on the Scripts folder and select Add > New Item:




Once the Add New Item dialog is displayed, we can add a new JavaScript File, making sure that we name the file exactly as the default pre-defined Implicit (Web) reference group expects the file to be named:





The format of the _references.js file follows the JScript Comments Reference format that has been in Visual Studio since VS2008.  It’s shown below:


/// <reference path=”path to file to include” />


You can add as many or as few “references” within the _references.js file that you need.  Bear in mind, though, that the more files you add in here, the more it may negatively impact the performance of the editor/IDE as it’ll have far more files that it has to load and parse in order to determine what IntelliSense should be displayed.   A sample _references.js file is shown below:




The format/syntax of the references within this file can take a number of forms.  You can directly reference other JavaScript files without needing a path if they’re in the same folder as the _references.js file (as the example above shows):


/// <reference path="jquery-1.6.3.js" />


You can use relative paths which are relative from the folder where the _references.js file is located:


/// <reference path="SubfolderTest/jquery-1.6.3.js" />


And you can also use paths that are relative to your web project’s “root” folder by using the special ASP.NET ~ (tilde) syntax:


/// <reference path="~/Scripts/SubfolderTest/jquery-1.6.3.js" />


Once this is configured and saved, you will now have lovely IntelliSense within your MVC Views without needing additional hacky script references from within the view itself.  See the screen shot below:




Yep, that’s the entirety of the view that you can see there (no @if(false) nonsense!), and that’s lovely jQuery IntelliSense being displayed as soon as you start typing $( !


Update (10/Feb/2013): Changed the screenshots to use a nicer elliptical highlighting and tweaked some references ever-so-slightly (i.e. change jQuery from 1.6.2 to 1.6.3)