My previous post showed how to create a simple asp.net application that runs on the local development fabric.  This post, as promised, will follow up and show how to move your application into the azure services cloud.

The first think you need to do is go into the azure services developer portal and create a new project.

Click on the 'Hosted Services' item, and you will be taken to a page that allows you to create a new project:


Next will take you to a form that allows you to specify the name of the service, but is really just the DNS name that will be assigned to the web app when in production:


When that is complete, you will be taken back to the main page which will have changed its look to be as follows:



The files I specified were a result of publishing from vs.net using the 'Publish' menu item.  This will create these packages, open the azure portal, and open an explorer folder where the files are located.

When pressing the deploy button, you will be presented with a dialog telling you the files are being copied:

This is the first post is a series of posts that I will be making about using the windows Azure cloud computing services.  This first post will be about making your first cloud service that runs locally on your computer.  Over the series of posts I'll explain moving the code into the actual azure cloud, adding storage to your application, using the cloud services as a bus between various distributed applications, providing scalability and reliability, and I'm sure other things that come up along the way.

The first this to do to get started is go to http://www.azure.com:

Click on try it now and download and install the SDKs:


While you are at it, I'd suggest registering for the services.  I did this at the PDC and got registered almost immediately.  I don't know how long it will take at this point, but in the worst case you can still develop and run locally.

Once the SDKs are installed, open visual studio and create a new web cloud service project / solution:


The solution will open and look as follows:


This is the service configuration file.  It is used by the cloud fabric to determine the roles and # of instances of each role to run.

There is another configuration file, the service definition file.  This file informs the fabric how external applications are to talk to the role.  In this case we are defining normal http access:


The project also has a web page added to it, and I've added a little bit of text to it:


You can then run this application with ctrl-f5.  Thing will appear a little different during the build and start up process.  You'll notice some messages about initializing the development storage system, which is basically the local cloud fabric and its data storage.  What's going on is the that application is being packaged and installed into the local fabric.  Once that is done, IE will open and you will see your application:



All in all, this does not seem too exciting as it's a real simple ASP.NET app.  The difference here is that it is running on a local development fabric, not just on a local copy of IIS.  If you look in your task bar, you will notice the following icon (it looks like a couple of azure colored gears):


Click on the icon and select the "show development fabric UI" menu item, and you will see the following user interface:


This UI is showing you the current applications being hosted in the cloud fabric on your local system.  This is a really cool tool, as when you run multiple instances, you will see multiple consoles.  When we actually get around to running .net console apps in the fabric, information that you write to the console will actually be shown here.  In a way this tool is a viewport into what can be many virtualized .net instances running on your system (or in the cloud).

One last thing in this lesson.  Click on service details, and you will get information about the service:


Notice that this information matches the information in the service configuration file that I showed before as part of the solution.

And voila, you are running in the cloud, albeit a cloud on your local system.  Very easy so far, but not too exciting.

In my next post, I'll show you how to move this into the actual cloud.  I have not actually done this yet, so it will be a discussion of my experience learning how to do it.

This is a list I need to grow over time to answer this question.  Besides the fact of vector based scalable graphics, WPF has the following advantages:

• Ability to accomplish much of the app in a purely declarative model
• Ability to very effectively separate UI from logic
• Dependency property model
• Command model, including routed commands.
  
• Bubbled and tunneled events.  Many times its so much easier to let events bubble up to a unified listener and make a decision on what to do based upon the original source, or the last control to bubble / tunnel the event.  This just lets your centralized a lot of the UI processing logic for a form at the form level, instead of splattered all over the individual controls.
  
• Built in animation models, including story boarding
  
• Styling and themes
• Better UI threading model
• Visual state management.  Yeah, still just in Silverlight, but coming to WPF soon.
  
• Declarative model translates to other environments (ie, Silverlight)
• Databinding is LIGHT YEARS more advanced.  More on this later.
  
• Tying into data binding and dependency properties, the observablecollection model is much more robust
• Data and control templates which provide flexible modeling (and substitution) of UI on data models.
• User interface virtualization is built in, allowing handling of extremely large data sets
• 2-Pass layout model.  This is real important is it allows negotiation of layout, and control by the container of other controls to modify positioning of element.
  
• Attached property model, which provides great flexibility in allowing a child of a parent element to talk to the parent in its own language, even though the child has no idea what the type of the parent is.  Want to position a text block in a canvas?  Use Canvas.LeftProperty.  Want to position it in a grid column, use Grid.RowProperty.  The child is agnostic to the type of the container, and you make the design time decision on how to pair them up without having to add any code to the child.
  
• Declarative triggers.  Just great to be able to trigger declarative code based upon various events with more declarative code.  Much more flexible than doing code behind.
  
• 3D (yeah, that's part of the obvious vector graphics)
• Ability to easily integrate different types of media out of the box
• Extensive support for different layout models (grid, canvas, stack panel, wrap panel, ...)
  
• Ability to create interfaces dynamically, or to download and execute them dynamically
• Winforms controls can be used via interop in a WPF app (helps support your installed base)
• Did I say databinding is more advanced?  I just love databinding to XML.  Additionally, combined with Linq and anonymous classes, databinding is just so much more effective and simple to implement.
• Control creation and reusability.  Actual creation of controls is about as easy, but you can reuse controls in WPF so much more effectively.  Basically any other control can be the content of another control, allowing great flexibility in building UIs.
• Ability to declaratively use business objects in the UI.  Your programmers can build the business objects, package them in a library, and then you can instantiate instances of them in xaml as resources and bind them directly to controls.  All without and code on the UI side.
• Preview event model, letting you intercept and perhaps prevent / modify events before they are processed.  Brilliant!
  

Also, and this is a gut feeling that I find hard to quantify, but it just seems that I am significantly more productive in WPF than in WinForms.  I think this comes from the ability to quickly layout items, get them bound to data, repurpose the UI if needed, all without much code just seems so much more productive.

Sure it took me understanding all of the items above, but once they are understood it's just really a much more productive environment.