Deploying LightSwitch Applications to Windows Azure

The new Microsoft Visual Studio LightSwitch aims to simplify the creation of classic line-of-business (LOB) forms-over-data applications. LightSwitch reduces the overhead of building these applications by performing much of the heavy lifting of creating connections to databases (the data-storage tier), displaying a professional UI (the presentation tier) and implementing business logic code (the logic tier).

To further simplify your life, you can host such applications on Windows Azure, an Internet-scale cloud services platform hosted on Microsoft datacenters. The platform includes Windows Azure, a cloud services OS, and SQL Azure, a database service hosted in the cloud. Hosting a LightSwitch application on the Windows Azure eliminates the need to dedicate resources to infrastructure management, such as Web servers and data servers: Windows Azure can take care of all of that for you.

In this article I’ll take a look at how to deploy a LightSwitch application to Windows Azure using the Vision Clinic sample application, which is available for download at bit.ly/LightSwitchSamples. Vision Clinic is a simple LOB application designed for an optometrist’s office. The application can be used to manage patients and appointments, as well as products the clinic’s patients may require. It uses two databases: the intrinsic application database, which manages patients and their appointments, and an attached database called PrescriptionContoso that manages products available for sale at the clinic. The original walk-through shows how to deploy the application as a two-tier desktop application: the application runs completely on the client user’s machine, but the data for the application is hosted elsewhere. After completing the steps in this article you’ll be able to publish your application on Windows Azure.

Attaching to a SQL Azure Data Source

The walk-through makes use of a sample external database—the PrescriptionContoso database, which you can download from MSDN and install to your local development machine. Because the PrescriptionContoso database is an attached data source, you’ll have to create and populate the database yourself. When the finished application is deployed to Windows Azure, it will use both an attached data source and the intrinsic data source hosted in the cloud. Let’s get the hard part out of the way first: creating that attached data source in SQL Azure.

Start by logging in to your Windows Azure account at windows.azure.com. If you don’t already have an account, you can sign up for one at the same site. Once you’ve signed in to the Windows Azure Management Portal, select the Database node in the navigation pane on the left and view the database information for your subscription in the central items list. (See bit.ly/pcwCLX for a description of the layout of the portal.) If your account doesn’t yet have a database subscription, select your subscription in the navigation panel, and choose Create from the ribbon across the top (see Figure 1). This will launch a server-creation wizard, allowing you to choose your SQL Server hosting region and your administrator login name and password, and to create firewall rules (see Figure 2). You’ll need to add at least two firewall rules for your server:

1. Select the checkbox to allow other Windows Azure services to access this server. This enables the Vision Clinic application, which will eventually be hosted on Windows Azure, to access this database.
2. Add a range of IP addresses that will also be able to access the server. These are IP addresses of computers that can manage the database through the Windows Azure Management Portal. For example, the IP address of my PC is 131.107.xxx.yyy, so I added a range of addresses starting at 131.107.0.0 and ending at 131.107.0.255. Don’t forget: You’ll still need your Windows Azure subscription login information to manage the database through the portal, but setting this firewall rule allows Visual Studio to access to the database during development. Once you’ve created and deployed the application, you can remove this firewall rule to prevent any external machines from accessing the database.

Figure 1 Windows Azure Management Portal: Creating a Database Server

Figure 2 Using the Wizard to Create a Database Server

With the database server created, you can now view its properties. Select the database server in the navigation pane (mine was called “pq96r63lrm”). The items list includes all of the firewall rules you created, as well as a default “master” database.

You’ll want to create a new database for the PrescriptionContoso information. Make sure your database server has been selected in the navigation pane, and then click the Create button from the ribbon in the Windows Azure Management Portal. For your database name, type “PrescriptionContoso” and leave the default settings for Edition and Maximum size (see Figure 3).

Figure 3 Creating the PrescriptionContoso Database

Now it’s time to add the tables to the PrescriptionContoso database. Select the new database in the left-hand navigation panel and click the Manage button. This will open a new Web page that allows you to manage the PrescriptionContoso database. On the new page, select New Table. This will open a table editor page (see Figure 4). Name the table “Product” and enter the information shown in Figure 5 for the schema.

