It has been a while since I have written a post on the Facebook C# SDK. For those that follow my blog and the sdk you probably know that since I have moved to Microsoft I have spent less time on the Facebook C# SDK and more time on Windows Azure. Fortunately, the Facebook C# SDK was left in the very capable hands of Prabir Shrestha and it has continued to thrive. While I haven’t been spending much time with the SDK, it is still a project I care about and as such I wanted to share our plans to keep the project moving forward.

Moving to Github

In the past few days we have been in the process of moving the Facebook C# SDK project to Github. Since the project was founded nearly two years ago we have hosted the SDK on Codeplex. Codeplex has been a great place for our project and on Codeplex we have recieved nearly 120,000 downloads. However, since the project was founded we have seen more and more projects and developers migrated to Github. Github offers a great set of collaboration tools that make managing a project like the Facebook C# SDK a breeze. We believe Github will enable the community to more easily contribute back code to the SDK through forks and pull requests. As such, the new home for the Facebook C# SDK will be at http://github.com/facebook-csharp-sdk.

Platforms and Frameworks

When the Facebook C# SDK was started we supported only .Net 4.0 Full Profile. This was primarily because the SDK relied heavily on dynamic objects and the reliance on objects found in ASP.NET libraries. Over time the SDK has evolved to support .Net 3.5, .Net 3.5 Client Profile, .Net 4.0 Client Profile, Silverlight 3, Silverlight 4, Silverlight 5, MVC 2, MVC 3, Windows Phone 7.0, Windows Phone 7.1, and most recently WinRT (Windows 8 Metro Style Apps). This is obviously a huge amount of code to write and maintain. If you have seen the code of the SDK you will notice there are lots of preprocessor directives that help us work around the differences in the various platforms. You can see an example of this in the code below.

    request.ContentType = contentType;
    if (!string.IsNullOrEmpty(etag))
        request.Headers[HttpRequestHeader.IfNoneMatch] =
             string.Concat('"', etag, '"');
#if !(SILVERLIGHT || WINRT)
    request.AutomaticDecompression =
        DecompressionMethods.GZip | DecompressionMethods.Deflate;
#endif
#if WINRT
    request.Headers[HttpRequestHeader.AcceptEncoding] = "gzip,deflate";
#endif
    if (input != null)
        request.TrySetContentLength(input.Length);
#if (!(SILVERLIGHT || WINRT) || WINDOWS_PHONE)
    request.UserAgent = "Facebook C# SDK";
#endif
    return new HttpHelper(request);

As you can see this code can be difficult to maintain, test, and debug. The good news is that through Prabir’s excellent work of abstracting the most difficult portions of this code we have been able to keep these proprocessor directives to a minimum. I will go into more details about this later in the article. What this means though is that we will do our best to keep supporting all of the current and future .Net and Windows platforms.

However, the reason I wanted to discuss this is to note that with this support there is generally a trade-off. At times we must decided whether to implement the new features of a particular platforms or maintain compatibility. So as I said, we will try to maintain compatibility with the various platforms, but moving forward we will be focusing our efforts on a few areas.

We want to make sure developers have a great experience with the Facebook C# SDK when developing web apps, Windows Phone Apps, and Windows 8 Metro Style Apps. This means that we will focus our energies on ASP.NET, Windows Phone, and WinRT support. We will be building out high quality samples and writing better documentation primarily around these three platforms and frameworks. While we aren’t explicitly not supporting the other platforms, our efforts will be minimal. We definitely welcome community contributions so if you have a great Silverlight sample please form the repo and contribute it back.

License

We have also decided to redistribute the Facebook C# SDK under the Apache 2.0 license. This license is more popular than the Ms-Pl license and is consistent with the license for  Facebook’s official SDKs and samples. While I am no lawyer, my understanding is that the Apache 2.0 license is the same in nearly every respect to Ms-Pl so this shouldn’t require any change on your part. You are still free to redistribute the SDK, use it in commercial projects, etc.

Facebook C# SDK and Web Apps

