Eccezione durante l'eliminazione di un messaggio dalla coda Azure?

Question

sto immergendo le dita dei piedi in Windows Azure, e sto correndo in qualcosa che deve essere semplice, ma non riesco proprio a vederlo.

ho questo piccolo test di giocare con le code 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);
}

Si invia il messaggio più che bene - posso vederlo nella tabella SQL. Tuttavia, quando si colpisce il "testQueue.DeleteMessage (ricevuto)" metodo, ottengo questo:

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

, che sembra essere un qualche fallimento giù dentro le viscere della Azure SDK.

Sto utilizzando VS 2010, .NET 4.0, l'Azure SDK V1.2, 64 bit Win 7. Il servizio lo sviluppatore del negozio è in esecuzione; Riesco a vedere i messaggi vanno in coda, non riesco proprio a cancellarli.

Chiunque abbia mai visto nulla di simile?

Answer 1

ho capito cosa sta succedendo. Il codice in questione è stato eseguito in un test harness xUnit. Scopre che il corridore xUnit non imposta un AppDomain con un percorso di file di configurazione di default. System.UriBuilder ora colpisce il file di configurazione, in modo che fa saltare in aria.

La soluzione era quella di aggiungere un app.config vuoto per il progetto di test. Ora funziona.

ARGH!