Beware: WebUtility.UrlEncode vs HttpUtility.UrlEncode

Whilst experimenting with hash-based message authentication code (HMAC) request signing for a REST API I’m working on, I noticed that sometimes a signature would fail to validate server side, despite the hashing algorithm on both ends following the exact same algorithm. Upon closer inspection, it turned out that the client side URL encoding method was returning lowercase HEX values and the server side, when computing the string for hashing, was returning uppercase HEX values. Fair enough! The client was written in PHP and the server is .Net. There’s no standard requirement for the casing of url encoded values so some differences should be expected across platforms.

But would you expect that difference between two methods in the .Net framework? Experience tells you yes, but we can be hopeful all the same!

Continue reading

Debugger.Launch (.Net)

Now and then I come across a feature in .Net that I have managed to completely miss over the years. Whilst trying to figure out why a unit test was failing when running it, but passing whilst debugging, I came across this nifty feature.

Debugger.Launch will attempt to break the program execution and give you the chance to attach a debugger so you can examine what’s going on.

if (condition)
{
    Debugger.Launch();
}

If the code is already running with a debugger attached, nothing will happen when the code is hit. If you want the code to break whether or not you have a debugger attached, you can use Debugger.Break instead.

Durable Task Framework – Testing a TaskActivity

Problem

You’ve created an orchestration using the Service Bus Durable Task Framework that makes use of several tasks, but you want to be able to test out each task in isolation.

Solution

The Durable Task Test Framework provides you with a utility class that makes creating and executing a new orchestration with a single task painless and easy. Whilst this isn’t a unit test by any stretch of the imagination, the MSTest framework is perfect for running your tasks one by one and making sure everything is as it should be.

How it Works

Creating and configuring an orchestration is relatively simple, but involves quite a few lines of code. If you’re just testing a single TaskActivity, there’s no point in doing that over and over again, so I created a simple helper class to take care of the grunt work!
Continue reading

Durable Task Framework – Complex Types as Task Input Parameters

In my last post, Using Unity With The Durable Task Framework, I mentioned that I had originally overlooked the fact that the data passed to and from your TaskActivity objects in an orchestration are serialized and sent over the wire. If you’re using simple types then this isn’t a problem, but usually we want to be able to pass in something with a little more information.

Continue reading

Using Unity With The Durable Task Framework

The Durable Task Framework, created by Abhishek Lal over at Microsoft, is fantastic. It allows you to leverage the Windows Azure Service Bus to create long running, durable workflows (orchestrations) comprised of one or more sub-tasks (activities) or even sub-workflows. If you’re not familiar with the framework, take a look at it first before continuing. The above link contains a download with some documentation and samples for using the framework.

It didn’t take long for me to get up and running with an orchestration and a few tasks, although I quickly realised that I had overlooked one key point. The input and output objects for each task are serialized and transmitted over the Azure Service Bus. Initially my inputs were complex types with a unity container reference so I could share a single instance of a unity container with all of my orchestrations and tasks. Serializing the unity container is out of the question, but it wasn’t obvious to me how I could use the framework to allow me to inject my unity container in to the orchestrations and tasks.

In this post, I present a solution to configuring your setup such that you can provide your task orchestrations and activities with whatever extra data you need.

Continue reading

Azure 1.8 Upgrade and WaIISHost.exe.config woes

Having finally upgraded my Azure solution to 1.8, I immediately encountered a crash when one of my web roles was starting. My unity configuration section had disappeared and could not be loaded! I hadn’t changed anything else so had no idea what was causing the problem. All the configs looked right and were in the right place. Looking at the config URI of the config host for the ConfigurationManager, it was pointing to ‘csxDebugrolesMvcWebRole1basex64WaIISHost.exe.config’.

Finally after looking at the path for the config file and checking the contents, I saw that it was just using a standard WaIISHost.exe.config! So something changed with 1.8. A quick search led me to this helpful blog post, detailing a workaround.

When running locally, to get any settings that you needed you would have to add them to a file called WaIISHost.exe.config and off you go. But this doesn’t work for 1.8. Instead you need to name your debug config file the same as the project it’s in (or at least the name of the generated assembly of that project). So if you’re creating an assembly called ‘MyWebRoleAssembly.dll’ then the config file should be ‘MyWebRoleAssembly.dll.config’.

Now the config URI is pointing to csxDebugrolesMvcWebRole1approotbinMvcWebRole1.dll.config. Much better!

