All Things Mobile, Because It's What I Do...: March 2012

This walkthrough shows how to deploy an ASP.NET MVC application to Windows Azure by using the Windows Azure Publish wizard in Visual Studio.
The Windows Azure Publish wizard enables you to perform most deployment tasks within Visual Studio. This includes such tasks as creating a hosted service, creating a storage account, and uploading certificates to enable Remote Desktop access. The wizard also lets you save Publish profiles so that you can reuse wizard settings in future deployments. This simplifies the deployment process for deploying updates in the future.
In this walkthrough you'll perform the following tasks:

Create a Windows Azure account.
Create an ASP.NET web project to deploy. This will not initially be a Windows Azure solution, since the purpose of this part of the walkthrough is to show how to deploy an existing web project to Windows Azure. Later in this walkthrough you'll see how to create a new web project that's specifically intended for deployment to Windows Azure.
Add a Windows Azure deployment project to the web project.
Deploy the web project to a new hosted service in the staging environment in your Windows Azure account.
Deploy an update by using Web Deploy.
Create a SQL Azure database and configure the application to use that database when it runs in the cloud.
Promote the application from the staging environment to production.

The final section of the walkthrough shows how to create a new ASP.NET Windows Azure web project using the templates provided in Visual Studio.
Before you begin, it's important to understand some of the differences between Windows Azure and other hosting environments that you may be familiar with, such as third-party hosting providers or Internet servers running in your own data center. In other environments, when a server that runs your application fails or is taken out of service for a patch or application update, you are aware of it happening and you handle it manually. In Windows Azure, a web role instance, which is a virtual machine (VM) that runs your service, might be taken down automatically and replaced by a new VM at any time for one of these situations. For example, a server to be patched is taken out of the pool of available web servers, a new VM is created, and then the server is added back to the pool. Or a VM fails, it is automatically taken out of the pool, and a new VM is created and added to the pool. You are not notified when these things happen, so your application has to handle them gracefully without any manual intervention.
These are typical scenarios for production applications, for which you normally specify that more than one web role instance should run the application. If you only have one web role instance, there is no pool and there would be a service interruption when these things happen. In development, however, it is often easier and quicker to work with just one web role instance. That is what you will do in this walkthrough, but changing the number of web role instances is easy to do when needed.
This walkthrough illustrates two ways to deploy: the Windows Azure Publish wizard and Web Deploy. The Publish wizard provides Windows Azure with the information it needs to create web role instances as needed. Web Deploy updates a specific web role instance while it is running, which means that when Azure takes down and re-creates the VM, the Web Deploy updates are lost. For this reason, Web Deploy is useful for quick updates during development, but you always have to Publish to Windows Azure before promoting to production.

Prerequisites

Before you start, make sure you have the following software installed on your computer:

Windows 7
Visual Studio 2010 SP1 or Visual Web Developer Express 2010 SP1
SQL Server Express 2008 R2 (this is installed with Visual Studio by default).
Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio 1.6 (November 2011)

The links in the list will install the required software using the Web Platform Installer.

Creating a Windows Azure Account

If you already have a Windows Azure account, skip this section.
Most of these steps are self-explanatory, but screen shots are provided so you can see how the process works even if you are not actually working through the steps of the walkthrough.

To create a Windows Azure account

Open a browser and go to http://www.windowsazure.com/, then click free trial.
On the next page, click sign up now.
Sign in with your Live ID credentials. If you don't have a Live ID account, create one. (After signing in, you might have to click sign up now again.)
In step 1 of the Create Account wizard, click Next.
In step 2 of the wizard, enter a mobile phone number and click Send text message.
Your mobile phone receives a text message with a number in it, and a text box appears in which you can enter the number.
Enter the number that you receive in the text message, and click Verify code.
After successful verification, click Next.
Enter billing information. (A credit card is required but is not charged for the free trial.)
Use a phone to verify your account again.
On the Windows Azure Home page, click manage.
If you are asked to select the new or the old version of the Windows Azure Management portal, choose the new version.
The Windows Azure Management Portal is the web site you will be using to manage your Windows Azure hosted service for this walkthrough.
For more information about the portal, see The New Management Portal.
Note: The Management Portal uses Silverlight. If Silverlight is not installed on your computer, you're prompted to install it.

Your Windows Azure account is now ready to use.