Figure 4 Adding the Product Table to the PrescriptionContoso Database

Figure 5 Schema for the Product Table

Create another new table, name this one “ProductRebate,” and enter the information in Figure 6 for the schema. As with all attached data sources, the connection string LightSwitch uses to interact with the PrescriptionContoso database will be stored in the web.config file generated as project output. Three-tier applications store the web.config file on the IIS server where it can’t be seen by application users.

Figure 6 Schema for the ProductRebate Table

However, with two-tier applications, all users who install the application can see the web.config file. Thus, it’s important to create a non-admin login and user for the PrescriptionContoso database for use at run time. This user will not be a full database server administrator and will be able to perform only Create, Read, Update, Delete (CRUD) operations on the PrescriptionContoso database. You create a new login for the database by opening a connection to your master database and executing the following commands in SQL Server Management Studio Express or using sqlcmd (see bit.ly/ok2Mdh for more information):

CREATE LOGIN <user> WITH password='<password>';

Be sure to substitute a new <user> and <password>. The password you provide must be strong (see bit.ly/p4BEwU).

Now connect to the PrescriptionContoso database with your SQL Azure administrator account and create a user:

CREATE USER <user> FROM LOGIN <user>;

The database schema has been created, but the table contains no data. You can add data to the table using the data designer on the Windows Azure Management Portal or by migrating the data from the PrescriptionContoso.mdf file included in the sample to the Windows Azure database. You can also use the bcp utility that comes with Microsoft SQL Server 2008 and Microsoft SQL Server 2008 Express (bit.ly/bhH7Ub). Yet another option is to add the data through a running application. It’s possible to have a two-tier application attach to a data source hosted on SQL Azure, so let’s populate the database by publishing and running the Vision Clinic example as a two-tier application.

With the schema in place on Windows Azure for the attached data source, it’s time to publish the application. You should be able to follow the deployment steps in the Vision Clinic walk-through (bit.ly/py9yna) until step 8. On the Other Connection Information page, enter the connection string to the database that was just created. You’ll find the connection string in the Windows Azure Management Portal by selecting the database in the navigation pane and hitting the Connection Strings button in the properties pane. Copy the ADO.Net connection string (see Figure 7) and paste it into the PrescriptionContoso textbox in the LightSwitch publish wizard. Open the Connection Properties dialog and make sure you type the user name and password for the new user you created. Use the Test Connection button to make sure you’re able to connect to the SQL Azure database.

Figure 7 Getting the Connection String for the PrescriptionContoso Database

After you enter the connection string for the attached data source, you can finish the publish wizard and wait for your application to be published. Once it’s published, you can view the generated web.config file among the publish output and see that the connection string to your Windows Azure database is now in place. Because the application is still two-tiered, end users will need the Microsoft .NET Framework 4 installed on their computers, but the application can now read and write data to the PrescriptionContoso database on SQL Azure.

Hosting the Application on Windows Azure

Next, let’s take a look at hosting the application completely on Windows Azure. Because Windows Azure is running IIS, it’s possible to have the same types of applications on Windows Azure as on an IIS server residing in your enterprise. Application users will only need to have Microsoft Silverlight 4 or higher to run the application, rather than the full .NET Framework 4, greatly simplifying client deployments. You’ll modify the Vision Clinic sample to publish the application to Windows Azure. The service tier will still require the .NET Framework 4, but Windows Azure will automatically provision that for you.

Before you can publish Vision Clinic to Windows Azure, there’s some additional preparation that needs to be done to your subscription. You’ll need to pre-create a hosted service in the Windows Azure Management Portal. This service is what will run the server-side code of the deployed application. You’ll also need to create a storage account, which will be used to store the application binaries while the application is deploying. The application data will be stored in a SQL Azure database.

Navigate back to the portal and select the Home button in the navigation pane (see Figure 8). In the ribbon, you should see a button marked New Hosted Service. Clicking this button shows a new window in which to create your Hosted Service. Enter a service name, URL prefix and region for your application. For Deployment Options, choose “Do not deploy”; the LightSwitch publish wizard will be deploying the application. The Storage Account is created in a similar fashion: Click the New Storage Account button on the ribbon and fill out the fields in the pop-up that comes up. You should now be able to navigate to the Hosted Services and Storage in the Windows Azure Management Portal. The rest of the Windows Azure configuration can be done through the LightSwitch publish wizard.