For those that have used the Facebook C# SDK in the past to develop web apps you have probably used the Facebook.Web and Facebook.Web.Mvc libraries. These libraries provide helper methods that were designed to make it easier to perform tasks such as authentication with Facebook in ASP.NET WebForms and MVC apps. Unfortunately, with the many changes to the Facebook platform, the new versions of MVC, and the new features added to the core Facebook C# SDK these libraries evolved in a way that we believe made them no so easy to use.

Instead of trying to patch and fix these libraries once again, we decided that it was time to take a step back and reevaluate how we handle web apps with the Facebook C# SDK. As such, we have decided that going forward we will be removing the Facebook.Web and Facebook.Web.Mvc libraries from the SDK. This change will happen in the 6.0 release and will not effect developers still using the 5.0 release. I will discuss our version plans later in this post in more detail.

So with the removal of the Facebook.Web and Facebook.Web.Mvc libraries you are probably wondering how will you develop Facebook Apps using ASP.NET WebForms and MVC. First, we are moving some of the more critical parts of the Facebook.Web and Facebook.Web.Mvc libraries into the core Facebook.dll. Second, we are going to be providing much higher quality samples for ASP.NET WebForms and MVC developers. Last, we intend to ship various NuGet packages that contain smaller parts of the Facebook  web libraries.

We believe the approach of having only a single Facebook.dll library will greatly simplify the  process of getting started developing your app. It will reduce the API surface and thus reduce the complexity. Additionally, we have found that developers often tweak the code in the web libraries to fit their application. For this reason we believe that shipping the web code as samples, simple NuGet packages, and general guidance will better allow developers to integrate and understand Facebook development in ASP.NET.

Now, we do understand this change may be difficult for some people. Many apps have already been built with the Facebook C# SDK and breaking changes can be tough. We have always tried to avoid breaking changes and generally have done so except in the case where Facebook introduced breaking changes. To this end we will keep updating Version 5.X of the Facebook C# SDK. We won’t be adding new feature to version 5, but we will ensure that it keeps working for you in the foreseeable future. You can find the code for version 5.x on github in a branch called ‘v5′. You can see that branch here: https://github.com/facebook-csharp-sdk/facebook-csharp-sdk/tree/v5.

Version 6.0

As mentioned earlier, we are starting work on version 6.0 of the Facebook C# SDK. Today, Prabir released Version 6.0 Alpha. This is a preview of where we are heading with the SDK. The overall goal of Version 6.0 is simplicity. We are reducing the API surface, improving the documentation, and building out better samples to make it even easier to build a Facebook app for .Net or any flavor of Windows.

Prabir has written an excellent post that goes into more detail about the technical changes to version 6.0, but below are a few highlights.

• You can now use anonymous objects as parameters. Before you had to either create a Dictionary or ExpandoObject.
• GZip/Deflate has been enabled for desktop client profiles.
• We have introduced FacebookMediaStream to replace FacebookMediaObject. You can now work with this object like a normal stream rather than converting back and forth to a byte array.
• You can now optimize your request to the graph with ETags.

Version 6.0 is an exciting step forward for Facebook developers on the Microsoft stack. We hope version 6.0 will greatly simplify your experience and help you create great Facebook apps. As I mentioned, the currently release is only an alpha release so we look forward to your feedback.

Documentation

Documentation has always been one of the biggest complaints for our developers. Admittedly, we have not always been able to keep our documents up to date to the SDK. We are hoping to correct this problem moving forward. With Prabir taking over in the last months as the lead developer on the Facebook C# SDK this has left me free to focus on other areas. Moving forward my contributions to the Facebook C# SDK will be primarily on writing documentation, tutorials, and building samples. My hope is that we can get even more developers using the Facebook C# SDK to build great Facebook apps.

When moving to Github we evaluated the various options for documentation. We thought about using the Github wiki, but in the end it felt a bit too constrained. Additionally, we are starting to split the code of the Facebook C# SDK into a variety of Github repositories. However, we didn’t want to also split up the documentation. We thought there should be a high quality, customizable, and centralized space for documentation. We decided that Github pages would work nicely for our needs. Many other projects use Github pages to build out rich and high quality documentation. You can see our early efforts at http://docs.csharpsdk.org. This is just an early start, but in the coming weeks expect to see this resource grow to provide lots of great content.

Issues and Discussions

