Choosing an Application Topology

LightSwitch relies on application services that can run in IIS, Windows Azure, or the end user’s machine. If you’re deploying a web application (either Silverlight or HTML client), your application services must be hosted in IIS or Windows Azure. But if you’re deploying a Silverlight desktop application, you can choose to host the application services on the local machine, and this is a configuration that’s called a “two-tier” setup. The advantage of running the services locally is that it’s easier to set up. Unlike a “three-tier” setup, you don’t need to go through the tricky process of setting up a web server, or understanding how Windows Azure works. But the disadvantage is that you’ll need to install the services on every machine that you want to run your application. Two-tier applications are therefore more suitable for single-user applications or applications that don’t have many users. In this type of deployment, you can also choose to install the database on the end-user machine by using a local instance of SQL Server or SQL Express. This means that you can run your entire application from a single machine.

Choosing Whether to Publish or Package

If you want to host your application services in IIS, you can choose to either publish or to package your application (Figure 18-2).

If you choose to publish your application, LightSwitch deploys it directly from Visual Studio onto your IIS server. It’s very easy to publish an application, but you’ll need to carry out more work to prepare your IIS server beforehand. The operating systems that support publishing are Windows Server 2003 or above, and Windows 7 or above.

The second option is to package your application. Packaging produces a set of install files that you would manually copy and install on your server. Packaging an application is easier than publishing. There are fewer tasks to carry out on your web server, and you don’t need to struggle to make Visual Studio talk to IIS. For example, your application will fail to publish if a firewall blocks the ports that are required for publishing to work (port 8172 by default). If you’re developing your application on a machine that isn’t on the same domain as the server that you want to deploy to, packaging is a good choice.

Setting Up Your Workstations

In order to set up a workstation to run LightSwitch, there are actually very few tasks for you to carry out. HTML client applications require only a web browser, so in almost all cases, you don’t need to carry out any additional work. Silverlight applications require the Silverlight 4 runtime. If a user doesn’t have the runtime installed and attempts to run a Silverlight browser application, the application displays a web page that prompts the user to download the Silverlight runtime from the Microsoft web site. If you’re in a corporate environment, you can distribute the Silverlight runtime by using group policy, SMS (Microsoft Systems Management Server), or some other software distribution mechanism. Some companies have policies in place that block Silverlight or Adobe Flash. If you have a policy like this in place, your Silverlight LightSwitch application will simply not work.

Setting Up SQL Server

In all deployment scenarios, you’ll need a database server with SQL Server 2005 or above to host your application. If you’re deploying your application into Windows Azure, you’d create a SQL Azure database rather than carry out an “on premises” installation of SQL Server. If you’re building a two-tier desktop application, you can install SQL Server Express on the client and run your entire application on the workstation. This type of setup is ideal for single-user or stand-alone applications. SQL Server Express is a free edition of SQL Server, and it’s perfect if you don’t have a license for a higher, paid-for edition of SQL. A disadvantage of SQL Server Express is that it limits performance by placing restrictions on the amount of memory and CPU cores that the database engine can use. You can find out more and download SQL Express from the following web site:

http://www.microsoft.com/en-us/sqlserver/editions/2012-editions/express.aspx

A detailed explanation of SQL Server is beyond the scope of this book, but if you want to find out more, SQL Server Books Online (BOL) is an excellent resource: http://msdn.microsoft.com/en-us/library/ms187875.aspx

For the purpose of installing LightSwitch, the topics that you should be familiar with are

• Installing an instance of SQL Server, and using Management Studio
• Creating Databases, Logins, and Users
• Understanding SQL/Windows authentication, and knowing how to create an ADO.NET connection to your database

Data Connections Page

If you choose to publish your application, the wizard shows the “Database Connections” page that’s illustrated in Figure 18-5. This page prompts you for two connection strings. The first connection string specifies the connection that LightSwitch uses to connect to your Intrinsic database at runtime. The wizard uses the second connection string during the publishing stage to create and/or update your Intrinsic database. The buttons next to the connection string text boxes open a dialog that helps you to build a connection string.

Figure 18-5 highlights the warning that the wizard shows when you enter a connection string that uses integrated security. The Publish Wizard allows you to specify only connection strings that use SQL Server authentication. If you’re not happy with this type of authentication, you’ll find out how to manually set up your application so that it uses integrated security later in this chapter.

If you choose to package your application, rather than publish it, the wizard shows the page that’s shown in Figure 18-6. This page allows you to create a new Intrinsic database or to update an existing database.

You’d typically update an existing database if you’re updating an application that you’ve already deployed. When you choose this option, you’ll need to provide a connection string. This allows the wizard to compare your database schema against the existing database and to create an update script.

