Monthly Archives: June 2009

I ran into an issue with a Windows Azure project created from scratch in Visual Studio 2010 Beta 1 with the May CTP of the Windows Azure Tools.Azure_Logo

When trying to create tables in the local development storage, I got the error “Invalid image format”. This issue occurred both from VS (using the Create Test Storage Tables option) and when running DevTableGen.exe manually from a command prompt. It didn’t occur when doing the same in VS2008.

DevTableGen.exe is a tool from the Windows Azure SDK. This tools loads an assembly, reflects over it and then tries to create tables in the local development storage.

After some head scratching I figured out the cause: in Dev10 the default target platform for executables was changed from AnyCPU to x86. In Beta 1 a bug snuck in, so that x86 is also the default for class libraries (DLLs). This will be changed back to AnyCPU in Beta 2. This blog post from Rick Byers has a lot of detail on why the default has changed.

DevTableGen.exe is an AnyCPU executable, so it will run as a 64-bit process on an 64-bit version of Windows. As such it cannot load assemblies marked as 32-bit only when run on 64-bit Windows. The solution was to change the assembly to AnyCPU.

This issue would have been prevented if DevTableGen.exe was marked as 32-bit only. That way it would always run in a 32-bit process and could load x86 and AnyCPU assemblies. According to the blog post linked to above, it is now considered best practice to explicitly mark an executable as x86 or x64. For most applications x86 is the best option.

I’ve suggested this change to the product team.

Update: I've been informed that DevTableGen.exe will not be changed. This is because this issue is temporary and will go away when VS2010 Beta 2 is released. Also the web role and worker role processes in Windows Azure are 64-bit, so trying to load x86 assemblies will fail anyway. So if you use Beta 1 make sure you explicitly change the platform for any assemblies you create for the cloud to AnyCPU.

1 Comment

Ever since the internal unveiling of Windows Azure as project “Red Dog” at our internal TechReady conference in July 2008, I’ve been very interested in this Software+Services platform.

Technical strategist Steve Marx from the Windows Azure team recently released a cool sample app called The CIA Pickup. He put up a demonstration video and a nice architecture drawing of this app up on his blog.

TheCiaPickup_Logo

Using the app you can pretend to be a CIA agent and hand out a phone number and your agent id to someone. When this person calls this number, they are greeted by an automated message that says they are connected to the CIA automated phone system and are requested to enter your agent id. After they have entered your id, you will receive their caller id via e-mail.

Seeing that 90% of the IT population seems to be male of which probably 95% is straight, I can see why the app is slightly biased in helping men picking up phone numbers of women. But if you don’t like this, you can always pick up the source and change the text. Which I did. Not to change the text, but to make some improvements so that I could run the app in my own Windows Azure playground in the cloud.

For example, the SMTP port of my e-mail service is not the standard port 25. I made this port configurable and in the process I found out that the app has to be deployed with full trust in order to be able to use the non standard port. I added logging to trouble shoot issues like this and made some security improvements.

I contributed these improvements back to Steve and he has gracefully credited me in his second blog post.

The CIA Pickup app is a great example of the power of combining different off-the-shelf services like SMTP providers, telephony service Twilio, Azure Table and Queue Storage, Windows Live ID Authentication with custom code, C# and ASP.NET MVC, running in the cloud. You can literally have this up-and-running within a couple of hours, including the creation of all necessary accounts.

So go try it out! You don’t need to deploy the app yourself to do this. You can use Steve’s deployment for this. Although it uses the US phone number +1 (866) 961-1673, it works when dialing from the Netherlands. If you want to get in touch, use my agent id 86674 😉

A couple of months ago I received a license for NDepend to evaluate its usefulness. I was already convinced that NDepend is a very useful tool. But up to now, I hadn’t put NDepend to good use in a way that I could blog about it.

Today I decided to bite the bullet and put my own pet project FlickrMetadataSynchr up for analysis. Its source code is available on CodePlex.

NDepend analyses managed code for several quality aspects, like cyclomatic complexity, coupling and unused code. In a way it resembles FxCop, but it also does a lot more in terms of reporting. NDepend also is a lot more flexible in letting you query your code base. For this it uses its own SQL variant called Code Query Language (CQL). For example, you could enter this query into the tool

SELECT METHODS WHERE NbLinesOfCode > 30 AND IsPublic

and NDepend will show you all public methods whose number of lines of code exceeds 30.

Just by using the standard settings, NDepend gives you truckloads of information that point to areas with potential code smell. The report has inline comments that explain why it selects stuff and points out possible false positives for which it is okay to ignore the warning.

You can find my NDepend results here if you want to see what such a report looks like.

Starting with those results from top to bottom, I started refactoring my code to improve the quality. For example, splitting up methods to:

  • Reduce cyclomatic complexity
  • Reduce the number of IL instructions in a method
  • Reduce the number of local variables in a method
  • Increase the comment to code ratio

This should increase maintainability of the code.

Go check out this tool if you are interested in improving the quality of your .NET code or if you are tasked with reviewing somebody else’s code.