views:

25

answers:

1

I'm dipping my toes into Windows Azure, and I'm running into something that has to be simple, but I just can't see it.

I have this small test to play with Azure queues:

public void CanPublishSillyLittleMessageOnQueue()
{
    var queueClient = CloudStorageAccount.DevelopmentStorageAccount.CreateCloudQueueClient();
    var testQueue = queueClient.GetQueueReference("testqueue1");

    testQueue.CreateIfNotExist();
    var message = new CloudQueueMessage("This is a test");
    testQueue.AddMessage(message);

    CloudQueueMessage received;

    int sleepCount = 0;
    while((received = testQueue.GetMessage()) == null)
    {
        ++sleepCount;
        Thread.Sleep(25);
    }
    testQueue.DeleteMessage(received);

    Assert.Equal(message.AsString, received.AsString);
}

It sends the message just fine - I can see it in the SQL table. However, when it hits the "testQueue.DeleteMessage(received)" method, I get this:

TestCase 'AzureExploratory.PlayingWithQueues.CanPublishSillyLittleMessageOnQueue'
failed: System.ArgumentNullException : Value cannot be null.
Parameter name: str
    at Microsoft.WindowsAzure.StorageClient.Tasks.Task`1.get_Result()
    at Microsoft.WindowsAzure.StorageClient.Tasks.Task`1.ExecuteAndWait()
    at Microsoft.WindowsAzure.StorageClient.TaskImplHelper.ExecuteImplWithRetry(Func`1 impl, RetryPolicy policy)
    at Microsoft.WindowsAzure.StorageClient.CloudQueue.DeleteMessage(CloudQueueMessage message)
    PlayingWithQueues.cs(75,0): at AzureExploratory.PlayingWithQueues.CanPublishSillyLittleMessageOnQueue()

which appears to be a failure somewhere down inside the guts of the Azure SDK.

I'm using VS 2010, .NET 4.0, the Azure SDK V1.2, 64-bit Win 7. The developer store service is running; I can see the messages go into the queue, I just can't delete them.

Anyone ever seen anything like this?

+1  A: 

I figured out what's going on. The code in question was running in a xUnit test harness. Turns out that the xUnit runner doesn't set up an appdomain with a config file path by default. System.UriBuilder now hits the config file, so it blows up.

The workaround was to add an empty app.config to the test project. Now it works.

ARGH!

Chris Tavares
The xUnit team fixed this one yesterday - http://xunit.codeplex.com/Thread/View.aspx?ThreadId=226567
Chris Tavares