You might wonder why the wizard doesn’t prompt you to supply database credentials at this point. This is because LightSwitch asks you for the credentials when you actually install the package, and by doing this, it avoids persisting your sensitive credentials in a package file that someone else could get hold of.

Prerequisites Page

If you deploy a two-tier desktop application, you can specify your application’s dependencies by using the page that’s shown in Figure 18-7. By default, your setup package includes the LightSwitch prerequisite component. This component allows LightSwitch to host your application services without IIS being available.

In addition to the LightSwitch prerequisites, you can also specify additional prerequisites by choosing the “Yes” radio button and using the check boxes to select the items that you want to include. When you do this, the wizard automatically includes the .NET 4 Framework and Windows Installer 4.5 packages. LightSwitch requires the .NET 4 Framework to run, and Windows needs the Windows Installer to install the .NET 4 Framework. The final set of radio buttons allows you to specify the install location for your prerequisites. You can select the option that prompts the user to download the prerequisites from the Internet if you want to reduce the file size of your setup package.

The LightSwitch wizard doesn’t allow you to include your own prerequisites. For example, the wizard allows you to add Microsoft SQL Server Express 2008 R2 and 2012. But if Microsoft releases a newer version of SQL Server or if there are any other components that you want to include, there isn’t any option for you to add them to this list.

Security Page

If you’ve enabled authentication in your application, the Application Administrator tab allows you to specify your application administrator. As I showed you in Chapter 16, authentication allows you to determine the identity of the logged-in user and to secure your application by specifying users, groups, and permissions.

Figure 18-8 shows the page that appears when you enable Forms authentication in the properties of your LightSwitch project. If you enable Windows authentication, the Wizard doesn’t show the full name and password text boxes; it’ll prompt you to enter only a domain user name. In the case of Windows authentication, make sure that you enter your administrator’s user name in a format that includes your domain (for example, DOMAINTIM). If you leave out the domain specifier, LightSwitch assumes that you’re referring to a local Windows user on your database server.

If you’re updating an application that you’ve already deployed, you’d choose the radio option that specifies that an application administrator already exists.

Digital Signature/Certificate Page

When you deploy a Silverlight application, you can optionally specify a certificate. But what’s the purpose of a certificate, and why would you want to add one? A digital certificate allows you to sign your application’s XAP file—this is the compiled Silverlight application that runs on the end-user’s machine. Signing a XAP file verifies the authenticity of your application and makes it difficult for a hacker to tamper with your application without it being noticed.

If you don’t sign your application, Windows shows a warning when the user installs your application. This warning states that Windows can’t verify the publisher and that your application might be harmful (Figure 18-9). Your users might be scared by this warning, so it’s a good idea to prevent it from showing by signing your application with a certificate.

Figure 18-10 illustrates the page that allows you to specify a certificate and sign your application. To obtain a certificate, you can purchase one from a third-party company such as VeriSign or use an internal certificate server if your company has one in place. If you want test the process of signing an application, you can generate a self-signed certificate by using a utility called makecert. You can read more about this and find out the command-line switches that you can use by visiting the following MSDN page: http://msdn.microsoft.com/en-us/library/bfsktky3%28v=vs.80%29.aspx

This next page in the wizard is the summary page. This allows you to review your settings and carry on to publish or package your application.

Setting Up IIS on Windows Server 2008/2012

Windows 2008 comes with IIS7, whereas Windows 2012 includes IIS8. Both of these operating systems allow you to set up IIS by using the “Server Manager” application. Once you open Server Manager, go to the Roles Summary group, and click on the Add Roles link (shown in Figure 18-11). This opens the “Add Roles Wizard,” and you’ll find a page in this wizard that allows you to select the Web Server (IIS) server role.

Once you complete the “Add Roles Wizard,” Server Manager adds a “Web Server (IIS)” section inside the Roles group as shown in Figure 18-12.

In the Role Services pane, enable the following three Role Services, as highlighted in Figure 8-12:

• Management Service
• Application Development ASP.NET
• Security Windows Authentication

Setting Up IIS on Windows 8, 7, or Vista

To set up IIS on a client operating system, you’ll need to enable IIS in Windows Control Panel rather than add the “Web Server Role” as in the case of a server operating system. When you open Control Panel, select “Programs and Features” and choose the option to “Turn Windows features on or off.” When the Windows Features dialog opens (Figure 18-13), select the options “Management Service,” Application Development Features ASP.NET, and Security Windows Authentication.

Setting Up IIS 6 on Windows 2003