ViewStubs and root elements

This might seem like a very obvious thing to most, but for me it was not. In some code I’ve inherited, ViewStub is used a great deal and works well, except for when I was trying to resolve the root element of the inflated content. For example the following (greatly simplified) setup:

Host view XML

<LinearLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/content"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent" 
    android:orientation="vertical">
 
    <RelativeLayout
        android:layout_width="fill_parent"
        android:layout_height="0dp"
        android:layout_weight="1">

	    <ViewStub 
	        android:id="@id/stub_import"
                android:inflatedId="@id/content_import"
                android:layout="@layout/splash"
                android:layout_width="fill_parent"
                android:layout_height="fill_parent" />

    </RelativeLayout>
</LinearLayout>
</pre>

<!--more-->

<h4>Content View XML</h4>
<pre class="prettyprint lang-xml">
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="vertical"
    android:id="@+id/root_control">

    <LinearLayout
        android:id="@+id/some_sub_control"
        android:layout_width="fill_parent"
	android:layout_height="wrap_content"
	android:orientation="vertical">

    </LinearLayout>
</LinearLayout>

Then in the your Activity:

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    ViewStub stub = (ViewStub)this.findViewById(R.id.stub_import);
    stub.setInflatedId(R.id.content_import);
    stub.setLayoutResource(R.layout.content);
    stub.inflate();

    // rootElement will be null!!
    LinearLayout rootElement = (LinearLayout)this.findViewById(R.id.root_control);

    // subControl holds a reference to the expected control.
    LinearLayout subControl = (LinearLayout)this.findViewById(R.id.some_sub_control);
}

So what’s going on here? Well three things really! Mostly that I should pay attention more and not rush so much. Those small details you can easily overlook often turn out to be the cause of your problems. The other two things are pretty much the same thing:


android:inflatedId="@id/content_import"

// From the Java code
stub.setInflatedId(R.id.content_import);

So here, they’re instructing the ViewStub to give the inflated content a new id once the ViewStub has been replaced. Great! Why they did it twice is anyone’s guess but that was the problem. Remove that code and hey presto! It works as expected. Also, another handy tip is that you can also get a reference to the inflated content via the result of the call to inflate().

LinearLayout rootElement = (LinearLayout)stub.inflate();
// Gets you the same thing as...
LinearLayout rootElement = (LinearLayout)this.findViewById(R.id.root_control);

Serving .JSON Files in Azure gives a 404

I just came across a problem when implementing some lovely localization in Javascript. Using the i18next library, it requires that all of your translations be stored in .json files. No problem! Everything runs fine locally (of course) but once I had pushed to my staging environment, those .json files couldn’t be found! When accessing the files directly, I was greeted with a 404. Because everything worked locally I knew the paths were just fine, so after a quick Google this looked to be a MIME issue. IIS didn’t know what to do with these static files so just threw up a 404.

The first solution was to add the missing MIME types to my web.config, like so:

<system.webServer>
  <staticContent>
    <remove fileExtension=".json" />
    <mimeMap fileExtension=".json" mimeType="application/json; charset=UTF-8" />
 </staticContent>
</system.webServer>

Redeploy, refresh. Now I had a bunch of errors with other scripts that were working fine, almost every script was throwing a 500 error. More Googling and cussing and publishing and refreshing and nothing. Eventually I spotted a small note on someone’s post on StackOverflow where they mentioned changing the BuildAction for the .json files to ‘Content‘ instead of ‘None’. I’m not sure what affect this has and will look in to it another time, but for now it solves my problem and hopefully yours too!

.Net 4.0 Printing Made Easy – Part 1 – Introduction

Welcome to the fist part of my ‘.Net 4.0 Printing Made Easy’ series. In this part we’ll take a quick look at the .Net printing support, what it does do for us and just as important, what it doesn’t do for us.

In .Net 3.0 we were given a great new printing framework based around XPS documents. This immediately opened up a world of vector based printing where you can print your WPF vector controls and have them appear as sharp as ever, or if printing to an XPS or PDF document, your print out will be preserved in its full vector glory. What makes this even better is that you as a developer don’t have to worry about any of this, you just send your data off to one of the many methods provided and the rest is done for you. There are of course some instances where you can’t print raw vector data out and need to handled rasterised data. This too is very simple and there are a few tricks you can use to make it even easier.

Continue reading