Figure 8 Creating a Hosted Service in the Windows Azure Management Portal

Let’s make some updates to the Vision Clinic sample in the LightSwitch IDE. Because the application is being hosted in the cloud, it’s a good idea to secure your LightSwitch application using Forms authentication. (For more information, see the article, “Securing Access to LightSwitch Applications,” in this issue.) This is configured in the application properties access control tab of the VisionClinic application (see Figure 9). Now navigate to the Application Type tab. The application will remain a desktop application, because you want the application to be able to interact with other applications installed on an end user’s computer (for example, exporting data to Microsoft Excel). For the Application Server Configuration, select Windows Azure (see Figure 10). Click on the Publish… button in the designer to begin the publishing process. 

Figure 9 Using Forms Authentication

Figure 10 Choosing to Host Application Services on Windows Azure

Hit Next twice in the wizard to get to the Connect to Windows Azure page. This page requires two pieces of information (see Figure 11):

1. The ID of your account subscription
2. A management certificate thumbprint

Figure 11 Connecting to Windows Azure in the LightSwitch Publish Wizard

The subscription ID is obtained from the Properties pane of the hosted service in the Windows Azure Management Portal. If this is the first time you’re publishing to Windows Azure, you’ll also have to create a new certificate that will be used to confirm your identity to the Windows Azure service during the publish process because there’s no login during the publish process. In the drop-down, select the option to <Create new self-signed certificate…>. Doing this adds a new certificate to your computer’s certificate store. Now you need to upload certificate information to your Windows Azure account. Choose Copy Path in the publish wizard and then go back to the portal and select the Management Certificates 
node in the navigation pane. Select Add Certificate from the ribbon and then choose the Browse… button from the ensuing dialog (see Figure 12). Paste in the path that you copied from the publish wizard—and your certificate should now be added.

Figure 12 Adding a Management Certificate to Windows Azure

The Azure Service Configuration page (see Figure 13) in the wizard allows you to specify the names of the hosted service and storage accounts that were created through the Windows Azure Management Portal. These drop-downs should be automatically populated by the wizard once a valid subscription ID and management certificate have been entered on the previous page. You also can choose which Environment the application will be deployed to: Production or Staging. For this example, select Production.

Figure 13 Setting Windows Azure Service and Storage Information While Publishing

Next, you’ll need to specify the Security Settings for the application: a certificate that will be used to establish an SSL connection for the deployed application. Communicating with Windows Azure over HTTPS protects business data exchanged between client and server, as well as the user name and password when using Forms authentication information. The wizard allows you to select from existing certificates that have already been uploaded to Windows Azure, or to upload a new certificate, as shown in Figure 14. The drop-down lets you create a new self-signed certificate that can be uploaded to Windows Azure. The Silverlight out-of-browser launcher tool that LightSwitch desktop applications use requires a trusted certificate on the server when run over HTTPS. If the certificate isn’t trusted, the application won’t run correctly. The best approach is to use a certificate signed by a trusted Certificate Authority. A less-secure alternative is to pre-install the new self-signed certificate in the client’s certificate store (see bit.ly/ra3CKG for more information). A LightSwitch client that runs in the browser can work with a self-signed certificate, but the browser will show a warning before loading the Silverlight application.

Figure 14 Setting the Certificate to Use for an HTTPS Connection

The next piece of information to enter into the publish wizard is the database connection settings for the intrinsic data source. This time, LightSwitch will automatically create the database and publish the schema to SQL Azure. You can start by getting the connection string of the master database that’s created automatically for you on SQL Azure. Paste this value into the administrator connection string in the publish wizard. Bring up the connection properties in the publish wizard by clicking on the builder button and enter a new database name to replace “master” (for example, “VisionClinic”)—see Figure 15. Update the user password (the connection string that was copied contains only a dummy password). Also consider setting the Encrypt connection property to True and the TrustServerCertificate connection property to False in the Advanced Properties for the connection string. This ensures the connection is encrypted and man-in-the-middle attacks aren’t possible. You don’t want the application to use the administrative connection string for its CRUD operations, so create a new login for the database server by clicking the Create Database Login button on the publish wizard.

