Friday, May 1, 2015

Migrating On-premise .Net Web Applications to Microsoft Azure - Part 3

Application Consideration

.Net versions

Existing applications built on different older versions of .Net for e.g. .Net 1.1, 2.0 0r 3.5. It’s important to identify the current version of .Net runtime of your application, because while you are deploying your application on cloud, you must choose the targeted .Net framework. Currently, the default .Net versions supported by Azure WebApp is .Net V3.5 and V4.5.

During the migration, it’s recommended to recompile your application to target either V3.5 or V4.5 for better performance and security reasons. However during the recompilation process you may encounter certain libraries are obsolete and replaced with the new libraries of the targeted framework for e.g. 4.5.

It’s highly recommended to refactor the code and replace obsoleted binaries with the recommended alternates, but in certain cases where your application might use some third party tools & components which might expect a specific older version on which it’s built. In such cases, you may go back to the respective vendor and get the updated latest version of components for the target framework of your application if not, you may continue to support those old frameworks by including the below configuration in your web.config file.

      <supportedRuntime version="v1.1.4322"/>
      <supportedRuntime version="v1.0.3705"/>

Migrating your application to the latest version of .Net can be best accomplished through Visual Studio IDE. To convert an .Net V2.0 application to .Net V4.5, open your solution using Visual Studio IDE, the Visual Studio Conversion Wizard will pop up and will request you to back up the application, click yes to backup else click no to proceed with the Conversion. On the next screen, select the targeted framework for your application, it’s recommended to install the targeted version of .Net before the starting conversion, if not the conversion wizard will assist you to download and install the respective .Net framework.  After the successful conversion, you may proceed with deploying the application to Azure right from Visual Studio IDE.  


Caching helps us to store frequently accessed data stored and retrieved from the Cache Memory of the Server. Existing Asp.Net applications heavily dependent on InProc Cache memory for storing and retrieving Output Buffers, ViewState, Session State and Named Caches. InProc is the fastest caching technique as it stores the caching data within the application server, but the major downfall with InProc cache is, it will lose the objects when the server or the IIS gets restarted. 
Similarly, if your application is hosted in more than 1 server inproc is not an ideal solution as it depends on the Cache memory of the host server. 

Azure offers 3 different Caching solutions 

1. Azure Redis Cache (Preferred)
2. Azure AppFabric Managed Cache
3. Azure AppFabric InRole Cache

Out of all 3, Azure Redis Cache is the newest offering based on popular open source Redis Cache which is fully managed and serviced by Microsoft. Azure Redis Cache has lot of advantage over the rest 2 options because it supports running atomic operations on these types, like appending to a string; incrementing the value in a hash; pushing to a list; computing set intersection, union and difference; or getting the member with highest ranking in a sorted set etc. Other features include support for transactions, pub/sub, keys with a limited time-to-live, and configuration settings to make Redis behave more like a traditional cache.

Azure AppFabric Managed Cache offers providers for storing ViewState, Session State, and Output Buffer etc. Azure AppFabric InRole Cache, is a self-hosted alternative where the developers must take care of patching and updating themselves.

Store SessionState in Redis Cache

Session State dependent Web applications can easily move from InProc Cache to Azure Redis Cache in 2 steps.

  1. Create a Azure Cache Node
  2. Update your Web.config to refer Azure Redis Cache instead of InProc Cache

Comment out the Following Configurations in the web.config File

<!-- <sessionState mode="InProc" customProvider="DefaultSessionProvider">
    <add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" />
</sessionState> -->

Include the following configuration in the web.config File

<sessionState mode="Custom" customProvider="8KMilesSessionStateStore">
    <!-- Syntax
      <add name="MySessionStateStore"  host = "" [String] port = "" [number]  accessKey = "" [String]
        ssl = "false" [true|false] throwOnError = "true" [true|false] retryTimeoutInMilliseconds = "0" [number]
        databaseId = "0" [number] applicationName = "" [String]  connectionTimeoutInMilliseconds = "5000" [number]
        operationTimeoutInMilliseconds = "5000" [number]  />
    <add name="8KMilesSessionStateStore " type="Microsoft.Web.Redis.RedisSessionStateProvider" host="" 
    accessKey="..." ssl="true" />

To programmatically read and write objects into Redis Cache download StackExchange.Redis provider from Nuget via Visual Studio IDE. Please refer the below example for reference


Error handling and management of events and logs is a cumbersome process but it’s required to make sure the health of the application is always good as well as analyze the errors and resolve them on a timely basis. Most existing applications use one or the other out of the box Logging libraries and SDKs or built a custom logging mechanism to capture the logs and monitoring infrastructure. These logs usually retained for couple of weeks or a month to reduce the storage cost of these logs.  Usually developers stores the log files in a text file and store in a centralized location with the overhead of parsing and conversion to feed the data to log monitoring application, other option is to store these log data in the SQ Server Database.

When migrated to Microsoft Azure provides native support for Log Tracing and Diagnostics. Azure provides 3 different ways to collect and store the log information.

They are

  1. File System Storage
  2. Table Storage
  3. Blob Storage

File System storage helps you to store the logs in the text format on the host server, and then you can configure to move the data to table storage or Azure SQL on a timely intervals for advanced monitoring and analysis. Table Storage option will directly store the data in Azure Table storage without having to storage the data in the host server, thirdly Blob Storage which is also very similar to File System storage but this will save the log files in the CSV format.

Another option is “Azure Operational Insights” exclusive for applications hosted on VM/Physical Machine hosted on premise and private or hybrid clouds. It’s a cloud based Log/Security/Capacity Planning service fully managed by Microsoft. With this you can completely automate, store, analyze the logs. Click here to read more about this service.

Note: While migrating applications to Azure, it’s recommended not to move the old log files into Azure to avoid raising confusions between the Azure Server Logs and Application and Onpremise logs.

Static File Consideration (Image/Scripts/CSS/Video/Audio etc)

Static assets like Images, Javascript, and CSS are the bulky and bandwidth intensive part of your web applications. Hosting these static files within your application environment has number of problems including 

  1. Increasing the overhead of the application server to serve static contents as well
  2. Increasing the bandwidth cost of the application hosting server
  3. Increasing the size of the application packages during frequent deployment

Offloading these static assets from your application host to a dedicated storage account is a recommended approach. While migrating your application to Microsoft Azure, you can move these static files to Azure Storage and directly serve the static content from the dedicated storage account instead of your application server. This separation of concern will overcome all the disadvantages mentioned above along with the benefits like boosting the performance and reduce your existing hosting costs and ability to update static files by replacing them in CDN without having to deploy entire website.

However when you adopt Blob storage, you have to update all the physical path to logical paths. Refer the below configuration snippet to fix this in the web.config file.

ConnectionMultiplexer connection = ConnectionMultiplexer.Connect(",ssl=true,password=...");
IDatabase cache = connection.GetDatabase();

// Perform cache operations using the cache object...
// Simple put of integral data types into the cache
cache.StringSet("key1", "value");
cache.StringSet("key2", 25);

// Simple get of data types from the cache
string key1 = cache.StringGet("key1");
int key2 = (int)cache.StringGet("key2");
Take a look at the Community developed Azure Storage Explorer (Version 6), it can help you to connect to your storage account and manage your static files.