Creating an ASP.NET Application to Deploy

In this section you create an ASP.NET application that you can deploy to Windows Azure. You aren't creating a Windows Azure solution right now, because this part of the walkthrough is just to show you how to deploy a project to Windows Azure that wasn't originally created for Windows Azure. You'll create a Windows Azure project later.

To create the ASP.NET application

Start Visual Studio 2010 as an administrative user. (In the Windows Start menu, right-click Microsoft Visual Studio 2010 and click Run as Administrator).
Visual Studio needs administrative privileges to run the Windows Azure compute emulator and to publish to Windows Azure.
In the File menu, click New Project.
In the New Project dialog box, expand the node for a programming language, select Web, and select ASP.NET MVC 3 Web Application.
Name the solution HelloAzureWeb and click OK.
In the New ASP.NET MVC 3 Project dialog box, select Internet Application and click OK.
After Visual Studio creates the project, press Ctrl+F5 to run the application. The home page appears in the browser.

In order to publish this web project to Windows Azure, the next step is to add a Windows Azure deployment project to the solution.

Adding a Windows Azure Deployment Project

A Windows Azure deployment project provides Visual Studio Publish Wizard functionality that you need in order to deploy an existing web project to Windows Azure. It also makes it possible for you to run the application locally in Windows Azure emulation mode.

To add a Windows Azure deployment project

In Solution Explorer, right-click the HelloAzureWeb project and select Add Windows Azure Deployment Project.
Visual Studio creates a Windows Azure deployment project and names it HelloAzureWeb.Azure.
Press Ctrl+F5 to run the solution using the Windows Azure compute emulator.
The same home page appears but with a different URL, and you can see the Windows Azure compute emulator in the system tray.

You are now ready to publish to Windows Azure.

Deploying to Windows Azure

For your Windows Azure account to host a web application, it must have a hosted service and a storage account. You can create these services in the Management Portal or from Visual Studio while you set up a Publish profile. In this walkthrough you'll do it in Visual Studio. The Publish profile can take some time to set up at first. But once you're done, future deployments are simple, because all of the settings are saved and you only have to click a button to deploy an application update.

To deploy to Windows Azure

In Solution Explorer, right-click the HelloAzureWeb.Azure project and click Publish.
As an alternative, you can right-click the web project and click Publish to Windows Azure.
In the Publish Windows Azure Application wizard, click Sign in to download credentials.

Note: If you are already logged in to a Windows Live ID but you need to use a different ID for your Windows Azure account, you need to sign out first. If the Sign Out link does not work, close all instances of your browser, open a new browser window, and select InPrivate Browsing (for Internet Explorer), and then click Sign in to download credentials again.
In the Windows Azure Platform sign-in page, enter your credentials and click Sign in.
The next page that appears starts downloading a .publishsettings file. Save this file. You will use it in the next step.