One thing you will notice on Github is that there is no discussions area. The old Codeplex project had a discussions area where many people asked questions and provided feedback. While we know that many of you liked that model we always have tried to discourage using Codeplex for discussions because of the problems associated with threaded conversations. First, information was quickly outdated. Often times you could find a discussion in a search that would seem like it solved your problem, but the answer would be outdated. Additionally, there is no way of noting which answer is the correct answer. You had to read the entire conversation to figure out the solution (if there was even one). For these reasons we have all come to know and love StackOverflow.

Recently, Facebook showed some love for StackOverflow and moved their developer forums to http://facebook.stackoverflow.com. We have decided to do the same. Going forward we will not offer a discussion area outside of Stackoverflow. We believe this will help keep questions and answered organized, relevant, and make it easier for developers to find the answers they are looking for. We will continue to monitor and answer questions on StackOverflow.

The one issue StackOverflow does not solve is bugs. The old Codeplex discussions were often the first place a bug was reported. This made it really difficult for us to keep track of these bugs. Going forward, we are going to be using Github issues for all bugs. If you find a bug or even think you have a bug file an issue. Users can then comment on issues, track issues, and we can tag issues, and mark them as fixed as appropriate. This will make our jobs easier and help ensure that your bug/issue gets fixed as soon as possible.

Also, issues are not just for bugs. Please add feature requests, documentation request/issues, sample requests/issues to the project issues as well. Don’t worry that your issues maybe isn’t really a bug or that your request might seem too specific. We love the feedback and want your help to improve the SDK.

Utility Libraries

As we built out the Facebook C# SDK we also created several utility libraries as well. The first of these libraries is SimpleJson which is a very robust yet very simple JSON serializer. Next is HttpHelper which simplifies making HTTP requests from various .Net/Windows platforms. ReflectionUtils which is a simple set of tools for performing reflection. Finally, there is CombinationStream which allows you to represent multiple streams as a single stream. We have moved these projects to repositories under the facebook-csharp-sdk organization on Github. Feel free to use these in your libraries or applications as well.

Community Contributions

Please fork our repositories. If you aren’t familiar with Github there are some awesome documents on their website. Additionally, Tekpub has a great video on getting started with Git here. The video costs $15, but if you like learning through videos it is definitely worth it.

If you want to submit a patch, please send us a pull request. We would love help with bug fixes, documentation, samples, or anything else. With github these sort of contributions are really easy to manage so please feel free to jump in and help out.

Wrapping Up

This post ended up being a lot longer than I had planned, but I hope you are excited about where the Facebook C# SDK is heading. There were a lot of big announcements today and we have a few more exciting announcements in the next few weeks. As always, please feel free to leave feedback. We would love to hear from you.

For those who haven’t downloaded or used the social gaming toolkit yet I would encourage you to check it out. There are a lot of common patterns and tons of reusable code in the toolkit that applies for many scenarios besides the gaming space. With more and more applications relying on real-time communication, sharing, and feedback the mechanisms that are used in games can be applied to many kinds of software.

Github

Since we started this project Github has become an increasingly popular place to host the open source projects. Additionally, the Windows Azure SDKs are now open sourced and available on Github. We have seen a great deal of support from the community in this move and believe that Github is the right place to host this toolkit. Our hope is that with the amazing support Github offers for social coding such as forking, pull requests, etc. more users will be able to utilize and contribute to this project.

For those of you that have not used git or Github before I highly recommend watching the Mastering Git video on Tekpub. It costs $15, but it is worth it if you like learning though videos. If you like learning by doing and reading the instructions Github has a great set of help documentation on there site.

Cloning a Repository

Rather than simply downloading the zip or self-extracting package of the Social Gaming Toolkit, you may want to clone the repository. Doing this will make it easier to pull in changes when we release future updates. It also allows you to make local changes to the toolkit and still update code that changes in future versions without loosing all your work.

In order to clone a repository first you must have git installed on your computer. You can download git here. After you have git installed simply open the command prompt and clone the repository using the following command.

git clone git@github.com:WindowsAzure-Toolkits/wa-toolkit-games.git

Forking a Project

One of the best features of Github is that you can easily fork projects and make your own edits. If you use this toolkit and want to keep your own version simply create a fork and make your edits. Additionally, if you make a change that you think everyone would benefit from simply send a pull request and request that we add your change to our fork.

