When browsing to a WCF endpoint hosted in an Azure web role you normally get back a web page for the service showing the location of the individual node / web role that is serving up your request (seen blurred out here) instead of the actual endpoint.

This isn’t great as you don’t want everyone knowing about your internal system and especially the URL of one of your web roles, with which they could do who know what.

This can easily be fixed with this patch for WCF that will now show the expected endpoint. This endpoint is actually the address of the load balancer that will then forward your request to an web role.

Once the patch is download and installed you can then simply add the following xml snippet into your behaviour for the WCF service:

With this snippet added into your web.config you can browse back to the previous service and will now see that the correct URL is displayed for your service.

I have recently been asked a number of questions both internally and from customers about when you will be billed for Azure usage.

As Eric Nelson’s recent post describes, if you suspend a service you will still be paying this is due to the fact you will still have your application deployed on the server ready to start again. With your application utilizing the server others will not be able to provision its usage.

When you select delete you will stop paying as you will no longer have servers provisioned for your application and the recourses will be freed up for others to use.

Memcached is a distributed cache used to help speeding up large scale web applications by taking pressure off the database. Memcached is used by many of the internets biggest sites, including Twitter, Wikipedia, and YouTube to name just a few.

A distributed cache is one of the things that I’ve been hoping to see released for Windows Azure for quite a while, and I am hoping that AppFabric Caching will make the move to the cloud in the coming year. However, until that happens I was determined to find a way to get a distributed cache and this great Windows Azure Memcached sample showed me how.

“Brad Fitzpatrick, I love your ass!"

Sorry, I just couldn’t help myself. I found this great quote on in the Caching Story page of the Memcached wiki.

After installing and setting up Memcached you will be able to cache any data, including data that is retrieved from your database so that the next time you need it you can get it from cache and not need to re-query your database. Therefore, reduce the pressure on the database and earning the love of our DBA.

Azure Memcached sample

You can download the sample code for Windows Azure from the codeplex download page you then need to download a Windows friendly version of Memcached (here is where I got mine). With the sample code from codeplex just add the memcached exe to your worker roles. You will now be able to run the sample code either on the dev fabric or in the cloud.

One thing to watch out for, the Memcached exe’s seem to take an age to get up and running. I actually left mine to set up overnight (glad I’m still on a CTP account) as the Memcached Worker Roles were all showing busy for a long time, during which the sample would not work correctly.

After the servers have started up you can easily set and retrieve values from the cache as shown in the screenshots below.

Under the hood

Now that we have got our distributed cache working lets have a look how the sample code works.

Memcached Server

On the server side we set up an internal endpoint that will be used to connect the clients to the Memcached server. When the node is created we launch the Memcached server that we downloaded before, passing in the nodes cache size and endpoint as arguments.

          string arguments = 	"-m " + cacheSize +
				" -l " + endpoint.Address +
				" -p " + endpoint.Port;

            ProcessStartInfo startInfo = new ProcessStartInfo();
            startInfo.CreateNoWindow = false;
            startInfo.UseShellExecute = false;
            startInfo.FileName = "memcached.exe";
            startInfo.WindowStyle = ProcessWindowStyle.Hidden;
            startInfo.Arguments = arguments;

This node is now exposing a Memcached server, which can be used by the client nodes to cache data.

Utilizing Memcached – Clients

The client node in the example looks a lot more complicated that it actually is. The most important part is adding the configuration for our memcached client within the settings tab of the node.

Then comes the interesting bit using the Enyim caching library (others libraries are available) and creating a MemcachedClient object, allowing us to get and set objects in the cache.

Each time a new MemcacedClient is needed the program loads a configuration based upon the data within the settings (picture above) and then loops through all of the instances of memcached servers nodes that we are running in our hosted service getting their endpoint, to add this to the configuration of available servers.

            _endpoints = new Dictionary();

            foreach (var endpoint in RoleEnvironment.Roles[_memcachedRoleName].Instances)
            {
                foreach (var epi in endpoint.InstanceEndpoints)
                  {
                    if (epi.Key == "memcached")
                    {

                        _endpoints.Add(epi.Value.RoleInstance.Id.ToString(),epi.Value.IPEndpoint);
                    }
                }
            }

Now that the connection to our memcached nodes we can use the caching library to set and get values in the cache.

AzureMemcached.Client.Store(StoreMode.Set, key, value);          

AzureMemcached.Client.Get(key);

With this code we now have distributed caching on Windows Azure, and can use the example to build out much bigger applications.  

Registration for Developer Developer Developer 2010 will open later today at 13:00, but you better be quick to sign up as last years tickets were snapped up in a few hours.

This year boasts some of the best sessions that I have seen in a while with proposed (corrected by @plip) presentations on a wide range of subjects from MonoTouch by Chris Hardy, .NET development for the iPhone, right through to Jon Skeet submitting a  number of sessions including one on NodaTime and C# 4.0 and a UK conference just wouldn’t be complete without Seb giving a talk on Open Rasta.

Go to the DDD site here, view the sessions and register.

Now I can see why some people have been raving about Google’s Chrome browser, it not only serves up the internet … it can teleport goats!!

Want to transport some Goats Yourself?

Follow these easy repro steps:

0. Download and launch Google Chrome
1. Shift + Esc
2. Right click on any process
3. Select “Goats teleported”
4. Uninstall Chrome

(note: I have taken the liberty of adding extra steps to the repro)

The official bug (Issue 31482 – Huge amount of goats teleported) has some great comments and definitely shows that geeks know how to have a laugh.

