CloudStorageAccount storageAccount = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"));
CloudQueueClient cloudQueueClient = storageAccount.CreateCloudQueueClient();
CloudQueue cloudQueue = cloudQueueClient.GetQueueReference("test-queue");
cloudQueue.CreateIfNotExists();

Please rememeber that queue names are quite fussy. You need to use lowecase names with hypens as seperators.
It does not like brackets or underscores.
This is especially important if you use the environment name in the queue name to allow shared storage accounts across a dev team.

Here is a great project that seems to solve one of the big problems with Azure Queues. There is a throughput limit that will prevent a queue from handling more than 500 transactions per second. The recommended solution is to shard the queues (although other solutions include moving to a vm based queing system or using an alternative queue such as RabbitMQ or ZeroMQ).

This is an example of microsoft not being very careful when releasing software. Key features get broken and priority is not given to fixing them.

In this case there is a mismatch between the recommended logging approach (log everything to the local event log and use DiagnosticMonitor to send to table storage) and the latest storage account bits. This shows a serious lack of attention to detail.
Azure is meant to be the bread and butter of microsoft. It should be a wonderful platform. However there has been too little attention given to things like documentation and sample code.

Update: They have now fixed this with SDK v2.0, looks like someone had jumped the gun with releasing new bits.

http://msdn.microsoft.com/en-us/library/windowsazure/gg433135

http://blog.syntaxc4.net/post/2012/02/01/windows-azure-storage-emulator-account-name-and-key.aspx

AccountName

devstoreaccount1

AccountKey

Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==

Here is a link to an article on efficiently querying azure diagnostics table.

The key piece of information is that the partitionkey is “0” + log capture time in ticks.

git clone https://github.com/WindowsAzure/azure-sdk-tools.git

Note that you need to use the command line git since tortoise git does not do https.

Here is a great article on querying the WadLogsTable

Here is the port conflict article that will prevent the compute emulator from starting.

This is however an old sdk and does not explain how to detect which ports are in use.

This is how to do it:

netstat -ano | find /i “listening”

The emulator uses the following ports:

15095, 15096, 15097, 15098, 15099, or 15100

As of the October 2012 SDK the emulator runs from the following location:

C:Program FilesMicrosoft SDKsWindows AzureEmulatordevfabric

Here is the given advice to correct this (not yet tested):

1. In the DevFc.exe.config file, locate the add port entry that contains the conflicting port value and modify the value to use a non-conflicting port. The DevFc.exe.config file entries that can be affected are:
   • <add key=”ManagementServicePort” value=”15095″ />
   • <add key=”RepositoryServicePort” value=”15096″ />
   • <add key=”AgentCallbackPort” value=”15097″ />
   • <add key=”AgentPort” value=”15098″ />
   • <add key=”PxeResponderPort” value=”15100″ />
2. In the DfService.exe.config file, locate the dfservice element and modify the ManagementServicePort or RepositoryServicePort attribute to use a non-conflicting port.
   • <dfservice ManagementServicePort=”15095″ RepositoryServicePort=”15096″ />
3. Press F5 to restart the application or run the CSRun Command-Line Tool.

However a restart of my machine cured this issue.

I suspect that it was caused by using on of the powershell scripts to start the emulator.