Setting up Django on Windows Azure Websites

A couple of things caught me out when I was trying to deploy a Django application to Windows Azure, so I’m making a note of them here for future reference. Oh, and I hope they might be of use to you as well :o)

Configuring Azure Websites to run Python and Django

The Windows Azure Websites and Django getting started tutorial directs us to put the required settings into the Azure management portal, but that’s not how Microsoft do it in the Gallery, oh no. If we create a Django application from the Windows Azure Website gallery, the resulting site puts all the configuration into a web.config.

Personally, I like the management portal approach, but I did play with the web.config and got it working for my custom site, so I present it here in case this works for you:

There are three things you need to do to get this working:

  1. Check the PYTHONPATHIt needs pointing to the root of your Django Application (the directory that holds manage.py, and the location of the directory site-packages (obviously, copy that directory into Azure from your development environment if it’s not there)
  2. Set DJANGO_SETTINGS_MODULEPoint this to your settings.py file. Replace directory slashes ‘/’ with dots, and omit the .py from the end
  3. Create the file handler.fcgiThis is required, and it’s a just a plain text file containing two double-quotes (i.e. “”) on the first line followed by a return carriage

Seriously though, just put the settings into the Azure management portal. It’s easier :o)

Bad Request (400)

Following the advice in settings.py the first thing I did after copying the files into Azure and seeing the Django “cool, now get cracking” default page was to trip DEBUG to False (DEBUG = False), then refresh the web browser..

Django on Windows Azure Websites - Bad Request (400)

Django on Windows Azure Websites – Bad Request (400)

Ouch.

Essentially, if DEBUG is False, we have to put our server’s URL into the ALLOWED_HOSTS setting. Now, we could do that in settings.py but this is really Azure specific just like the configuration above, so it really belongs in Azure.

In the Azure management portal, under the Website > Configure tab, find the ‘app settings’ section near the bottom and add the following:

Setting Value
ALLOWED_HOSTS Your Azure URL: e.g. mydjangosite.azurewebsites.net

If you have custom domains pointed at Azure, you can use a space-separated list like so: mydjangosite.azurewebsites.net myjangosite.com

SECRET_KEY While we’re adding new application settings, create a new 50 character random string and copy it here. We’ll use it in a second

Now, we could just modify our settings.py, but it’s much better to have a configuration file specifically for production / Azure, so first of all, copy your existing settings.py to a new file in the same directory – I like to use the filename settings_azure.py.

Now, assuming you have a shiny new settings_azure.py file, delete everything in it and replace it with this:

If you created this new settings_azure.py file, don’t forget to adjust the DJANGO_SETTINGS_MODULE value to point to it in the Azure management portal, or your web.config if you went that route, you heathen!

Extending System.Data.Linq.Table<T> – Exportable Linq2SQL Classes

Wouldn’t this be handy?:

I’ve found this approach useful when working on API’s which essentially provide access to data that closely mirrors Linq2SQL generated classes. It makes it easy to control which properties are included, and how they are formatted.

First, we declare an interface that we can decorate our Linq2SQL classes with. Note that I’m returning an XElement here, but this could be JSON or something else:

Then we augment the Linq2SQL classes we wish to be exportable, using Partial Classes as we’d normally do:

Finally, we extend the Linq Table class itself:

And that’s it!

As you can see, this approach affords us complete control over the Linq2SQL generated properties and the format they’re serialised to, and it makes it really easy to omit properties without having to re-implement them in the Partial class just so we can add the [XmlIgnore] attribute.

Gravatar HtmlHelper for ASP.Net MVC

Update: This implementation is now linked from the official Gravatar website!


Inspired by a recent project at work, here’s a complete implementation of the Gravatar image request API, as an ASP.Net MVC 3 / MCV4 HtmlHelper.

It includes the help and documentation from the Gravatar API page, and automatically does HTTPS/SSL requests if included on a page that is served securely (secure requests can be forced too).