To set up IIS6 on Windows 2003, you’ll need to install it by using the “Add/Remove Windows Components” option that you’ll find in Windows Control Panel. When the “Windows Component Wizard” dialog opens, select “Application Server” and click on the Details button to open up the dialog that’s shown in Figure 18-14. When you click on the OK button, Windows might ask you to insert the Windows 2003 CD that matches the exact edition of Windows 2003 that you’re using. For example, if your server runs “Windows 2003 Standard, Volume License Edition, with SP2,” you’ll need the CAB file from that specific CD, and a CAB file from a different edition might not work. It might be difficult to locate the correct CD, particularly if the person who originally installed your server has now left, which is quite likely in a case of an operating system that’s now 10 years old. If this is the case, we wish you good luck in finding your installation CD!

After you’ve installed IIS6, you’ll need to install ASP.NET and the LightSwitch prerequisites. (I’ll explain how to do this very shortly.) Once you’ve installed ASP.NET 4, it’s important to make sure that it’s enabled in the “Web Service Extensions” section of Internet Information Services (IIS) Manager, as shown in Figure 18-15.

Setting Up IIS Application Pools

Application pools improve the reliability of your web server by isolating the applications that run in IIS. If a web site in an application pool crashes, it won’t bring down the other web sites that run in other application pools. It therefore makes good sense to deploy each LightSwitch application into its own separate application pool.

Each application pool also runs under a specific security context, and this enables you to configure your application services to connect to your SQL Server database through Windows Authentication. Figure 18-16 illustrates this concept.

To create a new application pool, open Internet Information Services (IIS) Manager and right-click the Application Pools node on the navigation menu on the left. You’ll find a right-click context menu option that allows you to create a new application pool, as shown in Figure 18-17. It’s important to set up your Application Pool to use version 4 of the .NET Framework.

In IIS7 and above, it is also preferable to choose the Integrated Managed Pipeline Mode, as opposed to Classic Mode. Classic mode is primarily designed for legacy code that might not run properly in integrated mode. Your LightSwitch server runs more efficiently when you set the pipeline mode to integrated.

After you deploy your web site, you can configure it to use the Application Pool that you’ve added by modifying the web-site properties in IIS Manager.

Configuring SQL Server Windows Authentication

Your LightSwitch application services can authenticate onto SQL Server by using two types of authentication: SQL Server authentication or Windows authentication. SQL Server authentication uses SQL Server to store and manage the login and password credentials. If you use SQL Server authentication, you’ll need to hard-code your SQL server login and password in the connection string that LightSwitch uses to connect to your database. Because your login name and password are hard-coded in a plain text file, some IT departments regard SQL Server authentication as less secure than Windows authentication. If you want to read more about the pros and cons of SQL Server authentication vs. Windows authentication, you can find out more in the following TechNet article http://technet.microsoft.com/en-us/library/ms144284.aspx.

To use Windows authentication, you’ll need to first create a Windows domain user. If your IIS server and SQL Server are on the same machine, you might find it easier to create a local Windows user rather than a domain user (particularly if you don’t have sufficient permissions to create new domain users).

Select the application pool that your application uses, and open the “Advanced Settings” dialog. Open the “Application Pool Identity” dialog by clicking the button that you’ll find next to the Process Model Identity text box. When the dialog opens, choose the “custom account” radio button (Figure 18-18), and use the “Set” button to specify the Windows user who you want to use.

The Windows user who you specify needs to have NTFS read permissions on the folders where you’ve installed your LightSwitch application. You should also add the user to the local IIS_IUSRS group in order to grant access to the ASP.NET resources that are needed.

The last step is to make sure that you add a SQL Server login for your Windows user by using SQL Server Management Studio. You’ll also need to grant access permissions to the tables in your application and grant access rights to the tables that the ASP.NET membership provider uses. The quickest way to do this is to add your user into the following database roles:

• aspnet_Membership*
• aspnet_Roles*
• db_datareader
• db_datawriter
• public

Windows authentication should now work, but if it doesn’t, you might need to configure the NTLM provider or carry out some extra steps to configure Kerberos authentication. The following TechNet article will help you if you run into problems: http://technet.microsoft.com/en-us/library/dd759186.aspx.

Configuring Secure Sockets Layer (SSL)

The LightSwitch client communicates with your web server via the HTTP protocol—a clear text protocol. If a hacker monitors your network, they’ll be able to see your LightSwitch data as it passes through the network. This poses a security vulnerability, particularly if your application uses Forms authentication. A hacker can easily discover user-name and password combinations by monitoring the network while users log in. To mitigate this vulnerability, you’d encrypt your data over the network by using the HTTPS protocol.

