Migration of existing ASP.Net web application to Windows Azure involves manual work as there is no automated tool available. This also requires you to look at several aspects of your application. However, if you already have a scalable, configurable application capable on running on a Web farm then migrating the application to cloud is not a complex undertaking. This blog covers vital considerations for moving an ASP.Net web application from On-Premises to Cloud.

The blog assumes that you have a basic understanding of Windows Azure platform and ASP.Net. The section below will provide overview on design / architecture changes involved for different components of a Web Application.

Important Note: This blog contains contents from different materials available on Internet from several sites. Purpose of this document is to gather those contents in a concise format at one place and provide inputs from our experience working with ASP.Net applications and Windows Azure CTP wherever required.

ASP.Net Web application Migration

Following headings details several aspects of a typical Web Application that will undergo changes.

Web Site to Web Application conversion

Only Web Applications (and not Web Sites) can be associated as Web Roles in the Windows Azure Tools for Visual Studio.  If you have a Web Site and are willing to convert it to a Web Application, Visual Studio provides a conversion tool.

App.config/Web.config changes

Because the web.config is part of the deployment, any change to the file also requires a re-deployment.  If you use a build system that targets your dev/stage/QA/prod environments automatically and can provide the correct settings in the web.config for you, this might mitigate the problem.

Alternately, you can move your settings to ServiceConfiguration.cscfg to allow for run-time update. You can also leverage RoleEnvironmentChanging and RoleEnvironmentChanged events if you want to be able to change default behavior of recycling the role on any config change.

.Net Full trust configuration

By default applications run under partial trust environment in Azure. To enable full trust for applications running in Azure, simply add the enableNativeCodeExecution attribute to your role in the Service Definition file and set the attribute value to true. This unlocks a number of compelling scenarios such as

• To allow using native code via spawning processes or Platform Invoke (P/Invoke)
•  Certain .NET libraries, including libraries in the .NET Services SDK, require full trust and can now be used in Windows Azure
• Inter-process Communication via Named Pipes: If you application spawns processes, you can communicate among them via named pipes.

Caching / State Management Migration

You will also need to make sure that you don’t have assumptions about the state of the machine you are running on – in the Windows Azure world, your service could easily be moved to a new VM.  For example, you cannot use in-process session state in an ASP.NET application that you plan to host within Windows Azure. Other considerations are as under:

1.       ASP.NET cache is not shared across instances.

2.       Memcached – a caching product can be used quite straightforward way for caching session state.

3.       Cookies, hidden fields - any client-side providers basically work fine.

4.       Velocity - not yet available for Windows Azure

5.       To store state, ASP.NET membership / profile providers for SQL Azure and Azure storage are available on Codeplex.

Forms Authentication Migration

Two options are available for Forms authentication migration:

a)       SQL Azure as the backend: Only requires you to change your connectionString, no other change is required.

b)      Azure Table Storage: You will need to use TableStorageMembershipProvider and TableStorageRoleProvider.

For details of Claims and Federated authentication, please see http://azuresecurity.codeplex.com/wikipage?title=Web%20Application%20Scenarios&referringTitle=Home.

Send Email from Cloud Application

SMTP service is not available within cloud. You can open TCP connections outside the Windows Azure cloud, so you can use an external SMTP server to send mail.

File System in Azure

A Windows Azure drive acts as a local NTFS volume that is mounted on the server’s file system and that is accessible to code running in a role. The data written to a Windows Azure drive is stored in a page blob defined within the Windows Azure Blob service, and cached on the local file system. Because data written to the drive is stored in a page blob, the data is maintained even if the role instance is recycled. For this reason, a Windows Azure drive can be used to run an application that must maintain state.

The Windows Azure Managed Library provides the CloudDrive class for mounting and managing Windows Azure drives. The CloudDrive class is part of the Microsoft.WindowsAzure.StorageClient namespace. See the Windows Azure Managed Library Reference for more information.

Once a Windows Azure drive has been mounted, you can access it via existing NTFS APIs. Your Windows Azure service can read from and write to the Windows Azure drive via a mapped drive letter (e.g., X:\).

COM  Support in Azure

COM is not supported in Windows Azure unless your components can be XCopied. The cloud machines do not have COM runtime installed. Currently the only native code supporting in Windows Azure is standard C++ library and standard Win32 API.

1.       COM Applications - typically have a dependency on the registry and won’t be able to update that when running in the cloud. Instead use registration-free COM+ with manifest files.

2.       To call a 32-bit DLL use a WCF host process

3.       Host external processes (EXEs) in a worker Role

Migrate WCF service to Cloud

Following considerations must be take into account for hosting a WCF service in Azure:

a)      Base Address: When hosting in Azure, ensure that the base address is the public load balancer address (for example http://wcfazure.cloudapp.net) as opposed to the address of the particular machine instance that Azure has allocated for our service.

b)      Partial trust: In Partial trust support, few of WCF features will not work. In order to access features that require full trust in the Azure fabric, your role needs to specifically opt in to full trust.