Security Note: This file contains a certificate that provides administrative credentials for your Windows Azure account. Make sure you keep the file safe from unauthorized access.
Switch back to Visual Studio. In the Sign in step of the Publish Windows Azure Application wizard, click Import and select the file that you just downloaded.
The Choose your subscription drop-down list is now populated with your Windows Azure subscriptions. If you have more than one, choose the subscription you want to use.
Click Next.
The wizard advances to the Settings step. If you don't have any hosted services defined for your Windows Azure account yet, Visual Studio automatically prompts you to create one. In that case you can skip the next step.
If the Create Windows Azure Services dialog box does not appear automatically, display it by clicking Create New in the Hosted service list.
In the Create Windows Azure Services dialog box, enter a unique name for the hosted service. This name has to be unique because it will be part of the URL that you'll use to access the service over the Internet.
Select a region.
You typically choose a region that is closest to where you expect most of your web traffic to come from. However, note that the Anywhere US option is more expensive than choosing a specific US region as shown in this illustration, because it causes the application to be hosted in multiple data centers in order to be closer to more U.S. regions.
Click OK.
If you see an error indicating that the DNS name is already taken, choose a different name and click OK again.
To see that your hosted service has been created, return to the Management Portal and click Hosted Services in the navigation pane.
You see the new hosted service in the items list.
In the illustration, notice that there's a (1) after Storage Accounts. When Visual Studio created the hosted service for you, it also automatically created a storage account. The storage account is required for profiling, IntelliTrace, and diagnostics data, and because the publish process temporarily stores the deployment package there during deployment. (When deployment is finished, the package is removed from the storage account.)
Switch back to Visual Studio to return to the publish wizard. The following illustration shows the default settings based on what you've done so far.
In the Environment drop-down list, select Staging.
You typically deploy an application to staging first, verify that it is running correctly, and then promote it to production.
Select the Enable Remote Desktop for all roles check box.
This causes the Remote Desktop Configuration dialog box to be displayed.
In the Remote Desktop Configuration dialog box, enter credentials that you will use for Remote Desktop access and to publish by using Web Deploy.
These are not pre-existing credentials. You can create any ID and password you want here.
Remote Desktop access is useful during development for tasks like debugging and checking log files. However, you shouldn't use Remote Desktop to configure the server or install software, because whatever you do to a live instance of the VM will be lost the next time Windows Azure takes down the virtual machine and creates a new one.
For information about how to connect after the application has been published, see Using Remote Desktop with Windows Azure Roles.
Select the Enable Web Deploy for all web roles check box.
This lets you update the application using Visual Studio one-click publish or web deployment packages, as you'll see later in this walkthrough. When you select this option, a warning icon appears to the right. If you hold the mouse pointer over the icon, you see a message warning that Web Deploy uses a self-signed untrusted certificate and should not be used for uploading sensitive information. (If you want to use Web Deploy with sensitive information, you can connect to the virtual machine and add a trusted certificate to IIS on the virtual machine. For more information, see To Make Web Deploy Secure.)
Using Web Deploy is a quick way to update an application that is running in Windows Azure, but it has the same disadvantage as using Remote Desktop — the next time Windows Azure takes down the virtual machine and creates a new one, any updates done by using Web Deploy are lost. Therefore, it is a tool intended only for use during development when you want to make quick updates and plan to do a full Windows Azure deployment later, before promoting the application to production.
The Common Settings tab of the Settings wizard step now looks like the following illustration:
For this wizard step there is also an Advanced Settings tab that lets you customize the name that will be given to the Deployment in the Management Portal, lets you select a storage account to use for deployment, and lets you enable tracing or profiling. You do not need to change any of the advanced settings for this walkthrough.
Click Next.
In the Summary step, click Save.
The profile is given a name that is created by concatenating the hosted service name with the environment name. In this example, the name is DemoHelloAzureServiceStaging. You can change the name of the profile by choosing <Manage…> from the Target profile drop-down list. Profiles are stored in the Profiles folder of the Windows Azure deployment project as XML files with the extension .azurePubxml.
Click Publish.
The Output window shows the results of preparing the deployment package for publishing. This part of the deployment process finishes fairly quickly. In this stage of the deployment, Visual Studio is creating a Windows Azure deployment package. This package is a file that contains all of the information Windows Azure needs in order to create a virtual machine that will run the HelloAzureWeb application.
The Windows Azure Activity Log window then shows the progress of deployment to Windows Azure. You can see more details by clicking the arrow at the left. (The illustration shows Pending under WebsiteURL. When deployment is finished, this becomes a link that you can click to run the application in your browser.)
This part of the deployment process can take several minutes. In this part of the process, the package is uploaded to Windows Azure, and Windows Azure creates a new web role instance. Windows Azure begins with the standard web server configuration, then applies all of the information in the package to that virtual machine in order to prepare it to run the HelloAzureWeb application and to make the application available over the Internet.
If you ever need to cancel before deployment is finished, right-click the Deploying …line in the Activity Log window and click Cancel and remove. (After deployment has finished, you have to use the Management Portal to remove a Deployment.)
When the deployment is finished, return to the Management Portal in your browser and display the hosted service as you did earlier. Under the hosted service, you now see the new Deployment in the staging environment.
Click the line that shows the new Deployment. Then in the Properties pane of the Management Portal, click the link in the DNS name box.
The browser opens to the home page of your HelloAzureWeb application.
Your application is now running in the cloud. Since it is in staging, the URL is <GUID>.cloudapp.net. When you promote it to production, the URL will be <yourhostedservicename>.cloudapp.net.

As an alternative to using the Management Portal for viewing the completed Deployment and getting the URL to run the application in staging, you can use Server Explorer in Visual Studio.

To use Server Explorer to view a Deployment