To set up HTTPS, you’ll need to install an SSL (Secure Sockets Layer) certificate on your web server. This certificate verifies the identity of your server and contains the keys that SSL uses for encryption. You can either purchase a certificate from a third-party company, such as VeriSign, or use an internal certificate server if your company has such infrastructure in place. The Server Certificates option that you’ll find in IIS Manager allows you to request, install, and configure SSL certificates.

An SSL certificate is valid when it meets the following three conditions: the server name on the certificate matches the server on which it’s installed, the certificate is within its validity period, and the certificate is signed by a trusted Certificate Authority. What tends to happen is that administrators allow certificates to expire by not renewing them in sufficient time. It’s important not to let this happen because desktop applications won’t work if your web server’s SSL certificate becomes invalid. The security model in Silverlight prevents LightSwitch applications from connecting to web servers with invalid certificates, and there’s no way that you can circumvent this security feature. Silverlight browser and HTML client applications will still work, but the browser warns the user that they “might be visiting a dangerous website.” This doesn’t look very professional, so it’s good practice to make sure that your SSL certificates don’t lapse.

If your application stores sensitive data, you might want to enforce encryption on all network traffic that takes place between your client and the server. This is particularly useful on LightSwitch applications that you expose over the public Internet. You can mandate SSL for all traffic by modifying your web.config file as shown in Listing 18-1. When you deploy your application, you’ll find this file in the root folder of your ASP.NET application.

Listing 18-1.  Web.config Setting to Mandate SSL

<configuration>
  <appSettings>
    <!-- A value of true will indicate http requests should be
         re-directed to https -->
    <add key="Microsoft.LightSwitch.RequireEncryption" value="true" />

Using the Microsoft Web Deploy Tool

If you want to directly publish a LightSwitch application from Visual Studio, or install the packages that the Publish Wizard generates, you’ll need to install the Microsoft Web Deploy Tool. You can use Web PI to install this utility, or you can download it directly from the Microsoft IIS web site (http://www.iis.net/download/WebDeploy).

The Web Deploy Tool installs a Web Deployment Agent Service. For publishing to work, it’s important to ensure that this service is started (shown in Figure 18-20). Although the installer sets the startup type of this service to Automatic, you should manually check that the service is started if you experience problems publishing your application.

Installing Your SQL Database

The output from the Publish Wizard produces a SQL script called <YourApplication>.sql (where <YourApplication> is the name of your LightSwitch application). This script creates the database, tables, stored procedures, and other database objects that support your application. You’ll need to execute this script on your database server, either by using the sqlcmd command-line tool or SQL Server Management Studio.

If you’ve installed a basic instance of SQL Server Express without the Management Tools, sqlcmd is the method that you would use. The default location of this utility on a 64-bit machine is

Program Files(x86)Microsoft SQL Server100ToolsBinn

To use sqlcmd, open an elevated command prompt, navigate to the directory where it’s installed, and run the following command:

sqlcmd.exe -i Helpdesk.sql -S .SQLExpress

You’ll need to replace the arguments that you supply to sqlcmd.exe as follows:

• -i Helpdesk.sql: This specifies the SQL file that you want to execute. Replace this with the name of the SQL file in your publish folder.
• -S .SQLExpress: This specifies the name of your database server and SQL Server instance.
• -U <username> -P <password>: If you don’t specify the –U and –P switches, sqlcmd connects to your SQL Server instance using Windows authentication. These switches allow you to supply a user name and password if you want to use SQL authentication instead.

If you choose to install the SQL Script by using SQL Server Management Studio, make sure to place your query window into SQLCMD Mode by using the option that you’ll find under the Query menu. Your script won’t run correctly if you don’t do this.

Setting the Database Connection String

If you specify a correct and valid connection string in the Publish Wizard, you can skip this step. But if not, you’ll need to modify your application’s connection string so that it points to the database that you’ve installed. The publish output contains an “Application Files” subdirectory that includes a file called web.config. Open this file in Notepad, and edit the connection string value in the <connectionStrings> section like so:

<add name="_IntrinsicData" connectionString="Data Source=SERVERNAMESQLEXPRESS;
   Initial Catalog=HelpDeskDB;Integrated Security=True;Pooling=True;
   Connect Timeout=30;User Instance=False" />

Replace SERVERNAMESQLEXPRESS with the name of your database server and instance, and replace HelpDeskDB with the name of your database. If you’ve defined additional data sources in your application, you’ll find the connection strings in the same section of the web.config file, and you can modify them as appropriate.

If you’ve enabled authentication in your application, you will have defined your application’s administrator in the Publish Wizard. You’ll find the settings that relate to your application’s administrator in the web.config file, and you can also modify the values manually if needed.

Once you configure these data tasks, you’ll be able to successfully run setup.exe on your client workstation. This creates a shortcut on the desktop, and the user can use this to start your application.