Getting Started

  1. Head over to the project page on GitHub, and save the single file GravatarHtmlHelper.cs into your project
  2. Start using it with the HtmlHelper sytax, like so:

or

 

gravatar image examples

and that’s it!  The helper method is progressively overloaded, so you need only supply the minimum parameters to get the Gravatar you’re after.

 

Comments and suggestions are welcome here or on the projects issue tracker over at GitHub. I hope you find it useful :)

WTV: Automatic date-based version numbering for .Net with WhenTheVersion

There’s a trend towards using the software build date as part of the software version number, you know the sort of thing I mean: ‘2011.11.4.xyz‘, like in the footer over at StackOverflow.com, or MyLetts.com..

Wouldn’t it be great if we could get Visual Studio to do this for us automatically on build?  I thought so too, so I’ve written a little app to do it :)

Getting set up with “When The Version”

  1. Go get a copy of “When The Version” (WTV.exe) from the GitHub download page (or you can build it from the source if you prefer)
  2. Drop it somewhere on your PC
  3. Now, in your Visual Studio project, expand the Properties and duplicate the AssemblyInfo.cs / .vb file – I rename the duplicate to be AssemblyInfo.Template.cs:

  1. Edit the AssemblyInfo.Template.cs file, putting in the placeholders for the date parts like so:

The following values are currently supported:

  • {YYYY} – the year
  • {MM} – the month
  • {DD} – the day
  • {SVN} – SubVersion revision number (more on this a bit later)

 

  1. Now, open up the Project Properties > Build Events, and add the following Pre-build event command line (on a single line):

 

  1. Finally, set the Build Action for the new AssemblyInfo.Template.cs file to ‘None’ and Build!

 

If you get stuck, pop open a Command Prompt and run WTV.exe without any parameters for usage instructions, or paste your full command line to see any helpful error messages:

SubVersion support

If you’re using SubVersion for your source control, WTV can also put the projects SVN revision number into the application version.

There’s only one caveat – .Net Application version number values are limited to a maximum of 32,767 (i.e. they’re Int16′s / short’s). Therefore, if your SVN revision is higher WTV will only use the last 4 digits: e.g.: 32768 -> 2768.

To use the SVN revision number, simply add the {SVN} placeholder to your AssemblyInfo.Template.cs file like so:

 

.. and then add a couple of extra parameters to the Pre-build event command line so WTV knows where SubWCRev.exe is, something like this (again, on a single line):

 
And because the AssemblyInfo.cs is generated, you can remove it from source control (but don’t remove it from your project!).

 

Finally

Comments and suggestions are welcome here or on the projects issue tracker over at GitHub. I hope you find it useful :)

Using SquishIt with Razor – ASP.Net MVC3 and MVC4

I’ll assume you already know the reasons why you should minify and combine your CSS and Javascript.

My favourite of the tools available for .Net is SquishIt by Justin Etheredge – here’s how I hook it up in my ASP.Net MVC4 (and MVC3) Razor projects..

  1. Get the bits, either directly or find it in NuGet
  2. Add a Project Reference to the SquishIt.Framework.dll
  3. Add SquishIt to the namespaces section in the Views/Web.config:

  1. Replace any <link /> and <script /> references with the following*:

*I’m loading the <script />‘s in the <head /> here for brevity, but there’s nothing stopping us moving these two JavaScript statements (lines 15 & 22) to the bottom of our page so they’re just above the closing </body>, as is generally recommended.

  1. Finally, as you’ll have noticed in lines 11 & 20, we’re generating the squished files to a /Cache directory, so we need to create it and grant the IIS AppPool our site is running under create and modify permissions on it

 

As I’m usually working with Layout pages, I’m sure you’ll have also noticed the @RenderSection()‘s in the example (lines 13 & 22) – that let’s me inject page-specific Squished CSS and/or Javascript as needed like so:

 

Thank you Justin  :)