If Server Explorer is not visible, click Server Explorer in the View menu.
Expand the Windows Azure Compute node to see the Windows Azure Deployment that you just finished creating. If you restarted Visual Studio since you published to Windows Azure, the node won't be there. You can perform the following steps to add it.
To add a Deployment environment
1. Right-click Windows Azure Compute and select Add Deployment Environment.
2. In the Add deployment environment dialog box, expand the node for your Windows Azure subscription and expand the node for your hosted service. Select Staging, then click OK.
In Server Explorer, under the Windows Azure Compute node, expand the node for your staging environment. Expand the node for your web role to see the status of instances of the role (you only have one for this walkthrough). The illustration shows a green arrow indicating that the role instance is in Ready status. (During deployment, you see an icon indicating the instance is not ready, and the instance name includes (Initializing) until deployment is complete.)
Right-click the staging environment and select View in Browser. This lets you view the HelloAzureWeb application running in the cloud, as you did earlier by clicking the DNS name in the Management Portal.

Deploying an Update by Using Web Deploy

As you have seen, deploying to Windows Azure can take time. However, after the initial deployment, you can use a simpler and faster process to deploy updates. You enabled this process when you created credentials for Remote Desktop access and selected the Enable Web Deploy for all web roles option in the previous procedure.
It's important to understand the difference between using the Windows Azure Publish wizard and using Web Deploy to update an application that is running in Windows Azure. When you deploy an update using the Windows Azure Publish wizard, you are uploading a new file that contains all of the information needed to set up a VM to run your application, and a new VM is created using this new information. Later, when a VM goes down or has to be taken down for a patch or an update, Windows Azure still has the package with all of the information required for creating a new VM. When you deploy an update using Web Deploy, you are making changes to a running VM instance, and you are not changing the deployment package that Windows Azure uses to instantiate new VMs. The next time Windows Azure needs to take down a VM that was updated by using Web Deploy, those updates will be lost because they are not in the deployment package used to create new VMs.
Another difference is that Web Deploy updates only one server at a time. If you select this option, the Publish wizard will make sure that your hosted service has only one web role instance when you deploy. This is fine for development, but for production you typically want more than one instance.

To deploy an update

