Exception lorsque le message suppression de la file d'attente Azure?

Question

Je trempant mes orteils dans Windows Azure, et je suis en cours d'exécution en quelque chose qui doit être simple, mais je ne peux pas le voir.

J'ai ce petit test pour jouer avec les files d'attente Azure:

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);
}

Il envoie le message très bien - je peux le voir dans la table SQL. Cependant, quand il frappe la méthode « testQueue.DeleteMessage (reçu) », je reçois ceci:

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()

qui semble être un échec quelque part à l'intérieur de les entrailles du SDK Azure.

J'utilise VS 2010, .NET 4.0, le SDK Azure V1.2, 64 bits Win 7. Le service de banque de développement est en cours d'exécution; Je peux voir les messages vont dans la file d'attente, je ne peux pas les supprimer.

Tout le monde jamais rien vu comme ça?

Answer 1

Je compris ce qui se passe. Le code en question est en cours d'exécution dans un harnais de test xUnit. Avère que le coureur xUnit n'a pas mis en place un appdomain avec un chemin de fichier de configuration par défaut. System.UriBuilder frappe maintenant le fichier de configuration, il explose.

La solution était d'ajouter un app.config vide au projet de test. Maintenant, cela fonctionne.

ARGH!