While playing around with Razor I ran into a weird issue that convinced me I had something funky going on with caching and IIS 7.5 and/or jquery itself. 

Long story short, I wanted to check out the new Razor View Engine so I worked on an application that would show random quotations spoken by developers at some point in time.

The basic premise was this:

When the application comes up it bring up a random quote from the database. After a short interval, it would refresh the quote via an ajax call. There are various degrees of trickery you can do to get a random record from the database, but I didn’t want to use the NEWID() trick where you select your data and select and additional NEWID() column and sort by it. I ended up doing something a little different, although some may consider it a little kludgy nonetheless. I used a generic list shuffler, courtesy of StackOverlfow, which avoids using the Random type. If you’re curious here is the implementation:

public static void Shuffle<T>(this IList<T> list)
{
    RNGCryptoServiceProvider provider = new RNGCryptoServiceProvider();
    int n = list.Count;
    while (n > 1)
    {
        byte[] box = new byte[1];
        do provider.GetBytes(box);
        while (!(box[0] < n * (Byte.MaxValue / n)));
        int k = (box[0] % n);
        n--;
        T value = list[k];
        list[k] = list[n];
        list[n] = value;
    }
}

My model was previously defined in the earlier MVC 2 iteration of this demo project so I decided to use a variation of EF Code-First where I wanted to associate this model with an existing database. Anyway, I wired up everything correctly and things were smooth locally on the ASP.NET development server.

My random list shuffler appeared to work. (Note: this is not efficient, I could have actually just got a random quote directly from the DB, but I digress…). I’d was getting all the quotes from the database into a list, and then shuffling them and picking the first one. I isolated the display of the quote itself into a partial view and added the following code for a refresh:

setInterval(function () {
            $('#currentQuote').slideUp('fast', function () { });
            $.getJSON('Quote/GetNew', function (data) {
                $('#currentQuoteText').html(data.Text);
                $('#currentQuoteSource').html('- ' + data.Source);
            })
            $('#currentQuote').slideDown('slow', function () { });
            ;
        }, 7000);

This basically does this, it slides up the container that has the current quote, calls the GetNew action on the Quote controller, and replaces the html elements with the new quote to be displayed.

The partial view was pretty trivial as well:

@model Quoteboard.Domain.Entities.Quote
<div id="currentQuote">
    <h4 id="currentQuoteText">@Model.Text</h4>
    <blockquote id="currentQuoteSource">
        - @Model.Source</blockquote>
</div>

Once I dropped it on IIS, where the server name was actually showing up instead of localhost:port/ as the url for the application, the first quote would load repeatedly. This was insanely annoying because it would work locally. This triggered the red herring of a cache issue.

I did all kinds of silly things like decorating my action with this attribute

[System.Web.Mvc.OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]

I even went into IIS and prevented caching on the application. Yet it would not work, the same quote was being loaded over and over again. Curiously, there were no real error’s I could think of.

Finally, my mind went back to the getJson call. Was it failing? Thankfully, Chrome provides the Javascript console which revealed the error.

Turns out, it wasn’t caching at all, the code was failing, because Quote/GetNew was 404ing when deployed to IIS, because it was looking for the RELATIVE path! 

The correction that needed to be made was changing the $getJson line to:

 $.getJSON('@Url.Action("GetNew","/Quote")',

so the key was the url which invoked the action locally didn’t work correctly when deployed to a server, since Url.Action -> Generates a fully qualified URL to an action method by using the specified action name. Doh!

Oh well. I guess if someone runs into this issue, hopefully they wont suffer my brief folly.