You will need Azure SDK installed…

In an earlier blog post, I was bemused that the Create New Project wizard was skipping the Azure configuration screen.

It has now been confirmed that this is because the Azure SDK is required as an installation pre-requisite in order to create and configure the Azure role, and to correctly support the deployment to Azure.

Additionally, I can also confirm that there is no dependency on the Azure SDK on the Casablanca runtime libraries themselves.

Installing Azure SDK

You can download the installer from http://www.windowsazure.com/en-us/develop/downloads/. This actually fires up a Web Platform Installer which can download and install other components in addition to the Azure SDK.

figure-02

Clicking through will install the Azure SDK and any other components you have chosen to install/upgrade.

Hello World Revisited

Creating a new Casablanca Project raises the following wizard…

figure-03

… followed by …

figure-04

… which results in the following Solution Tree being created

figure-05

The Worker Role references the Deployment Project, and the Deployment project references the Casablanca Service.

…and One Last Thing

When you are building worker roles, ensure that you fire up Visual Studio with ‘Run As Administrator’.

Without Administrator privileges, you will get:

figure-06

You may also have to open up firewall ports and that kind of thing depending on how your development environment is set up…

Happy Coding!

Saying “Hello World”

So let’s dive in and start coding!

We’re assuming you’ve installed Visual Studio 2012 and the latest Casablanca SDK. We’re using the bits published on Sep 24.

The code for this project is available at http://microsoftcasablanca.codeplex.com/ in the ‘HelloWorld’ directory.

This code is quite different from the default we talked about in the video, and reflects the evolution and maturing of the Casablanca SDK itself. In fact, the next version of the Casablanca SDK may have a different default application, reflecting further improvements in the SDK. We’ll do our best to keep the blog up-to-date!

Fire up Visual Studio and create a new Casablanca project…

figure-01_thumb2

[The older bits gave us a second dialog allowing us to choose a Web or Worker role, and configure those appropriately, but the current drop seems to blitz past that dialog. I will post an explanation as soon as I find one! –John]

…which gives us the default project.

figure-02

We’ll walk through the code in a minute, but let’s run the project as is, and see what happens…

figure-03

Boom! The code compiles and runs, but obviously fails. It is time to dissect the code and understand what’s going on inside.

Let’s look at the project first, and figure out what is going on there:

First of all, the C++ compiler needs to get some header information about the Casablanca classes…

figure-04

…and the linker needs to include the Casablanca libraries…

figure-05

Pay close attention to the SDK folder, as this may change with future releases, and you will need to update your projects as and when this happens.

[I don’t know if there is a system like ‘nuget’ or ‘apm’ for Visual C++ projects, which can consume a library and keep it up-to-date in a streamlined way. It sure sounds like a good way to release Casablanca bits –John]

The actual Casablanca library is dependent on the version of Visual Studio. For VS 11 aka VS 2012, it is called ‘casablanca110.lib’. The Actors library, analogously, is contained in ‘actors110.lib’. This will be different if you’re using VS 2010.

figure-06

Similarly, the Project Configuration has a reference to a Platform Toolset, which is how the project is configured to build in a given version of Visual Studio.

figure-09

The project we are building does not create an .exe file. Rather, we are writing a library, as highlighted above. Our DLL is loaded by a host which is part of the Casablanca system. When we run the project in Visual Studio 2012, we are actually running CasablancaHost110.exe, and specifying the DLL to load in the actors_config.cfg file.

figure-07

figure-10

Therefore, there is a Post-Build step to copy it from the project directory to the deployment target directory.

figure-08

Now let’s go and get the application running:

The only material change that is required is that the endpoint needs to be specified. We could change

// Function to help find dynamically assigned port for our endpoint.
casablanca::string_t find_addr(const std::vector<casablanca::string_t> &configs)
{ 
    // The configuration data is a vector of [key1,value1,key2,value2,...,keyN,valueN] pairs.
    return U("http://*");
}

to

// Function to help find dynamically assigned port for our endpoint.
casablanca::string_t find_addr(const std::vector<casablanca::string_t> &configs)
{
    // The configuration data is a vector of [key1,value1,key2,value2,...,keyN,valueN] pairs.
    return U("http://localhost:8181");
}

and run successfully.

figure-11

The functionality we’re demonstrating above is provided by the handler for the HTTP GET verb. We’re specifying that here.

    g_listener.support(methods::GET, [](http_request message)
    {
        message.reply(http::status_codes::OK, U("Hello World!"));
        actors::log::post(actors::LOG_INFO, U("Serviced a GET request for ") + message.request_uri().to_string());
    });

What we are actually doing is providing the listener a call-back lambda which writes “Hello World” into the response of the current request.

Two key points for the future:

1) This lambda does not close over any local or instance variables, so it’s effectively a free-standing static method. We can use this information to build more complex mechanisms to respond to HTTP methods in the future

2) There are several overloads to message.reply(), and we’ll encounter a few more as we build other projects.

That’s it for now. I hope this post has provided a detailed explanation of the basic infrastructure of a Casablanca project, which helps you to understand what is going on better!

Happy Coding!