Forking a repository is easy. Simply click the fork button and select where you want the fork to live.

After you have forked the project, you can push changed to your own repository. If you have a change that you want to be added to the original repository all you have to do is send a pull request.

If your pull request is accepted, your changes will be added to the original repository for everybody to use. Feel free to add features or fix any bugs you find and send us a pull request.

As always, feel free to leave comments, feedback, or suggestions. I would love to hear how you are using the toolkit and what you think about using Github.

This is more of a note to myself, but I thought others may find it useful. You can use the Process Explorer tool that is part of SysInternals to figure out which program is holding the lock on your file and kill it. Very handy.

This release is a ‘beta’ release because it did not go through our full QA process, but all the tests pass and it should be stable. I will be releasing a stable version of the 1.2.x branch shortly that has undergone the full QA tests to ensure the quality is up to par.

The biggest changes in this release is that we are now using dependency injection throughout the solution. The toolkit uses the great Autofac library for injection, but you could easily swap out another library if you prefer.

Below you will see how we setup MVC3 and the WCF Web APIs to use Autofac for DI.

// Setup AutoFac
var builder = new ContainerBuilder();
DependancySetup(builder);
var container = builder.Build();

DependencyResolver.SetResolver(
new AutofacDependencyResolver(container));

// Setup WCF Web API Config
var config = new WebApiConfiguration();
config.EnableTestClient = true;
config.CreateInstance = ((t, i, h) =>
DependencyResolver.Current.GetService(t));
RouteTable.Routes.SetDefaultHttpConfiguration(config);

Additionally, we updated all the Nuget packages to their most recent versions. This includes the WCF Web APIs to Preview 6 and jQuery to version 1.7.1. Finally, we fixed a few bugs. There was a memory leak that some people were seeing in the worker role that should be fixed.

Download and deploy the toolkit to Windows Azure today. Let me know if you have any feedback, questions, or if you find any bugs.

Benjamin Guinebertière discovered the performance issues and was kind enough to share the results. Benjamin noticed that the response time between when the server gets a request to the time when the response begins was about 4 seconds. You can see this below by measuring the difference between “ServerGotRequest” and “ServerBeginResponse”.

Request Count:  1
Bytes Sent:     3 011	(headers:2938; body:73)
Bytes Received: 228	(headers:225; body:3)

ACTUAL PERFORMANCE
--------------
ClientConnected:    	16:33:24.848
ClientBeginRequest: 	16:33:45.247
ClientDoneRequest:   	16:33:45.247
Determine Gateway:  	0ms
DNS Lookup:           	0ms
TCP/IP Connect:      	1ms
HTTPS Handshake: 	0ms
ServerConnected:   	16:33:45.249
FiddlerBeginRequest:  	16:33:45.249
ServerGotRequest: 	16:33:45.249
ServerBeginResponse: 	16:33:49.973
ServerDoneResponse: 	16:33:49.973
ClientBeginResponse: 	16:33:49.973
ClientDoneResponse:   	16:33:49.973

Overall Elapsed:     	00:00:04.7260980

RESPONSE CODES
--------------
HTTP/200:		1

RESPONSE BYTES (by Content-Type)
--------------
       ~headers~:	225
application/json:	3

Benjamin setup and ran some tests to investigate the bottleneck. You can see how he added the traces below.

The results of this trace are show below. Notice that the action takes less than half a second to run. This meant that there was something outside of the action that was causing the problem.

After some investigation we discovered that we were calling the EnsureExists() method on every request in the game service. This was a mistake on our part and definitely not a best practice. You can see how the EnsureExists() method is called every time the repository is instantiated.

public GameRepository(
    IAzureBlobContainer gameContainer,
    IAzureBlobContainer gameQueueContainer,
    IAzureQueue skirmishGameMessageQueue,
    IAzureQueue leaveGameMessageQueue,
    IAzureBlobContainer userContainer,
    IAzureQueue inviteQueue)
{
    this.skirmishGameQueue = skirmishGameMessageQueue;
    this.leaveGameQueue = leaveGameMessageQueue;

    this.gameContainer = gameContainer;
    this.gameContainer.EnsureExist(true);

    this.gameQueueContainer = gameQueueContainer;
    this.gameQueueContainer.EnsureExist(true);

    this.userContainer = userContainer;
    this.userContainer.EnsureExist(true);

    this.inviteQueue = inviteQueue;
    this.inviteQueue.EnsureExist();
}

