Kean Walmsley


  • About the Author
    Kean on Google+

July 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    








« Hosting our ASP.NET Web API project on Windows Azure – Part 1 | Main | Using Windows Azure Caching with our ASP.NET Web API project »

April 18, 2012

Hosting our ASP.NET Web API project on Windows Azure – Part 2

In the last post, we added a Windows Azure deployment project to the ASP.NET Web API project we created previously. In this post, we’re going to go ahead and publish our project on Windows Azure.

To get this started, we right-click the deployment project in Visual Studio’s Solution Explorer and select “Publish”…

Right-clicking our deployment project and clicking Publish… which brings up the “Windows Azure Publish Sign In” dialog.

At this stage, you probably don’t yet have an Azure subscription. Whether you do or not, click the link on the dialog to proceed:

Download your credentials

If you don’t yet have a subscription, it’s at this point that you’ll be prompted with the options available to you. I personally signed up for a 3-month trial subscription, for which – by logging in – I can then download credentials to my local system.

Downloading credentials

I’m then able to go back to my Publish dialog and import these credentials:

Windows Azure Publish Sign In dialog

Now we’re ready to really start publishing to Azure. Our next step is to choose a name (which will be used to form the URL *.cloudapp.net that you’ll use to access your web-site and/or -service).

You also get to choose your hosting location – in this case I’m going to deploy to Western Europe… partly because it’s the closest location to me, personally, but also because the Eastern US data center (which would have split the difference nicely between here and the US) doesn’t yet have a caching service available (something we’ll look at in the next post).

Choosing a name and a hosting location

For the sake of this example, we’re going to break the cardinal rule of web development and push our deployment straight into production (rather than publishing to staging, testing it and then promoting it from there).

Our publish settings

We can also set some credentials to allow us Remote Desktop access to the instances we create, helping us troubleshoot any tricky issues:

Remote desktop options

And then it should be a simple matter of hitting Publish…

Publish Summary - ready to go!

… and sitting back and waiting for VS to deploy the project to Azure:

Our Azure activity log

In the meantime, we can shoot across to the very-handy Windows Azure Management Portal, by logging in at http://windows.azure.com:

Logging in

This provides access to our Azure subscriptions and services:

The Windows Azure Management Portal

From this page, it’s straightforward to perform various tasks such as checking usage and billing, promoting staging to production, and stopping or deleting running services.

Once the project is live, we can access the main web-page (which I went ahead and customized to provide some information about our web-services):

Our web-page describing the available web-services

And, of course, the web-services are available below this site, e.g.:

http://apollonian.cloudapp.net/api/circles/5/3

http://apollonian.cloudapp.net/api/spheres/5/3

Now that this site is live, it remains for us to adjust our AutoCAD-specific code to consume the data from the cloud rather than the local service. Once we’ve done that, I’ll post the project for the server deployment as well as our local AutoCAD-based client.

But before that, in the next post we’re going to look at some decisions related to the economics of cloud hosting, particularly around adding a caching service (one of Azure’s PaaS features) and reducing the size of our cloud-hosted VM instances.

Update

While preparing the next post, I decided to adjust the JSON format slightly, shortening “Radius” and “Curvature” to “R” and “C”, respectively. This reduces the data transferred by a reasonable amount (about 8% for spheres and 14% for circles), and I decided to go ahead and do it now, before we create more dependencies on the service and end up with a versioning issue.

blog comments powered by Disqus

10 Random Posts