Exception lors de la suppression d'un message de la file d'attente Azure?

Question

Je trempe mes orteils dans Windows Azure, et je cours dans quelque chose qui doit être simple, mais je ne peux pas le voir.

Je possède 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 « testQueue.DeleteMessage (reçu) » méthode, 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 dans les entrailles du SDK Azure.

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

Quelqu'un a déjà vu quelque chose comme ça?

Answer 1

J'ai compris ce qui se passait. Le code en question fonctionnait dans un faisceau de test xUnit. Il s'avère que le runner xUnit ne configure pas un domaine avec un chemin de fichier de configuration par défaut. System.UriBuilder frappe maintenant le fichier de configuration, donc il explose.

La solution de contournement consistait à ajouter un app.config vide au projet de test. Maintenant ça marche.

ARGH!