To fix this issue we created an EnsureExists() method on the GameRepository and moved all the queue and storage initialization methods there.

public void EnsureExist()
{
    this.gameContainer.EnsureExist(true);
    this.gameQueueContainer.EnsureExist(true);
    this.userContainer.EnsureExist(true);
    this.inviteQueue.EnsureExist();
    this.skirmishGameQueue.EnsureExist();
    this.leaveGameQueue.EnsureExist();
}

Next, we call this new method only once in our Global.asax Application_Startup. You can see that below.

protected void Application_Start()
{
    CloudStorageAccount.SetConfigurationSettingPublisher(
       (configName, configSetter) =>
    {
        string configuration = RoleEnvironment.IsAvailable ?
            RoleEnvironment
                 .GetConfigurationSettingValue(configName) :
            ConfigurationManager.AppSettings[configName];

        configSetter(configuration);
    });

    AreaRegistration.RegisterAllAreas();

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);

    FederatedAuthentication.ServiceConfigurationCreated +=
        this.OnServiceConfigurationCreated;

    // initialize blob and queue resources
    new GameRepository().EnsureExist();
    new UserRepository().EnsureExist();
}

After these changes the time for a request went down to less than 2 seconds. You can see the request and response times below.

This is a good improvement, but there are still several more changes like this we can do. I hope to release a new version in the next week or so that improves performance even more. Until then, give the updated version a try and let me know if you have any feedback.

The biggest change we have made in this release is to separate the core toolkit from the Tankster game. After we released the Tankster sample game we received a lot of feedback asking for a simpler game that developers could use to learn. To meet this need we developed two simple games, Tic-Tac-Toe and Four in a Row, and included in the toolkit. The Tankster game is now available separately as a sample built on top of the toolkit.

Below you can see the sample Tic-Tac-Toe game.

While the new games included in the toolkit are much simpler than Tankster, they still show the same core concepts. You can easily use these samples as a starting point to build out any number of types of games. Additionally, you will find that many of the core components of the game such as the leaderboard services, game command services can be used without any modification to the server side or client side code.

The features included in the new version of the Windows Azure Toolkit for Social Gaming are listed below.

• Sample Games: Tic-Tac-Toe and Four in a Row
• Game Invitations
• Leaderboards
• Game Friends
• User Profile
• Tests for both server and client code
• Reusable JavaScript libraries

In order to make the toolkit easy to setup and start using we have included our improved dependency checker and setup scripts. When you run the default setup you simply have to open the toolkit solution and run it. Everything is preconfigured to run on your local developer machine. You can read the full instructions for the setup here.
Windows Azure Toolkit for Social Games dependency checker.

In addition to running the toolkit locally you can also use the setup tools to configuration the toolkit for deployment to Windows Azure. You can read the full instructions for deploying the toolkit here. Publishing the toolkit is even easier than before with the updated Windows Azure Tools and SDK Version 1.6. You can see the updated publish dialog below.

Windows Azure Publish Dialog

As I mentioned previously, the Tankster game is still available for download as a sample. We will continue to update and release future versions of the Tankster game. For now, you can download Version 1.0 of Tankster here.

Finally, if you want to see the toolkit in action you can access it at http://watgames4.cloudapp.net/. Feel free to login and play a couple games of Tic-Tac-Toe or Four in a Row. If you use multiple browsers you can even challenge yourself to a game!

As always, please let me know if you have any comments or feedback.

To begin, lets review a few of the concepts behind the command-query pattern. First, the core principle is that every method should either send data or receive data, but never both. Second, while the pattern itself isn’t focused on building to scale it works very well for many high scale applications. By combining the command-query pattern with some of our Windows Azure best practices we can create a highly reliable and scalable system that is both easy to design and easy to maintain.

Below you will see the basic steps in the command-query process.

