Jun 30

Solving partitionkey problems using Windows Azure tables that runs locally fine but errors “One of the request inputs is out of range” when published

I’ve made a quite simple WCF (Windows Communications Foundation) project using Windows Azure Tables with a DateTime string in the partitionkey. And it really works fine locally. Even if I skip the storage emulator, and really put the data in Azure Tables it still works fine. The WCF service is run locally on my development computer.

But as soon as I publish the WCF service to Windows Azure I get the error:

One of the request inputs is out of range

Quite strange, because the WCF (using the real Azure Tables) works great, storing the information correctly to the Table storage, which is proved by the Azure Storage Explorer. So: What is the difference between my development computer and Windows Azure?

I used the DateTime.UtcNow.ToString() to populate the partitionkey. This is because I wanted to balance the load over time when reading the rows.  My developer computer is localized NL-nl, that uses a dash ‘-‘ to separate day-month-year. Because I use this function as part of the partitionkey, there is a ‘-‘ inserted when I run the service locally. But the Windows Azure computer uses a month/day/year notation, so when running on Windows Azure the function produces a ‘/’ as part of the partitionkey.

And the ‘/’ is not allowed as part of the partitionkey.

So the solution is to comply with the Windows Azure Table Service Data Model naming convention and leave out the ‘/’ as part of the partiotionkey.

Please comment if this was usefull to you.



May 14

Using asynchronous programming (WCF) in a Windows Phone background agent (periodic task).

Sometimes you want to have a background agent that does some stuff for you periodically on the background. If that agent has to consume a WCF (Windows Communications Foundation) service you can run into some troubles, due to the asynchronous programming model that is uses in the Windows Phone.

In my occaisson I wanted to asynchronously add a record a Windows Azure database that is accessible through my WCF service. While debugging everyting seems to be executed correctly, but on thing: the oncompleted event never occured and no record was addedd to the database. But also: no error to debug on.

So what was wrong? When the background agent is run, you have to let the OS know when it is finished. You do that by executing NotifyComplete(). I had this statement right after the statement that called the WCF service. It seems that you have to wait until the service raises the completed event.

So you have to put the NotifyCompleted() statement in the completed event that is raised when the WCF async service returns it result.

Simple once you know IT.

May 09

How to solve “There was no endpoint listening at …” on Windows Phone 7 connecting to Azure WCF service

My WCF Service works fine when I test it with wcftest. All the endpoints are exposed as intended. But when I try to consuming the service on my Windows Phone 7 I get the message:

There was no endpoint listening at http://myservice.cloudapp.net/GeneralApplicationServices.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

InnerException: {“The remote server returned an error: NotFound.”}

Everything in the code looked fine, wcftest is also working OK, so what could be the problem? After extensive searching with no decent result I made a new wp7 app with the same service reference. And guess what? It worked right away.

So what was the difference? After I remmed out all the non relevant code, I was left with basically 4 lines of code:

  1. initialize the context: context = newAppActivityClient();AppActivityClient 
  2.  add the eventhandler for the async service: context.AddCompleted += new EventHandler<AddCompletedEventArgs>(context_AddCompleted)
  3. Handle the Async event: MessageBox.Show(“It worked”)
  4. Call the service: context.AddAsync(Guid.NewGuid(),Guid.NewGuid(),Guid.NewGuid(),567,”Dit is de data2″,10,6)

Still not working. This were exactly the four lines of code in my newly created project that indeed was working very well. So no difference in the source code. I also used a fiex GUID (FD9EDB38-864D-49F2-A8AE-B6439AB3362D), no difference, I examined all other files in the solution….. And there was it, just in front of me:

The solution:

Add the networking capability to the WMAppManifest.xml. The code is:

<Capability Name=”ID_CAP_NETWORKING”/>

Normally this capability is default in the manifest. But I removed it, because the first version of my app didn’t need any networking capabilities.

Simple, once you now IT.


May 08

Error in WCF service on Azure: ‘The remote name could not be resolved’. Locally everything works fine.

I have a WCF service that works fine on my local machine. When I deploy it to Windows Azure and do an Invoke with wcftest I get the message:

Failed to invoke the service. Possible causes: The service is offline or inaccessible; the client-side configuration does not match the proxy; the existing proxy is invalid. Refer to the stack trace for more detail. You can try to recover by starting a new proxy, restoring to default configuration, or refreshing the service.

There was no endpoint listening at http://rd00155d3ad8c4/GeneralApplicationServices.svc/AppActivity that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Inner Exception: The remote name could not be resolved: ‘rd00155d3ad8c4′    at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)    at System.Net.HttpWebRequest.GetRequestStream()    at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput.GetOutputStream()

The strange thing is that I don’t know where rd00155d3ad8c4 is coming from in the URI. It should be something like http://mysite.cloudapp.net. I’ve searched the entire solution for this strange string, but no luck. The service seems to be exposed correctly at http://mysite.cloudapp.net/GeneralApplicationServices.svc

After extensive searching this seems to be a bug in .NET 3.5 that is resolved through a hotfix in .NET 4.0 but still requires you to set useRequestHeadersForMetadataAddress as a servicebehavior in your web.config file. It should be something like this:

<behavior name=”MexGet”>
<serviceMetadata httpGetEnabled=”true”  />
<add scheme=”http” port=”81″ />

This setting is necessary in a load balanced environment. And of course Windows Azure is a load balanced environment. If you use .NET 3.5 you can download the hotfix.

You can find more detailled information in Cloud Computing with the Windows Azure Platform Publisher: Wrox

I’ll hope this post keeps you from searching 3 three days, as I did :-(

Simple once you know IT.