Since I last rebuilt my development machine I haven’t had a need to even look at web development let alone Windows Azure.  The last time I had “opportunity” to develop anything using Windows Azure was with version 1.3.  At the time version 1.4 was still in beta and I couldn’t seem to successfully install it.

Lucky me I was added to a project using Windows Azure so I installed version 1.6 along with the Windows Azure Platform Training Kit – November Update and decided to make a quick run through some of the training kit to see how things worked.

Much to my chagrin attempting to run the training projects only ever resulted in the dialog:

The first thing that popped out at me was the IP address ‘127.255.0.0’.  I immediately proceeded to look at project properties to figure out where this came from to no avail.  I then unloaded the projects and looked through the raw project and solution files to no avail.  Attempting to ping the address did succeed so I looked through my hosts file in ‘%windir%\System32\drivers\etc’.  Nope it wasn’t there either. 

Searching the Internet (hmmm, I wonder if the term ‘Binging’ will be added to the dictionary?) on the error message gave me a whole lot of nothing.  Refining my search to just the IP address sent me off on a tangent for blogs on Windows Azure v1.5 about the need to add entries to the hosts file, although they were helpful in educating me about what in the world the IP address was.  For more information on that see http://blogs.msdn.com/b/avkashchauhan/archive/2011/09/16/whats-new-in-windows-azure-sdk-1-5-each-instance-in-any-role-gets-its-own-ip-address-to-match-compute-emulator-close-the-cloud-environment.aspx.

Finally *bonk* I got the idea to look in the Windows Event log.  It should have been the first place I looked but I guess I hadn’t drank enough coffee yet to think straight.

I found two errors:

ISAPI Filter ‘C:\Windows\Microsoft.NET\Framework\v4.0.30319\\aspnet_filter.dll’ could not be loaded due to a configuration problem. The current configuration only supports loading images built for a AMD64 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.

and

Could not load all ISAPI filters for site ‘DEPLOYMENT16(11).WINDOWSAZUREPROJECT1.GUESTBOOK_WEBROLE_IN_0_WEB’.  Therefore site startup aborted.

That certainly gave me a good clue.  Why I need ‘Enable 32-bit applications’ on the application pool I have no idea since I’m compiling as ‘Any CPU’.  Compiling as x64 results in the same errors and compiling as x86 fails because I’m running on an x64 box and results in the dialog:

Every time the computer server starts it creates a new application pool with ‘Enable 32-bit applications’ set to false.  When the compute server shuts down it removes the application pool so manually resetting this value doesn’t help.  Searching around found http://blogs.msdn.com/b/zxue/archive/2011/10/31/enabling-support-for-32-bit-iis-applications-in-windows-azure.aspx.  Adding the startup task to set the IIS default to allow 32-bit applications solved my problems.  It really only needs to be run once but I just leave it in the project just in case.