Nicke Andersson

Windows Azure: How I deployed an existing Silverlight application in 30 minutes

Almost two weeks ago I posted about my first experiment with Amazon EC2, and how I was able to get an existing application (our Sproodle SaaS offering) up and running on EC2 in a couple of hours. That was the same day as Microsoft announced Windows Azure, and of course I wanted to try the same application to run on Azure as well. Two days later I finally got my Azure account, and to my delight I was able to get our application up and running on Azure in about 30 minutes. Which in my mind seriously rocked. In this post I will explain the steps I went through to deploy an existing application to Azure, and talk a bit about how Azure compares to EC2.

Oh, and I’m pretty sure this was the first real (real as in real application, not a Hello World sample) Windows Azure deployment from Finland (on the 29th of October) :).

Deploying an existing application to EC2

There are a bunch of Hello World-examples for how to create a small app and deploy it to Azure, but when I first did this deployment I couldn’t find a sample that showed how to take an existing application and deploy it. However, the mechanism behind deploying to Azure is pretty simple, and essentially what you need is a deployment project. In Visual Studio you can’t add just the deployment project to an existing solution, you always get a new web application as well. This may not seem that useful at first glance, but it’s actually not that hard to change it to deploy whatever project you want. Below you can find out how. I’m using a sample app for this article, since the project I actually used when I did this at PDC is a pretty large and complex beast.

Step 1. In your existing Silverlight application solution, add a new Cloud Service project

My sample application solution contains two projects. The first is the Silverlight application, which in this case just writes “I like clouds! on a blue background. The other project is a web application that shows the Silverlight app. No changes has been made to this project, it’s just straight out of the box.

Now, to add cloud goodness we have to cheat a bit. Currently (as far as I know) Visual Studio won’t let you add a Cloud Service project (which is needed for deploying to Azure) and have that deploy an existing web application. It always wants to create a new application for you. So what you can do is to add a new “Web Cloud Service” to your solution. Let’s call it “CloudService”.

 

 

 

Step 2. Get rid of the generated WebRole-project

When you add a new “Web Cloud Service”-project Visual Studio actually creates two projects for you. One is the deployment project (“CloudService” in this example), and the other is a web application (“CloudService_WebRole”). As far as I can tell the second one is just a regular web application.

The deployment project is set up to deploy the CloudService_WebRole-project, and I haven’t found a way to change which project it tries to deploy through the Visual Studio UI. So we need to wire it up to deploy our existing  “SilverlightCloudApplication.Web” instead.

 

 

 

Step 3. Use notepad to edit the project file.

This is the scary part. If you’ve poked around in the Visual Studio project files before you know that they are just XML files, and note even very complex ones at that. It turned out that all we need to do in order to make “CloudService” deploy any web project we want is just change which project its deployment point refer to.

So what we first need to figure out is the ID for our “SilverlightCloudApplication.Web”-project. First close Visual Studio. Then open the file “SilverlightCloudApplication.Web.csproj” in notepad (or your favorite text editor). Look for an XML element called “ProjectGuid”, and copy the contents of that element. In my sample project here it was “{61CADBB5-24ED-4F11-848B-7754877F7A06}”, but it will be something different for you project.

Next open the project file for the “CloudService”-project. Look for an XML element called “ItemGroup”, and another called “ProjectReference” below that. You need to edit three things in there. First, change the “Include”-attribute of the “ProjectReference”-element to be the path to the project of the web application you want to deploy. Next, change the contents of the “Name”-element to be the name of your web application. And finally, change the contents of the “Project”-element to be the guid you copied from the web application project file earlier.

Below you can see a screenshot that gives you an idea of what the results of your edits should look like.