When you review the diagram there are a few things to note. First, is that we are performing our read operations directly from blob storage. This allows us to rely on the high scale of the Windows Azure storage systems and offload some of our HTTP requests from our Web Role.

Second, the heavy lifting of this application (Step 7) occurs in a Worker Role. This allows us to have fewer Web Roles and to ensure our web server is doing minimal work so that it is always extremely responsive.

Finally, because every command goes through our Windows Azure storage queues we can control the rate at which data is processed more easily. For example, if we had a third-party web service that could only handle say 100 requests per second and our system was processing 200 requests per second we could throttle the worker processing back to ensure we don’t overload the third party server.

Before we dive into the example, I want to setup the scenario. For the purposes of this article we are going to build a simple command-query user registration system. The user registration will contain a simple form with first name, last name, email, and date of birth. The goal will be to register the user and return a registration token to the client after the registration is successful.

To begin the user is presented with the simple registration form.

(Step 1) After the user clicks register, we submit the form using some simple ajax. The sample uses ASP.NET MVC3 for the single service, but you could use anything you like. Below you will find the controller action.

[HttpPost]
public ActionResult Register(RegisterModel model)
{
	var queue =
		new AzureQueue<UserRegistrationMessage>
		(account);
	var registrationBlob =
		new AzureBlobContainer<RegistrationTokenEntity>
		(account, true);

	var containerId = Guid.NewGuid().ToString();
	registrationBlob.Save
	(containerId, new RegistrationTokenEntity
	{
		RegistrationToken = null,
	});

	var expires = DateTime.Now.AddHours(1);

	var blobContainer = registrationBlob
		.GetSharedAccessSignature(containerId, expires);

	queue.AddMessage(new UserRegistrationMessage
	{
		DateOfBirth = model.DateOfBirth,
		Email = model.Email,
		FirstName = model.FirstName,
		LastName = model.LastName,
		ContainerId = containerId,
	});

	return Json(new { container = blobContainer });
}

(Steps 2, 3, and 4) As you can see a few things are happening here. First, we are creating a random ID for the container. Next, we save the the blob container. The container we save has our token value set to null. Finally, we create the shared access token for the blob and return the blob url to the client. Below you can see the contents of the registration result blob in its initial state.

registrationtokenentityCallback({"RegistrationToken":null})

(Step 5) After we send the register post to the server our browser will show us a waiting page. In the background the browser is continually requesting the contents of the registration result blob. If the registration token is set to null, the client continues to poll the blob. This continues indefinitely. Note, in the real world you would want to handle the situation where there is either a failure and the blob doesn’t update or the processing is taking longer than usual.

(Steps 6,7, and 8) While the client is waiting for the registration result blob to update our worker role is polling the registration queue for new registrations. In this case a new registration is in the queue so the worker role reads the message. This is the point where you would do your heavy lifting. This could be anything from saving the registration to a database, sending it to a web service, validating for duplicates, etc. After your worker role is done processing the registration it creates a token for the registration. The worker then updates the registration result blob with the token.

registrationtokenentityCallback(
   {"RegistrationToken":"665864095"}
)

After the registration result blob is updated with the registration token the client stops polling the blob and displays the result. You can see the polling script below.

var waitingId = null;
var tokenUrl = null;
$(document).ready(function () {
	step(0);
	$('#register').validate({
		submitHandler: function (form) {
			$(form).ajaxSubmit(function (result) {
				tokenUrl = result.container;
				waitingId =
                   setInterval('checkForToken()', 1000);
				step(1);
			});
		}
	})
});

function checkForToken() {
	try {
		$.ajax({
			type: "GET",
			url: tokenUrl,
			dataType: "jsonp",
			jsonpCallback: 'registrationtokenentityCallback'
		});
	} catch (ex) { }
}

function registrationtokenentityCallback(data) {
	var regToken = data.RegistrationToken;
	if (regToken != null) {
		clearInterval(waitingId);
		$('#txtToken').text(regToken);
		step(2);
	}
}

That is the entire process for this basic command query example. The result is a flexible and distributed systems that allows you to handle even the largest scale.

You can find the entire source for this example on GitHub here or download the zip file here. Additionally, you can find a deployed version at http://simplecq.cloudapp.net.

Let me know if you have any questions.