Figure 15 Setting the Connection String for the Application Data

Next, you should enter a user name and password for the application’s initial security administrator. A security administrator provides access to the security administration screens in the running LightSwitch client application. These screens allow the security administrators to provide initial access to other users to run the application.

You can continue to use the PrescriptionContoso connection string that was previously added on the Other Connections wizard page. On the Specify a Certificate wizard page, you can choose to sign the client application (see Figure 16). Signing the application allows the Silverlight out-of-browser launcher to automatically update the application on a user’s machine when you publish a newer version of the application to Windows Azure (bit.ly/iY6lFP).

Figure 16 Specifying a Certificate to Sign the Client Application

When the wizard is done, the application is packaged up and sent off to Windows Azure for installation. When publishing is complete, LightSwitch will launch the Windows Azure Management Portal. LightSwitch tells Windows Azure to start the hosted service, but it may take a few minutes for the process to complete. You can track the progress of the deployment in the Hosted Service tab of the navigation pane on the portal.

When the deployment has been completed, select Hosted Services in the navigation pane of the portal, and then open child nodes in the items list to reach the completed “Vision_Clinic” deployment (see Figure 17). The Properties window should contain a DNS name for your deployed application; clicking on this link will open the Web page to your application, after first automatically redirecting the application to use HTTPS. This is the URL clients should use to run the application. It’s possible—but highly discouraged—to turn HTTPS redirection off by setting the Microsoft.LightSwitch.RequireEncryption property to “false” in the service configuration file (described in the following section).

Figure 17 Viewing the Published Application in the Windows Azure Management Portal

Publish Output

Let’s take a look behind the scenes. There are three output files unique to publishing to Windows Azure. They are:

• Vision Clinic.cspkg
• ServiceDefinition.csdef
• ServiceConfiguration.cscfg

In the build output directory, you’ll see a .cspkg file. This file is a bundle of all of the files relevant for the Windows Azure application: the application binaries as well as the service definition and configuration files. During the publish process this file is transferred to Windows Azure to configure the hosted service.

ServiceDefinition.csdef (see Figure 18) is the Cloud Services definition file for the application. This XML file dictates how the Web site for your application can be configured. The file declares that the one WebRole, LightSwitchWebRole (under the WebRole node), should enable both HTTP and HTTPS (the Sites and EndPoints nodes). It specifies that HTTPS will require a certificate stored on the Windows Azure machine (Certificates node), and declares customizable configuration settings specific to this application (ConfigurationSettings node). These settings include diagnostics logging information as well as whether to redirect HTTP calls to HTTPS.

Figure 18 The ServiceDefinition.csdef File

<ServiceDefinition name="Vision_Clinic"
  xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="LightSwitchWebRole"
           vmsize="Small"
           enableNativeCodeExecution="true">
    <ConfigurationSettings>
      <Setting name="Microsoft.LightSwitch.Trace.Enabled" />
      <Setting name="Microsoft.LightSwitch.Trace.LocalOnly" />
      <Setting name="Microsoft.LightSwitch.Trace.Level" />
      <Setting name="Microsoft.LightSwitch.Trace.Sensitive" />
      <Setting name="Microsoft.LightSwitch.Trace.Categories" />
      <Setting name="Microsoft.LightSwitch.RequireEncryption" />
    </ConfigurationSettings>
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="HttpIn" endpointName="HttpIn" />
          <Binding name="HttpsIn" endpointName="HttpsIn" />
        </Bindings>
      </Site>
    </Sites>  
    <Endpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
      <InputEndpoint name="HttpsIn" protocol="https" port="443"
        certificate="SSLCertificate" />
    </Endpoints>
    <Certificates>
      <Certificate name="SSLCertificate" storeLocation="LocalMachine"
        storeName="My" />
    </Certificates>
  </WebRole>
</ServiceDefinition>

Figure 19 shows the Cloud Services configuration file (ServiceConfiguration.cscfg) contains the actual configuration settings for the Web Role. If you look at the ServiceConfiguration.cscfg file in the build output directory, you’ll see a setting that contains the SSL certificate thumbprint that was specified in the “Security Settings” page of the publish wizard.

