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.

While most of you have already heard about the ability to define Debug and Release web.config files, these two new features may put you over the edge in waiting for .NET 4.0 to release.

• Clean Web.Config Files

  Finally Microsoft has realized that while having configuration files that are verbose enough to support wild customizations, most of us do not need to change the default sections in the web.config file. So it should come as no surprise that clean configuration files will now be a thing of the (recent) past. It is just a shame it took so long to get.

• Control over Client Ids

  Hidden in this post about new project templates and what looks to be the ASP.NET WebForms version of the ASP.NET MVC template is a bit about client ids for controls.

  All of the styles and content within the site are configured using CSS, and take advantage of some of the new features with Web Forms in ASP.NET 4 – including clean client-side “id” names (no more ctrl_ mangled names – ASP.NET 4 gives you complete control over the client id), and CSS based rendering instead of table based rendering for the built-in server controls.

  This, again, should come as no surprise as the mangled names can present problems for developers looking to write some quick javascript as well as those looking to simply clean up their HTML. Here’s to hoping that Microsoft cleans up its HTML in other places as well (SharePoint anyone?).

Furthermore, if you are running into assembly load problems when running on Windows Server 2008 R2 remember that everything is running in X64 and that you need to enable 32-bit compatibility in your Application Pools. To do this select the App Pool and click “Advanced Settings” and set “Enable 32-Bit Applications” to true.

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.

The driving force behind the provider model is the abstraction of the implementation. This is done via an interface.

1
2
3

public interface IAuthenticationProvider{
	bool Authenticate(string username, string password);
}

What gives the provider model its meat and bones is the different implementations of the above interface. The two implementations below represent two authentication backends: an ActiveDirectory installation and an Sql database. Although the meat has been stripped from these two classes, it is clear that their implementations would differ enough to have the two separate classes.

1
2
3
4
5
6
7
8
9
10
11
12
13

public class ActiveDirectoryAuthenticationProvider : IAuthenticationProvider{
	public bool Authenticate(string username, string password){
		// Attempt to log user into AD.
		return authTest;
	}
}
 
public class SqlAuthenticationProvider : IAuthenticationProvider{
	public bool Authenticate(string username, string password){
		// Validate credentials against the Sql DB.
		return authTest;
	}
}

Now that the implementation is abstracted from the functionality requirements, the provider model requires only a driver to use differing implementations. Below is a sample driver that simply uses each provider to authenticate a user. It is important to note that there is no code to be changed based on what backend (provider) is being used due to the use of the common interface.

1
2
3
4
5
6
7
8
9
10
11

public class Driver {
	public Driver(IAuthenticationProvider provider){
		if(provider.Authenticate(“jsedlak”, “hello”))
			Console.WriteLine(“You are authenticated!”);
	}
 
	public static void Main(){
		Driver d1 = new Driver(new SqlAuthenticationProvider());
		Driver d2 = new Driver(new ActiveDirectoryAuthenticationProvider());
	}
}

The above example is a simplified version of the provider models used in Vodka where Membership, Authentication and Roles have all been squeezed into one provider. The reason for this is to remove an unnecessary code complexity requirement of three different security providers. More often than not, the three are commonly found together in the backend anyways.

There is a lot of work to be done, but the base code (being built into FGF) is coming along very nicely. Once I can figure out security, the project should simply expand exponentially provided I have the time (ugh!). The two main [sub]projects here are FGDN (Focused Games Developer Network) and a simple CMS similar to that of WordPress, SharePoint, et al. The first is designed to allow users to submit bugs, feature requests, etc. easily much like Microsoft’s Connect. The latter is pretty self explanatory.

Because I am building this all as one interconnected solution, I have also started working on the idea that users that exist in Vodka [may] have access to many other parts of Focused Games. Primarily this means FGDN but also the SVN repositories. A user (you) can apply for access to one or more of the repositories I currently use for my source code. Once you are accepted, you are also connected to any other Vodka service I create. Pretty nifty, eh?

WebHost4Life
ASP.NET, PHP, etc. and Unlimited Bandwidth
WebHost4Life was one of my first ASP.NET hosts and was used largely because I could run PHP alongside my normal web apps. This is a huge plus since I run a PHP-based forum and did not want to force my users to recreate their users, et cetera. So what was the problem with WebHost4Life? Daily downtime of an hour or more at roughly 2AM GMT -5 due to the AppPool being reset. This is completely unecessary and about the worse thing a host could ever do, especially when claiming 99% reliability.

BlueHost
PHP, unlimited everything
BlueHost was my first real host and I have had my account for over two years now. What can I say about them other than they are amazing, especially for Shared hosting. I am running three sites on them now and am having no problems so far with scalability. But because accounts are so cheap compared to ASP.NET hosts, I can easily buy a second or a third if need be. Only problem? The CEO has told me in a private e-mail that he will never support ASP.NET on BlueHost, ever. Saddening because they could do great things for the ASP.NET world.

Reliable Site
ASP.NET, PHP
Reliable Site has been a great host for me up until recently. They were always great on support and always willing to help me out. Reliability was top notch: I didn’t experience a single second of downtime on my Clustered account, even when hosting four sites. The problem? They expect you to pay $8 a month for a mere 40gb of extra bandwidth on a rolling schedule. That means that bandwidth isn’t calculated per month but per last 30 days. This may be nice if you have consistent days, but spikes can ruin your bandwidth for 30 days. You have no chance of timing a release for the last 2-3 days of a month because it won’t matter.

I have experienced other hosts but they really aren’t worth mentioning. I just wish I could find a host that did what ReliableSite does but was easier on the bandwidth pricing. Especially when DreamHost, BlueHost and several others offer 5tb and more of bandwidth per month for less money.