Showing posts with label Windows Azure. Show all posts
Showing posts with label Windows Azure. Show all posts

Tuesday, October 29, 2013

Azure DevDays

Marraskuun 11. päivä pidetään Microsoftilla (Keilaranta 7) Azure DevDays-tapahtuma joka nimensä mukaisesti keskittyy Azure-teknologioiden ympärille (ja nimestään huolimatta on vain yksipäiväinen Smile). Minäkin olen siellä kertomassa tekemästäni Azure-palvelusta Linnanmäen Windows Phone- ja Windows 8-appeja varten. Tervetuloa kuuntelemaan ja kyselemään!

Ohjelma ja ilmoittautuminen täällä.

Friday, September 20, 2013

Run your development workstation in the cloud

I have been working lately on projects that require me to use legacy versions of development tools (such as VS 2010, SQL 2008 R2 etc). I normally run the latest and greatest versions of everything on my personal development workstation so this has forced me to put up a Hyper-V virtual machine that has the required versions set up properly. Luckily MSDN has all of the legacy versions downloadable :)

I do development work using multiple workstations depending on where I happen to be. I have a more powerful, bigger laptop at my office as the primary developer workstation with external display, keyboard etc. Since it is a bit painful to lug that laptop around when visiting customers, I also have a more lightweight laptop that I use as my take-anywhere tool of choice. That leads to a problem of what to do with the locally hosted development vm? I could copy it to both laptops (the lightweight one is also a Win8Pro machine), but then it would be out of sync constantly on the other machine, although all project source code is managed via the Team Foundation Service at http://tfs.visualstudio.com/.

The solution I came up with is that instead of running a local vm I set up a vm in Azure as an IaaS virtual machine. There is even a platform image with a legacy OS and SQL Server version:

clip_image001

So that would solve my problem! This solution has the benefits of being able to access the same hosted vm from either of my active development machines (or any other machine that has remote desktop capability). It was also a positive surprise (although I knew that but hadn’t realized it in practice earlier) that hugely large downloads from MSDN get downloaded via the extremely quick network that Azure datacenters have. Downloading a 4GB ISO image took a mere 15 minutes or so!

In practice, I already had a vm set up locally, so I also explored the option of moving that vm to Azure instead of creating a new one. In a later post I will explain how to move an existing vm image to Azure.

PS. This post was mostly written in the inspiring environment of Aalto AppCampus open house event on the “national work from home day” in Finland where I met many old friends and made some new ones!

Friday, March 22, 2013

Upgrading Azure Storage Client Library from 1.7 to 2.0

I recently needed to update a Windows Azure customer project to use the current version of Azure Storage Client library. Luckily NuGet automates most of the package management activities (adding references, dependencies etc). Apparently there have been some dramatic changes in the structure of the library itself, since I had to do quite a lot of work to bring the code back up to working level.

Some issues I bumped into:

Microsoft.WindowsAzure.StorageClient namespace has been renamed to Microsoft.WindowsAzure.Storage

CloudStorageAccount.SetConfigurationSettingPublisher() is no longer supported, use CloudConfigurationManager.GetSetting() instead. Typically like this:

Account = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting(configurationSettingName));

StorageClientException class renamed to StorageException, notably the following code:

catch (StorageClientException ex)
{
    if ((int)ex.StatusCode == 404)
    {
        return false;
    }

    throw;
}

becomes:

catch (StorageException ex)
{
    if ((int)ex.RequestInformation.HttpStatusCode == 404)
    {
        return false;
    }

    throw;
}

Uploading/downloading blobs only support streams instead of the earlier options that included byte array, string etc.

So instead of this code:

public void SaveImage(string containerName, string blobName, string contentType, byte[] data)
{
    CloudBlobContainer container = BlobClient.GetContainerReference(containerName);
    CloudBlob blob = container.GetBlobReference(blobName);
    blob.Properties.ContentType = contentType;
    blob.UploadByteArray(data);
}

you need to do something like this:

public void SaveImage(string containerName, string blobName, string contentType, byte[] data)
{
    CloudBlobContainer container = BlobClient.GetContainerReference(containerName);
    ICloudBlob blob = container.GetBlockBlobReference(blobName);
    blob.Properties.ContentType = contentType;
    var blockBlob = blob as CloudBlockBlob;
    using (var stream = new MemoryStream(data, writable: false))
    {
        blockBlob.UploadFromStream(stream);
    }
}

Note the use of GetBlockBlobReference() method instead of GetBlobReferenceFromServer() in the new code. The latter actually hits the server (thus resulting in performance hit), but what’s more crucial is that it actually fails if the blob does not exist. So if you need to create a new blob, it cannot be used at all, so most likely you will end up using GetBlockBlobReference() instead.

Retry policy structure has changed. Instead of this:

BlobClient.RetryPolicy = RetryPolicies.Retry(4, TimeSpan.Zero);

you need to do something like this:

using Microsoft.WindowsAzure.Storage.RetryPolicies;

BlobClient.RetryPolicy = new LinearRetry(TimeSpan.Zero, 4);

Links