Cache Problems with ASP.NET MVC Views?

John Sedlak — Tue, 27 Apr 2010 08:51:10 +0000

If you have done any decent amount of work with the ASP.NET MVC platform, you have probably run into the following problem. You have a page where you want to update data on the server without a postback and so you whip out some fancy Javascript to send a request to the server. What happens is the response you get back is a success, and the data is updated, but subsequent requests don’t seem to be updated. This is most noticeable with partial views and content views called via the infamous “$.ajax” call. What you forgot was to make sure the browser isn’t caching the result:

^?View Code CHSARP

1	HttpContext.Response.AddHeader("cache-control", "no-cache");

Note that if you have already hit the particular view and it is cached, you can generally clear the cache by navigating to the URI of the view manually and hitting refresh.

Linking To CSS Files In MasterPages

John Sedlak — Fri, 22 Jan 2010 18:45:44 +0000

A common problem for beginning ASP.NET developers is relative linking to CSS files in a MasterPage file. As it turns out, this is incredibly easy as shown below. Even better is that it works in ASP.NET MVC!

^?View Code HTML

1	" type="text/css" media="screen" />

Imploding Versus Exploding Installations

John Sedlak — Mon, 20 Apr 2009 01:15:11 +0000

One of the major design decisions for Vodka 2.0 has been how to handle the installation of all the software necessary to run a site. At first I favored a desktop application based install since it would allow me to write in normal .NET code without any problems or hurdles that the web presents. The problem with this idea is that a desktop based install isn’t feasible for most people, certainly not for those on shared hosting.

A client application based installation is what I call an Exploding Installation because it takes a package and pushes files out of it onto the file system. Thus it is exploding itself onto the computer. This works really well for most cases, especially basic software installs like games, office applications, et cetera.

Where such an explosion doesn’t work well is for web based installations, which is where Vodka 2.0 is headed (see screenshot below). This is due to the fact that in most cases the average user isn’t able to set up the server in a way to make it work, or doesn’t want to. Originally the installation procedure was going to be based on an explosion: the user would upload the files, put in the site information (see screenshot below) and then the installation would unpackage the files necessary to run the site based on the information. This would work very well, except it leaves the original install files at the root directory of the server. Instead of this approach, an Imploding Installation does the trick because it not only erases over the install files themselves (big security bonus), it doesn’t require any work to setup. The goal here is to have the user upload the files, run the install and get to work creating content.

So how is this done? To support an implosion of the software, or rather a rewrite of key points of it the software needs to be modular in such a way that programmatic writes can be done over content areas. In the case of the Vodka install the site’s navigation needs to be rewritten and because it is based on ASP.NET MVC has to handle the shutdown and/or removal of the installation controller and views. Right now this is done by removing a simple text file from the server, although in the future it can be done by changing a portion of the web.config file and/or removing an extra “Install” library from the bin directory.

The best part about the implosion is that it is 100% clean. After an installation is completed, there is no evidence left that it ever took place, and no possible way for a user to rerun the installation.

JSEDLAK » ASP.NET MVC

Cache Problems with ASP.NET MVC Views?

Linking To CSS Files In MasterPages

Imploding Versus Exploding Installations