c)       Proxy Generation: Out of the box, using Add Service Reference or svcutil to generate a proxy to a service hosted either in the development fabric or the cloud fabric will fail. The WCF team has issued a patch that can be applied to the user machine in order to work around this issue. To configure a WCF service to use the patch, you need to configure the behavior from your service by setting <service behaviorConfiguration=”LoadBalancedBehavior” /> when you declare your service.

d)      Address filter mismatch: At runtime, WCF services may return the following error: The message with To ‘http://127.0.0.1:81/Service.svc’ cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher.The error can be corrected by applying the following attribute to the service class, [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

The above operations and available templates for WCF Rest Services development in Azure are detailed at this link: http://code.msdn.microsoft.com/wcfazure/Wiki/View.aspx?title=KnownIssues&referringTitle=Home.

Windows Azure supports ASP.Net ASMX Webservices. Both asmx and WCF services runs under Web Role to be accessible over http.

Migrate only SQL Server to SQL Azure

1.       From application to connect to SQL Azure DB, just change the connectionString

2.       If you are using ASPNetSQLProvider then you need to create required tables in SQL Azure database (with the new scripts available from Microsoft)

3.       Migrate your database to SQL Azure as detailed in SQL Azure migration section

ADO.Net Data Services and Entity Framework Support in Azure

You have to use a local database to create the EF edmx file, but once that is done changing the connection string to the SQL Azure database using “Server” instead of “Data Source”; “Database” instead of “Initial Catalog”; and the “User ID”, “Password”, and Trusted_Connection=False” instead of “Integrated Security=TRUE” will allow you to develop directly against the SQL Azure database.

Data Access Layer Migration

Only changing connection string from SQL Server to SQL Azure instance will be required. However, if you want to utilize Windows Table Storage instead of SQL Azure, then you will need to rewrite your Data Access Layer.

Background Job Migration

The Worker Role is similar to a windows service. It starts up and is running all the time. Instead of a timer, it uses a simple while(true) loop and a sleep statement. When it ‘ticks’ it performs some kind of maintenance work.

Worker role usually needs some data to work with. This data can come from a number of places. For example, the AzureServicesKit has examples that show you how to communicate between a worker and a web role via the use of a queue.

An example of using Worker role will be: You could potentially create a Cloud Service with just a worker role that monitors a particular Live Mesh folder for photos, and when a new one is added, it checks for that metadata with the city name, and inserts latitude/longitude coordinates as additional metadata.

Migrating Database Schema

To migrate an existing SQL Server database to SQL Azure you can export the schema as a Transact-SQL script and then execute that script against SQL Azure as follows:

1.       Export a script from SQL Server Management Studio and set the appropriate export options. Because SQL Azure supports a subset of features found in SQL Server, you may have to make some modifications to the script before you are able to execute it in the cloud.

2.       Execute the script to create the schema in SQL Azure.

You can use the Generate and Publish Scripts Wizard to transfer a database from a local computer to SQL Azure. The Generate and Publish Scripts Wizard creates Transact-SQL scripts for your local database. The wizard uses them to publish database objects to SQL Azure.

Note: SQL Azure does not support user-defined data types, extended properties, Windows authentication, or the USE statement.

SQL Server Data Migration

You can transfer data to SQL Azure by using the following:

·         SQL Server 2008 Integration Services (SSIS)

·         The bulk copy utility (BCP.exe)

·         System.Data.SqlClient.SqlBulkCopy class

·         Scripts that use INSERT statements to load data into the database

SQL Azure Migration Wizard – from codeplex

The SQL Azure Migration Wizard helps you migrate your local SQL Server 2005 / 2008 databases into SQL Azure. The wizard walks you through the selection of your SQL objects, creates SQL scripts suitable for SQL Azure, and allows you to migrate your data. SQL Azure Migration Wizard does not catch all of the compatibility issues between different levels of SQL Server databases (i.e. level 80, 90, and 100). SQL Azure is based on SQL Server 2008 (level 100). If you are migrating from an older database (level 80 or 90), you should go through the upgrade process first (at least in the dev environment) and once on SQL Server 2008, then migrate to SQL Azure. Link for details about this tool is mentioned in References section.

Utilizing App-Fabric

Once the application is on cloud, it can communicate with other applications on cloud or On-Premises using Appfabric Service Bus. Appfabric also includes Access Control service that provides federated authentication.

Conclusion

Windows Azure promises to be an extremely interesting environment for developers, service providers and companies trying to develop robust, highly available service environments.

In this blog we covered migration of several components of a typical web application. A detailed whitepaper on ASP.Net migration along with its benefits/limitations, product management considerations is posted on GINI at: https://portal.globallogic.com/confluence/display/GINI/Migration+-+ASP.Net+application+to+Windows+Azure

Popularity: 100% [?]