Patrick Godwin's Blog-O-Rama!

Developers, developers, developers!

How I wrote and deployed a cloud powered app in just six days

So, I was sitting around on the Friday before Labor Day, when suddenly, I thought: “I should make an app!”. And six days later, I had the app published:


But how did I build a cloud powered Windows 8 App in just six days? It was actually really easy, thanks to the new Windows Azure Mobile Services preview.

If you don’t know what Windows Azure Mobile Services are, I highly recommend you check it out. It enables you, the app developer, to develop a rich, cloud powered application without building any of your own infrastructure. If you need a SQL database to store data? Mobile Services takes care of that for you. Need to do push notifications? Azure can take care of that too.

Essentially, you build your data model all in your application. You simply mark your class with the new DataTable attribute, and mark the members with DataMember, and Azure Mobile Services handles the rest. What happens, is the new SDK takes your data and serializes it to JSON. It then makes various REST API calls to the Azure service you’ve set up, allowing it to store data in SQL Azure without having to write a data access layer. If you need to perform more powerful data validation or push notifications, you can use write scripts on the web service to perform these tasks with each call to GET, POST, DELTE, or UPDATE.

By using Azure Mobile Services, I spent part of Friday and Saturday writing authentication and data access code. From there, I was able to focus on my applications actual user interface and logic. I didn’t have to spend any time fiddling around with SQL databases, writing my own API methods, or rolling my own OAuth code. It was all taken care of by Azure Mobile Services and  The core of the application was done by mid-Monday, and sent into certification later that evening.

You may be wondering, why did it take until Thursday to get the app into the store. The simple, scary answer? Certification. Windows Store certification is no easy task, especially for an app that was thrown together over one weekend. I failed it twice. This was of course due to bugs that hadn’t creeped up during my own testing, which takes me to one important point:


I could have saved myself an entire day in certification time if I had realized that some people wouldn’t want to necessarily authenticate with Windows Live. Had I tested this, I would have seen that exiting a certain dialog crashed my app. Another important point to note when trying to certify an app that does ANYTHING with user data:


I got failed for this on this app. It makes sense that I failed because of this, but when you’re writing code, a privacy policy doesn’t always cross your mind.

All in all, I have to say I was quite impressed with how flexible and easy to use Azure Mobile Services were when it came to writing an app like this. I highly encourage you to sign up for a Windows Azure 90 day trial, and try out the Azure Mobile Services preview. The best part? You’re not tied down to Windows 8. You could use Android, Windows Phone, or even iOS. Because it’s REST based, it’s a very flexible framework. If you need any resources to get started with Windows 8 app development, check out the new 30 to Launch program.

Also, I’d really appreciate it if you went ahead and give my app a try. It’s free and fun, and it’s the only one like it on the Windows Store. And, it’s powered by the cloud. Yay cloud!

Windows 8 Professional and Visual Studio 2012 Professional now Available to DreamSpark Premium users

For those of you enrolled in a higher learning institution, you’ll be happy to know that, if your university has DreamSpark Premium (formerly MSDN Academic Alliance), you now have access to Windows 8 Professional. Simply log into your school’s DreamSpark Premium Portal, and you’ll see the following:

After that, just click the product you want, and enjoy the new bits.

MonoGame: XNA for Metro Style apps

As most of you may know, XNA is not supported as an option for Windows 8 Metro Style apps. As a result, those who use C# for game development have very few options with Metro Style apps. Wondering what alternatives there are to XNA, I did some scrounging around the internet to discover that MonoGame, an open source game development framework developed alongside Mono, was working on a Windows 8 branch of their technology. This is a great find for any C# developers looking to write games on Windows 8. So here is what you need to do to start porting your XNA games to Windows 8:


Windows 8 Release Preview
Visual Studio 2012 Release Candidate
MonoGame Template for Metro Style apps
MonoGame Binary (Built 6/7/2012 for your convenience)


Once you have installed and downloaded the required materials, we can get started. First thing you need to do is extract the MonoGame Template for Metro Style apps attached above to the folder

“%UserProfile%\My Documents\Visual Studio 2012\Templates\ProjectTemplates\Visual C#\”

like so:


Next, you can open Visual Studio and create a MonoGame Metro Style app, like so:


Now that you’ve created the project, you simply have to add a reference to MonoGame.Framework.Windows8.dll, located in


Once that is complete, all of the errors should go away and the app should build without any problems. You’ll recognize the familiar cornflower blue background, except now it’s running as a Metro Style app!



From here, the MonoGame APIs appear to be one to one with the XNA APIs. The only thing to note that, as of this posting, MonoGame for Windows 8 is still lacking support for the Audio and Effects API. That will soon be fixed, and a follow up post will be published.

Keep an eye out for the stable release of MonoGame for Windows 8 by checking the MonoGame GitHub and Codeplex pages in the next few weeks. Until then, you can always build from the Develop3D Branch.

Poking around in the Windows 8 Simulator

Over the last few months, I’ve been playing around with some of the new WinRT/Metro Style APIs that are introduced in Windows 8 Developer Preview. The end to end developer experience resembles the one introduced with the Windows Phone 7 tools, including a tool for testing your code. One such tool is the “Simulator”

The Simulator is a tool that resembles the Windows Phone 7 Emulator, in both look and functionality:


It looks like a Windows Slate chassis, and includes emulation ability for touch gestures, mainly Pinch to Zoom and Rotate. While sideloading the App to debug on the local machine is fine and dandy, it’s nice to be able to test things like Orientation change and touch.

One thing that took me by surprise with the Simulator is in the way it functions. When using it, I expected a similar environment the Windows Phone 7 emulator, I was surprised. I opened up the Desktop “app” on the simulator, only to be greeted with this:


That’s a fully functioning version of my desktop… running inside of a simulator…. running on my desktop. Desk-ception? What on earth is going on here? There is no way we’re virtualizing a full instance of Windows just to test apps. So what is the simulator doing?

I decided to peek around, only to discover that the Simulator is creating a Remote Desktop Session on the local machine. It looks for some entries in HKEY_LOCAL_MACHINESoftwareMicrosoftWinSimulator (Or HKEY_LOCAL_MACHINESoftwareWow6432NodeMicrosoftWinSimulator if you’re on 64-Bit), namely the DWORD DisableChildSession. If that DWORD is set to 1, it will then look for the RemoteMachine value (string), UserName value (string), Domain (string), and the PathToPasswordFile value (string). Using these values, I’m sure you could point the simulator to another machine running Windows 8 for debugging.

It’s also worth noting that the Simulator has a dependency on WinRT. While it just appears to be a normal .NET Application, if you try to move it to any other versions of Windows, it will not run.

Go ahead and mess with those registry keys and see what kind of results you can get. I’m curious to see what the Beta build brings around CES. Perhaps there will be more goodies or secrets hidden.