Open HomeController.cs or Homecontroller.vb (in the Controllers folder), and change "Welcome to ASP.NET MVC!" to "Welcome to Azure!".
Save the change and press Ctrl+F5 to run the application and verify that you see the change in the home page.
In the Solution Configurations drop-down list, click the Release build configuration. (For this walkthrough you don't need to deploy a Debug build to Windows Azure.)
If you have customized your toolbars, you might not see the Solution Configurations drop-down list. In that case, you can use this method: in the Build menu, click Configuration Manager. Then in the Configuration Manager dialog box click Release in the Active solution configuration drop-down list.
In Solution Explorer right-click the HelloAzureWeb project (not the Windows Azure deployment project), and click Publish.
When the Publish Web dialog box appears, most of the information you need is already filled in.
In the Windows Azure Management Portal, select the Deployment, as you did earlier in order to run the application. Then in the Properties pane, select and copy the ID value.
In the Service URL box of the Publish Web dialog box, if the GUID that precedes cloudapp.net in the URL is different from what you copied, delete that GUID and replace it with the GUID you just copied from the Management Portal.
Enter the credentials you created when you enabled Remote Desktop access, and click Publish.
In a short time, the Output window shows the results of successful deployment. (There will be no new activity in the Windows Azure Activity Log this time.)
To verify that your change was successfully deployed, run the application by using one of the methods shown earlier, namely Server Explorer or the Management Portal. (Click the line that shows the new Deployment, and then in the Properties pane, click the link in the DNS name box.) As expected, the heading now says "Welcome to Azure" instead of "Welcome to MVC".

You have now seen both initial deployment and a Web Deploy update deployment for a web application that was not originally created in a Windows Azure solution. In the next section you'll create a SQL Azure database for the ASP.NET membership system and configure the HelloAzureWeb application to use this database when it runs in the cloud.

Creating and Using a SQL Azure Database

For persistent storage that does not need to be stored in a relational database, such as CLR objects or large files, you can use Windows Azure Storage Services. For relational data, you can access SQL Azure databases in the same ways and with the same tools that you access SQL Server databases. For more information about storage options in Windows Azure, see Data Storage Offerings on the Windows Azure Platform.
For this walkthrough you'll use SQL Azure as the data store for the ASP.NET membership system. In this section you'll perform the following tasks:

Install the ASP.NET Universal Providers. The membership providers that are specified by the default (not for Windows Azure) ASP.NET MVC 3 project template will not work with SQL Azure. For the ASP.NET membership system to use a SQL Azure database, you must install the Universal Providers.
Create a SQL Azure database.
Configure the application to use the SQL Azure database when it runs in the cloud, and deploy that update.
Verify that the application is using the SQL Azure Database when it runs in the cloud.

The database that you create in this section will be used only for the ASP.NET membership system. However, the procedures for creating the database and configuring the application to use it also apply to databases that you create and use for application data.

To install the ASP.NET Universal Providers

In Solution Explorer, right-click the HelloAzureWeb project and click Add Library Package Reference.
In the Add Library Package Reference dialog box, enter system.web.providers in the search box and press Enter. When the System.Web.Providers package appears in the list, click Install.
The NuGet package adds a reference to the System.Web.Providers assembly and adds a new connection string named DefaultConnection in the Web.config file.
```
<connectionStrings> 
 
  <add name="ApplicationServices" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient" /> 
 
  <add name="DefaultConnection" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\aspnet.mdf;Integrated Security=True;User Instance=True;MultipleActiveResultSets=True" providerName="System.Data.SqlClient" /> 
 
</connectionStrings>
```
The ASP.NET membership system will now use the connection information specified by DefaultConnection instead of ApplicationServices. The Universal Providers package also configures session state to use server memory, which is only appropriate for hosted services configured to use a single web role instance. For a production application that has multiple instances, you need to configure session state to use Windows Azure Storage or SQL Azure.

To create a SQL Azure database

In the Windows Azure Management Portal, select Database in the navigation pane and then click Create a new SQL Azure Database.
In the Create Database wizard, specify your subscription and choose New Server in the Server drop-down list, then click Next.
Select the region that you expect will be geographically closest to most of your users (make sure that it's the same region you chose for your hosted service), and then click Next.
Enter credentials for the login that you will use to access the database.
These are not pre-existing credentials. You can create any ID and password you want here.
Click Next.
Select Allow other Windows Azure services to access this server to enable your web role to use the database, and then click Next.
Enter a database name, such as aspnet, and click Finish. For this walkthrough, the default Edition and Maximum Size values are fine.

To configure HelloAzureWeb to use the SQL Azure Database when it runs in Windows Azure

Perform the following steps to get a copy of the connection string for the new SQL Azure database. You'll use this connection string to update a Web.config transform file. When you deploy the HelloAzureWeb project, Web Deploy will change the connection string in the deployed application to the value you put in the transform file. For more information about transform files, see Web.Config File Transformations.
To get a copy of the connection string
1. In the Management Portal, select Database in the navigation pane, expand the node for your subscription, and expand the node for the new server.
2. Select the database you created, and then click the ellipsis button in the Connection Strings box.
3. In the Connection Strings dialog box, copy the ADO.NET connection string.
In Solution Explorer, expand the application Web.config file to see the transform files, and then open Web.Release.config.
In Web.Release.config remove the comments that surround the connection string sample, replace the connection string name with "DefaultConnection", and replace the connection string with the one you copied from the Management Portal.
Replace "myPassword" in the connection string with the actual password.

Add MultipleActiveResultSets=True to the end of the connection string. This is required for the Universal Providers.
The Web.Release.config file now resembles the following example:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> 
 
  <connectionStrings> 
 
    <add name="DefaultConnection" 
 
      connectionString="Server=tcp:jk3mpjk3mpg.database.windows.net,1433;Database=aspnet;User ID=HelloAzureWebAdmin@jk3mpjk3mp;Password=password;Trusted_Connection=False;Encrypt=True;MultipleActiveResultSets=True" 
 
      xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/> 
 
  </connectionStrings> 
 
  <system.web> 
 
    <compilation xdt:Transform="RemoveAttributes(debug)" /> 
 
  </system.web> 
 
</configuration>

Note: This configures the application to use an account that has administrative rights. To use an account that has more restricted permissions, create a user that has the permissions you want and specify that user's credentials here. For information about how to add users, see Adding Users to Your SQL Azure Database.

You are now ready to publish the project. When you publish, the only change that will be made in the Windows Azure Deployment will be the update to the Web.config file.

Make sure that the HelloAzureWeb project (not the Windows Azure deployment project) is selected in Solution Explorer, the build configuration is set to Release, and the Publish profile is set to HelloAzureService – Staging. Then click the Publish Web button.
If your toolbar does not look like this, you can also invoke one-click publish by right-clicking the HelloAzureWeb project in Solution Explorer and clicking Publish.

To test the HelloAzureWeb application

Run the application by using one of the methods shown earlier.
When the home page appears, add account/register to the URL in the browser address bar and press Enter. The Create a New Account page appears.
Creating an account causes ASP.NET to create the membership database.
Enter credentials for a user account and click Register.
ASP.NET creates the membership database and adds the new user. The browser returns to the home page and indicates that you are logged in.

You now have an application running in the cloud and accessing a cloud database. However, it's still running in staging and you can only access it using a URL that includes a GUID. In the next section you'll promote the application to the production environment.

Promoting the Application to Production

In the production environment you can access your web application by using a URL with the name you specified. In the sample created for this walkthrough, that URL is http://DemoHelloAzureWeb.cloudapp.net; your URL will depend on the name you used for your hosted service.
For this walkthrough, you are skipping a couple of steps that you would take if this were a real application. One step is to specify that Windows Azure should create multiple web role instances to run your application rather than just one. Another step is to publish the application again using the Windows Azure Publish wizard. This would update the deployment package that Windows Azure uses to create VMs so that the two updates you made by using Web Deploy would not be lost the next time Windows Azure takes down the virtual machine and creates a new one.

To promote from Staging to Production

In the Hosted Services pane of the Windows Azure Management Portal, select the Deployment that you created. You'll notice that the Environment column indicates that this Deployment is in the staging environment.
In the toolbar, click Swap VIP. VIP refers to the virtual IP addresses for staging and production: when you click this button, the production URL is routed to the Deployment currently in staging. If you had a Deployment in production, the staging URL would be routed to that Deployment.
In the Swap VIPs dialog box, click OK.
When the swap is complete, the staging Deployment is in the production environment.
Test the application by opening a browser and using the <hostedservicename>.cloudapp.net URL.
Log in using the credentials you created while the application was in staging. This verifies that you are still successfully accessing the same database.

This completes the section of the walkthrough that shows how to deploy an existing ASP.NET web application to Windows Azure. The following section shows how to create a solution from the beginning as a Windows Azure solution.

Creating an ASP.NET Windows Azure Web Project

In this section you'll see how to create a new Windows Azure web project. The Visual Studio templates for creating Windows Azure solutions automate much of the solution setup that you did earlier in this walkthrough in order to migrate an existing application to Windows Azure.

To create a Windows Azure solution

In the Visual Studio File menu, click New Project.
In the New Project dialog box, expand Visual C# or Visual Basic and select Cloud. In the center pane you see Windows Azure Project.
Specify a name and location and click OK.
In the .NET Framework 4 roles pane of the New Windows Azure Project dialog box, expand the node for your preferred programming language, and select ASP.NET MVC 3 Web Role. Then click the right arrow to copy the selected node to the Windows Azure solution pane.
In the Windows Azure solution pane, hold the mouse pointer over the MvcWebRole1 line to display the rename and delete icons. Click the rename icon (a pencil), and specify a name for the role, such as HelloAzureWeb, then click OK.
In the New ASP.NET MVC 3 Project dialog box, select Internet Application and then click OK, the way you did when you created an MVC project by itself earlier in this walkthrough.
After Visual Studio finishes creating the solution, the projects in Solution Explorer look similar to the first solution you created after you added a Windows Azure deployment project.
There are some differences in the web project compared to the project that was not created originally for Windows Azure. For example, the web project has the ASP.NET Universal Providers already installed so that you can use the ASP.NET membership system with a SQL Azure database. The project also includes a WebRole.cs file that you can use to add code to customize the web role when it starts.

At this point the solution is ready to publish. In order to publish it, you can use the same procedures you used earlier in this walkthrough after you added a Windows Azure deployment project to an existing solution.

All Things Mobile, Because It's What I Do...

Tuesday 13 March 2012

Walkthrough: Hosting an ASP.NET MVC Application on Windows Azure