Save the file, and restart Visual Studio. When you open the solution you will see that the CloudService now refers to your web application (in this case “SilverlightCloudApplication.Web"). At this point you can safely delete the “CloudService_WebRole”-project, as it is no longer needed.

 

Now you should be able to build and publish your application to Azure. Happy cloud computing.

 

 

 

Comparing Azure to Amazon EC2

A lot of people have asked me which is better, Azure or Amazon EC2? First I want to point out that this is a bit of an apples to oranges-comparison. Sure, they both are part of that fuzzy bag of stuff called “cloud services”, but from a (service) perspective they are quite different. What Amazon does is give you virtual servers that you can use to run whatever you want on, and what Azure does is give you the ability to deploy web applications to the cloud. The difference is primarily that with Amazon you still have to operate and maintain the environment your application runs in, and with Azure Microsoft is taking care of all of that for you. And they seem to do it in a very impressive way. Their environment even takes care of staging for you, so that you can test your new deployment before you switch out the currently live one.

So which one do I prefer? I really like Windows Azure. I also like Amazon EC2. I think there’s room for them both. Currently I think Azure is the better choice if what you want to do is run a web application in the cloud. Most software developers do not want to have to operate the environment, for many reasons (cost being one of the most popular ones).

If you need full control over the environment your application runs in, you probably cant use Azure (at least not in its current state). For example, I have to admit that I ended up cheating a bit when I deployed Sproodle to Azure. Because it has a database and a bunch of WCF services on top of that database I couldn’t deploy those to Azure, since it doesn’t supply you with a SQL Server. I would have had to re-architect the services so that they can run in Azure on top of SQL Services (which is a completely different animal from SQL Server). My kung fu may be strong, but not strong enough to do that in half an hour. :) So what I did was keep the services in the EC2-environment I’d set up a couple of days earlier, and set up my Silverlight app to call them from there instead. So I ended up being double-clouded, the front end running on Azure and the back-end on EC2. Not ideal, but hey, it worked! :)

Silverlight navigation patterns – what do users expect?

During my presentation at Microsoft DevDay a few days ago I promised to share the code I was showing there. Here’s the first set, with more to follow (maybe in a few days, depending on my schedule).

During the presentation I was talking about how users do not care about what technology was used for making the application (obviously), and instead they just expect the application to behave like other similar or related applications. So, to a user, a Silverlight application is just like any other web application because they use a browser to access it. If the technology itself has certain limitations that is of no interest to the user.

Because Silverlight is heavily sandboxed you can only get access to some of the things going on in the browser, and the back- and forward-buttons (and history management) is not among those. Still, being able to use the back- and forward-buttons is something users expect to be able to do. There’s different ways to solve this, but many of them end up being either browser-specific in one way or the other. However, a month or so ago I came across a post by Jordan Knight that shows an implementation based on features introduced in ASP.NET as part of .NET 3.5 SP1. The code I showed in my presentation was more or less directly influenced/copied from his approach, so all the credit for this approach belongs to him.

For the DevDay-presentation I made a simple sample application, pictured on the right. There are three buttons, with which the user moves to different parts (modules) of the application.

When the user presses one of the navigation buttons the new position gets added to the browser history.When the user clicks the forward- or back-buttons (or uses the browser history to select a previous position) the application is notified of this and shows the appropriate module.

So how does this work? For a full explanation I really recommend that you read Jordan Knight’s original post, as the sample I made doesn’t really add anything new to it and his explanation is very detailed and easy to follow.

The principle behind the technique Jordan describes is that a bit of JScript is used as glue between the browser and the Silverlight application, and this enables the Silverlight to react to history-related events in the browser.

Download the code here.

 

The interesting parts are in the following files:

• SilverlightBrowserNavigationTestPage.aspx
  Here the History.js is loaded, and the OnPluginLoaded-event on the Silverlight plugin is wired up to an event handler in History.js.
• HistoryManager.cs
  Used for interfacing between JScript (History.js) and the rest of the Silverlight application.
• App.xaml.cs
  Here the HistoryManager is instantiated, and a new property is introduced (History) to expose it to the rest of the application.
• Page.xaml.cs
  Events fired by the HistoryManager when the user uses Back/Forward are handled here, and the appropriate module is shown.
  

Enjoy the sample.

Silverlight Experiences at Microsoft WebDay