I stumbled upon this little gem thanks to Barry Dorrans (@blowdart).

In a previous post I mentioned using the Service Management API sample library to call out to the Azure fabric from within a C# application.

The natural progression from here was to get the code working from within a web or worker role instance hosted within the cloud. Using a web role, I used the OnStart method to set up a IServiceManagent class that could then be shared with the remainder of the classes within the role.

When tracing the hosted services from either the OnStart method or from within default.aspx.cs I could successfully print out all of the services within my account. However, when I set up a WCF REST service to return these hosted services in an array I started to get an error with the connection to the Management API. Giving a argument error stating that a property with the name “httpRequest” is not present. This was even happening when I was using exactly the same code as I was elsewhere.

After a push in the right direction from Simon Davies we found out  that the issue was in the WCF REST service already having an OperationContext from the original REST call before calling out to the Service Management API. This handy blog post, help solve all my issues, all that was needed was to create a second OperationalContext before calling the management service.

using(new OperationContextScope((IContextChannel)WebRole.serviceManagement))
{
  var hostedServices = WebRole.serviceManagement.ListHostedServices(subscriberID);

  foreach (HostedService service in hostedServices)
  {
    Trace.TraceInformation("Hosted Service: {0}", service.ServiceName);
  }
}
            

Ta dar … everything now works, we can use the above code snippet to retrieve back all our hosted services by calling our own web role.

One things I am constantly falling into the trap of doing is naming my message queues using camel casing when naming my queues giving names such as “mySuperQueue” which ends up throwing the below error. Which because it gives us very little information tends to lead to me debugging the code for a while before I remember that capitals and other special characters are not allowed in queue names.

The rules on naming queue are:

A queue name must start with a letter or number, and may contain only letters, numbers, and the dash (-) character.

The first and last letters in the queue name must be alphanumeric. The dash (-) character may not be the first or last letter.

All letters in a queue name must be lowercase.

A queue name must be from 3 through 63 characters long.

So to try and stop myself making this mistake in the future I have put together a quick code snippet that allows me to pass in the proposed queue name and view if it is valid.

            bool match = false;
            var exp = new Regex(@"^[0-9a-z]+-*[0-9a-z]+$");

            if (exp.IsMatch(input))
            {
                if (input.Length >= 3 && input.Length <= 63)
                {
                    match = true;
                    Console.ForegroundColor = ConsoleColor.Green;
                    Console.WriteLine("VALID Queue Name: {0}", input);
                }
            }

            if (!match)
            {
                Console.ForegroundColor = ConsoleColor.Red;
                Console.WriteLine("INVALID Queue Name: {0}", input);
            }

Hopefully this small snippet will be able to save me a lot of time by instantly flagging a queue name that is invalid, then either notifying the user before the queues are created or even fixing the queue name so that it is in a correct format.

I previously published an article showing how the Service Management API and the csmanage tool could be used to aid in the deployment of your Windows Azure application as part of your daily build.

Once I had began playing with the API’s, I wanted to be able to use them within an application so that I would be able to create something like a simple dashboard for managing your services without calling to csmanage all of the time.

I started to do this by building up the REST requests within the application and performing a HTTP GET from my application. However, I then found this very handy library from Microsoft that has done the leg work around all of the calls needed for the service API (almost like a Blue Peter, here’s one I made earlier).

You can see in the code below that to utilize the library, we first need to create a ServiceManagementHelper class. This class will then be used to call out to each of the available services. To create this helper class we need to pass in a reference to an endpoint in app.config (show further down) and a reference to the certificate uploaded to manage our service.

namespace serviceManagementConsoleApplication
{
    class Program
    {
        private const string subscriberID = "...";

        static void Main(string[] args)
        {
            var serviceManagment = ServiceManagementHelper.CreateServiceManagementChannel				   ("WindowsAzureEndPoint", new X509Certificate2("insertcert"));

 	    var x = serviceManagment.ListHostedServices(subscriberID);

            foreach (HostedService s in x)
            {
                Console.WriteLine(s.ServiceName);
            }

            Console.Read();
        }
    }
}

As you can see in the code once the helper is set up we can call any of the services such as ListHostedServices which will return an list containing each service we have hosted in our account.

As mentioned above we need to have an endpoint set up for the helper class to call out to, the configuration for this is shown below.

With the configuration set up and the sample service management API library, we can easily get any application to call out and manage our cloud services.

Download the sample library here.

This afternoon I noticed that I was able to select Europe and Asia regions to deploy my Azure application.

I have yet to see official word of these locations being available, but this must be for the move from CTP to production.

Bad news guys … I am unable to present at the upcoming NxtGen Oxford. I have just started a new and exciting project up in Leeds and therefore will be unable to get back down to Oxford in time for presentation. It does mean I will have even more content for my presentation when I eventually do get the opportunity to do it.

However, every cloud (pun intended) has a silver lining  and this one comes in the shape of Dave McMahon who will be stepping in for me to give a great presentation on SharePoint:

SharePoint Starting Point

SharePoint is one of Microsoft’s biggest success stories. It’s grown from a Document Management system into an Enterprise Platform capable of being scaled out to serve thousands of users, provide a platform for BI, CMS, EDM and a whole bunch of other stuff. But how exactly does it work?

I would like to say a big thank you to Dave for doing this at such short notice.

That’s not all we still have Ben Nunney presenting on “The Power of PowerShell” which promises to be a great talk, showing how developers can really get the most out of PowerShell.

Finally, if anyone is around Leeds and fancies a cheeky pint, let me know