Figure 19 The ServiceConfiguration.cscfg File

<ServiceConfiguration serviceName="Vision_Clinic"
  xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="LightSwitchWebRole">
    <Instances count="1" />
    <ConfigurationSettings>
      <!-- A value of true will enable diagnostic logging on the server -->
      <Setting name="Microsoft.LightSwitch.Trace.Enabled" value="false" />
      <!-- A value of true only lets local access to Trace.axd -->
      <Setting name="Microsoft.LightSwitch.Trace.LocalOnly" value="true" />
      <!-- The valid values for the trace level are: None, Error,
        Warning, Information, Verbose -->
      <Setting name="Microsoft.LightSwitch.Trace.Level"
        value="Information" />
      <!-- A value of true will indicate that logging sensitive
        information is okay -->
      <Setting name="Microsoft.LightSwitch.Trace.Sensitive" value="false" />
      <!-- The semi-colon separated list of categories that will be
        enabled at the specifed trace level -->
      <Setting name="Microsoft.LightSwitch.Trace.Categories"
        value="Microsoft.LightSwitch" />
      <!-- A value of true will indicate http requests should be
        re-directed to https -->
      <Setting name="Microsoft.LightSwitch.RequireEncryption"
        value="true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="SSLCertificate"
        thumbprint="CD27FF4C85A2AD495A054D606E354BCAAD01B3D8"
        thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
</ServiceConfiguration>

There are two ways to change the additional configuration settings for the Web Role. One option is to edit the ServiceConfiguration.cscfg file contained in the LightSwitch project directory. For example, to enable diagnostic logging on the server, you’ll need to modify the Microsoft.LightSwitch.Trace.Enabled property, like this:

<Setting name="Microsoft.LightSwitch.Trace.Enabled" value="true" />

The values set in the project’s cloud service configuration file in the project will end up in the built cloud service configuration file.

It’s also possible to change the values in ServiceConfiguration.cscfg post-deployment. In the Windows Azure Management Portal, click Hosted Services, Storage Accounts & CDN, then click Hosted Services in the lower part of the navigation pane. Drill down to the Vision_Clinic deployment item in the items list. Once there, you should see the Configure button on the ribbon. Clicking this button allows you to either upload a new service configuration file or edit the existing file.

Using Additional Windows Azure Features

Although there’s no built-in support for many additional Windows Azure features, with some simple modifications to your project’s Service Definition.csdef and ServiceConfiguration.cscfg files, it’s possible to take advantage of additional Windows Azure features. Here are a couple of examples.

Virtual Machine (VM) Size Windows Azure provides several sizes of compute instances, which dictate the amount of resources dedicated to each service instance: the greater the VM size, the more expensive the application is to run. LightSwitch applications default to a Small compute size, but you can change the level by updating the “vmsize” attribute of the default WebRole in the ServiceDefinition.csdef file:

<WebRole name="LightSwitchWebRole"
         vmsize="ExtraSmall"
         enableNativeCodeEecution="true">

ExtraSmall (which is currently available in beta release) is the least resource-intensive service available on Windows Azure. A summary of all VM sizes is available at bit.ly/qdTFZp.

Microsoft Windows AzureConnect Windows Azure Connect (bit.ly/nvTg6Z) allows for IP-based network connections between Windows Azure and on-premises resources. Windows Azure Connect, currently in CTP, provides a way for an application deployed to Windows Azure to connect to an on-premises SQL Server database or SharePoint site. You could also have a Windows Azure VM join your local domain, enabling your application to use Windows Authentication. It’s possible to configure your LightSwitch application to take advantage of the Windows Azure Connect features. While performing this configuration is beyond the scope of this article, keep an eye on the “Deployment” page of the LightSwitch Developer Center (bit.ly/pxmV5d).

Mike Wade is a developer working on Visual Studio LightSwitch. His focus on the team is deployment and project tooling features.

Thanks to the following technical experts for reviewing this article: Beth Massi and  John Rivard

Share this content

Comments (0)

Sign in to Leave a Comment