Accessing Dependancy Injection Interfaces

There are some times where you need to access those instances in other classes. My preferred method of Dependancy Injection is Ninject (Others are available!).

The following code will allow you to access the interfaces that you have declared.

private static <Interface> obj = (<interface>)System.Web.Mvc.DependencyResolver.Current.GetService(typeof(<interface>));


HTML 5 offline apps with MVC

If this is your fist exposure to the HTML 5 Manifest, I recommend HTML 5 Rocks beginners guide!

Offline applications are becoming increasingly popular for your user base to continue interacting with your product when an active internet connection is not available. This makes is easier to demo a product when you visit a client.

Below I have included some real world scenarios that you may encounter during expanding an application to be made available offline.

Authenticated views

On load, your browser will try to load your manifest files and try to resolve each of the URL’s to cache the content. If there are pages in the manifest that are behind some sort of authentication process, the manifest file will fail and the cache content will be deleted as the browser will receive a 404 error. The same applies if your authentication process is role based.

Cross site scripting

With ASP.NET you can stop Cross Site Request Forgery (CSRF) by including the anti forgery token. If your page has one of these and it has been included in the manifest, your page will throw an exception as the cookie would have been expired.


When your content team update the website, they will expect to see the content straight away. The manifest file can’t detect if there has been a change to the content of the cached page, it will only know of there is a change once the manifest file has either been changed or deleted.

You only need to change one character in the manifest file for the browser to request a new one when the application is back on line. One way around this is to programatically add something like a date or a version number in the manifest for the browser to request it again.
Check out Sergi Dorogin‘s blog on how to do this.

By doing this, when the browser connects back to the website, the manifest would have change and the new content will be brought down cached in the browser.

Client side events

On load, your browser will go through a series of events to handle the manifest. Ben Nadel has a great post on the events and how to use them.
You may be asked to programatically void the cache client side to force a new one down. This won’t work as the client side events aren’t designed to do this.

Hide your .net framework version

Keeping your framework version up to date is always preferable, but for those projects that can’t be upgraded to the new framework version, you can always hide it.

The version number of your framework will be shown in the header of a request. Add the following code in your web.config file to stop the version from being shown.

<httpRuntime enableVersionHeader=”false” />