To refresh your memory on how inconvenient this used to be here are the steps you would have had to go through to make a minor CSS change and preview it while running in the local emulator.

1. Make your edit
2. Run your application either through debugging (F5) or just by running it (Ctrl+F5).
3. Wait for the Windows Azure emulator to redeploy and start
4. Load your site.
5. Repeat.

In all this process would take 30 seconds to a minute or so depending on the machine you are on. While generally not a huge deal for most work, when you are doing something like testing your CSS design or fine tuning some JavaScript this could become very inconvenient.

With the changes to the local emulator you can now edit static content while debugging your project and simply refresh the browser to see the changes. If you are just running your project (not debugging) you can actually make changes to your code as well. You can rebuild any of your project files and the changes will be immediately available to preview or test in the browser. The only thing you can not do is rebuild your entire solution.

This is a small minor change, but hopefully this helps you save a little time when developing on Windows Azure.

Register today using the promo code “azure 200” and attend SIC for only $150 (a $200 savings).

• Attend a full day of technical sessions and learn more about leveraging the cloud for mobile, web and social scenarios. View the list of confirmed Cloud Experience speakers.  Sessions include:
  • Great Mobile Apps Make Money – Intro to Cloud Experience Track
  • Mobile + Cloud, Building Mobile Applications with Windows Azure
  • Zero to Hero: Windows Phone, Android, iOS Development in the Cloud
  • Building Web Applications with Windows Azure
  • Building Social Games on Windows Azure
• Cloud Experience speakers and technical experts will be available to provide technical assistance and resources for developing, deploying and managing mobile, social and web apps in the cloud.

Seattle Interactive Conference (SIC): November 2-3, 2011, The Conference Center at WSCC

This feature is facilitated by a new section in the service definition for the roles. You can see the new section and subsections below.

<Runtime executionContext="[limited|elevated]">
  <Environment>
	 <Variable name="<variable-name>" value="<variable-value>">
		<RoleInstanceValue xpath="<xpath-to-role-environment-settings>"/>
	  </Variable>
  </Environment>
  <EntryPoint>
	 <NetFxEntryPoint assemblyName="<name-of-assembly-containing-entrypoint>" targetFrameworkVersion="<.net-framework-version>"/>
	 <ProgramEntryPoint commandLine="<application>" setReadyOnProcessStart="[true|false]" "/>
  </EntryPoint>
</Runtime>

For purposes of this example we are going to duplicate the simple NodeJS worker role that was created in a previous post, but we are going to use the new ProgramEntryPoint functionality.

To begin we create a standard Windows Azure project with a single Worker Role.

Our starting point is a standard Worker Role.

The first thing we need to do is delete the WorkerRole.cs file. We won’t be using that file or any other C# code for this project.

Next, we add our node.exe and app.js files. Make sure to set the to “Content” and “Copy if newer”.

Next, we need to tell Windows Azure to run our node application after the role starts. To do this open the ServiceDevinition.csdef file.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject11" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WorkerRole>
</ServiceDefinition>

Now add the following lines to the csdef file. These lines tell Windows Azure that your role entry point is “node.exe app.js” and that when that process starts the role is ready. Note that we also added an endpoint for NodeJS on port 80 and also removed the diagnostics import.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject11" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <Runtime executionContext="limited">
      <EntryPoint>
        <ProgramEntryPoint commandLine="node.exe app.js" setReadyOnProcessStart="true" />
      </EntryPoint>
    </Runtime>
    <Endpoints>
      <InputEndpoint name="NodeJS" protocol="tcp" port="80" />
    </Endpoints>
  </WorkerRole>
</ServiceDefinition>

Finally, we are ready to deploy our project. After you deploy the project you will see your NodeJS server running all without writing a single line of .Net code.

Another thing to note is that if your NodeJS server shuts down for any reason the Worker Role will recycle and restart the process. This way you don’t have to worry about restarting the services yourself.

While our example used NodeJS, you can use pretty much any process like this. There are also ways of using .Net code in this fashion as well to make it even easier to transition your existing application to Windows Azure.

You can see my working demo deployed here: http://simplenodejs.cloudapp.net/

Let me know how this works or if you have any questions or feedback.