I gave a presentation on Thursday (the 16th of October) at Microsoft WebDay here in Helsinki. The presentation was about what we've learned while developing our new product Sproodle using Microsoft Silverlight. The focus was not so much on the technical details but on what kind of experiences we've had with the technology and what we've learned from using it.

The recording from the presentation (in Finnish) will be up on Codezone in a few days or so, but if you just want to have a look at the slides you can find them below.

I think the presentation went well, based on the feedback I got (hey, it was even called "epic" in a comment on this blog).

During the presentation I promised to post (at least some of) the samples I showed, and I'll try to get them up during the weekend.

Anyway, here are the slides:

 

View SlideShare presentation or Upload your own. (tags: microsoft silverlight)

I noticed that Slideshare butchered a couple of the slides a bit (fontsizes and such), but it's close enough.

Popfly is in public beta

Yay! Head over right away to www.popfly.com and get mashing.

Silverlight, custom controls and setting width and height

I guess it's just one of those facts of life that sometimes beta bits turn on you and bite you in the ass. I've been working on a set of charting-related custom controls for both WPF and Silverlight that would let you produce some nice looking sparklines and bullet graphs, and there were some issues in the Silverlight controls that had me stumped. I tried to make the code somewhat portable between WPF and Silverlight (not as easy a feat as one would think), and one of the latest problems I've run into is related to setting the Width and Height of my control in XAML.

As a basis for my work I'd been using one of the quickstarts at Silverlight.net, namely the on creating a custom control. This puppy was clearly written before the latest refresh of Silverlight 1.1 and the tools for Visual Studio 2008 beta 2.

I had my custom control shadow the width and height properties, like this:

        public virtual new double Height

        {

            get { return _implementationRoot.Height; }

            set

            {

                _implementationRoot.Height = value;

                UpdateLayout();

            }

        }


        public virtual new double Width

        {

            get { return _implementationRoot.Width; }

            set

            {

                _implementationRoot.Width = value;

                UpdateLayout();

            }

        }

Where _implementationRoot was declared as:

private FrameworkElement _implementationRoot;

and I was initializing it in the constructor of my custom control like this:

        public BulletGraph()

        {

            System.IO.Stream s = this.GetType().Assembly.GetManifestResourceStream("SilverlightBulletGraph.BulletGraph.xaml");

            _implementationRoot = this.InitializeFromXaml(new System.IO.StreamReader(s).ReadToEnd());

        }

The reason for doing this was that I wanted to be able to re-layout my control if its size changes. This should have been all fine and dandy, as it was all in line with what the sample from Microsoft was saying. But, when I was trying to perform a lot of layout magic that was needed in order for the bullet graph control I was trying to implement I noticed that Width and Height were never being set, despite the fact that I in the XAML file I was declaring them like this:

  <my:BulletGraph Width="300" Height="100"

                  Header="SalesSales" Scale="EUR"

                  Minimum="0" Maximum="150" TickFrequency="25"

                  Value="87" Target="100"

                  BadRange="50" SatisfactoryRange="80"/>

So, as it turns out, the Silverlight refresh and Visual Studio 2008 beta 2 (Orcas) has a bug in them (surprise, surprise!). The Width and Height never get called.

Unfortunately I kept trying to solve this on my own too long before relying on Google. If I'd done so I would have come across several pieces of advice, among those that of Jeff Prosise of Wintellect fame, who blogged about this in an article back in August.

Anyway, as it turns out, the advice given in the original article, is no longer valid for the refresh. Width and Height never gets set, and I ended up removing the properties. This way I can't achieve all of the behavior I was looking for, since if the size changes I won't find out. I'll wait for the next version of Orcas and the Silverlight tools, where I'm sure Microsoft has fixed this-

 

And, by the way, if you're wondering what all this bullet graph stuff is about I seriously recommend that you check out the writings of Stephen Few (who invented them), at Perceptual Edge or at wikipedia.

And the controls I've been making? I hope to polish them a little bit and post more about them during next week.