Note: This information has been updated since original posting and now applies to Visual Studio LightSwitch 2011 RTM. For information on deployment enhancements with LightSwitch in Visual Studio 2012 (LightSwitch V2) please see LightSwitch IIS Deployment Enhancements in Visual Studio 2012.
Visual Studio LightSwitch applications are logically three-tier applications and consist of a client, application services (a.k.a. middle-tier), and data store (a.k.a database). LightSwitch applications can be deployed to a variety of environments in a couple different ways. You can deploy the client as a Desktop application or a Web (browser-based) application. A Desktop application runs outside the browser on a Windows machine and has access to the computer storage and other running applications. Users see a desktop icon to launch the application like any other Windows application. A Web application runs inside the browser and does not have full access to storage or other applications on the machine, however, a Web application can support multiple browsers and run on Mac as well as Windows computers.
If you select a desktop application you can choose to host the application services locally on the same machine. This creates a two-tier application where all the components (client + middle-tier) are installed on the user’s Windows computer and they connect directly to the database. This type of deployment avoids the need for a web server and is appropriate for smaller deployments on a local area network (LAN) or Workgroup. In this situation, the database can be hosted on one of the clients as long as they can all connect directly.
Both desktop and browser-based clients can be deployed to your own (or web hoster’s) Internet Information Server (IIS) or hosted in Azure. This sets up a three-tier application where all that is installed on the client is a very small Silverlight runtime and the application services (middle-tier) are hosted on a web server. This is appropriate if you have many users and need more scalability and/or you need to support Web browser-based clients over the internet.
(click images to enlarge)
If you don’t have your own web server or IT department then deploying to Azure is an attractive option. Check out the pricing options here as well as the Free Azure Trial. Last week Andy posted on the team blog how to publish your LightSwitch application to Azure, if you missed it see:
In this post I’m going to show you how you can set up your own server to host the application as well as some configuration tips and tricks. First I’ll walk through details of configuring a web server for automatic deployment directly from the LightSwitch development environment and then move onto the actual publishing of the application. I’ll also show you how to create install packages for manual deployment later, like to an external web hoster. We’ll also cover Windows and Forms authentication. Finally I’ll leave you with some tips and tricks on setting up your own application pools, integrated security and SSL that could apply to not only LightSwitch applications, but any web site or service that connects to a database. Here’s what we’ll walk through:
Configuring a server for deployment
- Installing Prerequisites with Web Platform Installer
- Verifying IIS Settings, Features and Services
- Configuring Your Web Site and Database for Network Access
Deploying your LightSwitch application
- Direct Publishing a LightSwitch Application
- Creating and Installing a LightSwitch Application Package
- Deploying Applications that use Forms Authentication
- Deploying Applications that use Windows Authentication
Configuration tips & tricks
- Configuring Application Pools & Security Considerations
- Using Windows Integrated Security from the Web Application to the Database
- Using Secure Sockets Layer (SSL) for LightSwitch Applications
Keep in mind that once you set up the server then you can deploy multiple applications to if from LightSwitch. And if you don’t have a machine or the expertise to set this up yourself, then I’d suggest either a two-tier deployment for small applications, or looking at Azure as I referenced above. This guide is meant for developers and IT Pros that want to host LightSwitch web applications on premises.
So let’s get started!
Installing Prerequisites with Web Platform Installer
You can use the Web Platform Installer (WPI) to set up a Windows web server fast. It allows you to select IIS, the .NET Framework 4 and a whole bunch of other free applications and components. All the LightSwitch prerequisites are there which includes setting up IIS and the web deploy service properly as well as including SQL Server Express. This makes it super easy to set up a machine with all the stuff you need. Although you can do this all manually, I highly recommend you set up your LightSwitch server this way. You can run the Web Platform Installer on Windows Server 2008 (& R2), Windows 7, and Windows Server 2003. Both IIS 7.0 and IIS 6.0 are supported. If the server already has IIS 6.0 installed, IIS 7.0 will not be installed.
To get started, select the Products link at the top then select Tools on the left. There you will see two options for LightSwitch Server Runtime. One option is to install SQL Server Express and the other is without. If you already have an edition of SQL Server installed on the machine or if you are hosting the database on another machine you can choose the “without Local SQL” option. Click the Add button for the one you want. For this setup I will be hosting the database on the same machine to I’ll choose the first option. This will install IIS, .NET Framework 4, and SQL Server Express 2008 R2 for you so you DO NOT need to select these components again.
UPDATE for VS2012 & 2013: If you are using Visual Studio 2012 or 2013, select the correct version that applies to your version of LightSwitch.
If you already have one or more of these components installed then the installer will skip those. LightSwitch server prerequisites do not install any assemblies; they just make sure that the server is ready for deployment of LightSwitch applications so you have a smooth deployment experience for your LightSwitch applications. Here’s the breakdown of the important dependencies that get installed:
- IIS 7 with the correct features turned on like ASP.NET, Windows Authentication, Management Services
- .NET Framework 4 + SP1
- Web Deployment Tool and the msdeploy provider so you can deploy directly from the LightSwitch development environment to the server
- If you selected to install the Local SQL above then SQL Server Express (engine & dependencies) are installed
The prerequisites are also used as a special LightSwitch-specific customization step for your deployed web applications. When deploying to IIS 7, they will:
- Make sure your application is in the ASP.NET v4.0 Application Pool
- Make sure matching authentication type has been set for the web application
- Adds an application administrator when your application requires one
So by installing these you don’t have to worry about any manual configuration of the websites after you deploy them. Please note, however, that if you already have .NET Framework 4 on the machine and then install IIS afterwards (even via WPI) then ASP.NET may not get configured properly. Make sure you verify your IIS settings as described below.
To begin, click the “I Accept” button at the bottom of the screen and then you’ll be prompted to create a SQL Server Express administrator password. Next the installer will download all the features and start installing them. Once the .NET Framework is installed you’ll need to reboot the machine and then the installation will resume.
Plan on about 20-30 minutes to get everything downloaded and installed.
Verifying IIS Settings, Features and Services
Once IIS is installed you’ll need to make sure some features are enabled to support LightSwitch (or any .NET web application). If you installed the Visual Studio LightSwitch 2011 Server Runtime on a clean machine then these features should already be enabled.
In Windows 2008 you can check these settings by going to Administrative Tools –> Server Manager and under Roles Summary click on Web Server (IIS). Then scroll down to the Role Services. (In Windows 7 you can see this information by opening “Add or Remove Programs” and selecting “Turn Windows features on or off”.) You will need to make sure to install IIS Management Service, Application Development: ASP.NET (this will automatically add additional services when you check it), and under Security: Windows Authentication.
Next we need to verify the Web Deployment Agent Service is started. Open up Services and right-click on Web Deployment Agent Service and select Start if it’s not already started.
Configure Your Web Site and Database for Network Access
Now before moving on we should make sure we can browse to the default site. First, on the web server, you should be able to open a browser to http://localhost and see the IIS 7 logo. If that doesn’t happen something got hosed in your install and you should troubleshoot that in the IIS forums or the LightSwitch forums. Next we should test that other computers can access the default site. In order for other computers on the network to access IIS you will need to enable “World Wide Services (HTTP Traffic-In)” under Inbound Rules in your Windows Firewall. This should automatically be set up when you add the Web Server role to your machine (which happens when you install the prerequisites above).
At this point you should be able to navigate to http://<servername> from another computer on your network and see the IIS 7 logo. (Note: If you still can’t get it to work, try using the machine’s IP address instead of the name)
Next you need to make sure the SQL Server that you want to deploy the LightSwitch application database (which stores your application data, user names, permissions and roles) is available on the network. In this example I’m going to deploy the database to the same machine as the web server but you could definitely put the database on its own machine running either SQL Server or Express depending on your scalability needs. For smaller, internal, or departmental applications running the database on the same machine is probably just fine. SQL Express 2008 R2 is installed as part of the prerequisites above, you just need to enable a few things so that you can connect to it from another machine on your network.
Open up SQL Server Configuration Manager and expand the SQL Server Services and start the SQL Server Browser. You may need to right-click and select Properties to set the start mode to something other than Disabled. The SQL Server Browser makes the database instance discoverable on the machine. This allows you to connect via <servername>/<instancename> syntax to SQL Server across a network. This is going to allow us to publish the database directly from LightSwitch as well.
Next you need to enable the communication protocols so expand the node to expose the Protocols for SQLEXPRESS as well as the Client Protocols and make sure Named Pipes is enabled. Finally, restart the SQLEXPRESS service.
Direct Publishing a LightSwitch Application
Here is the official documentation on how to publish a LightSwitch application – How to: Deploy a 3-tier LightSwitch Application. As I mentioned, there’s a couple ways you can deploy to the server, one way is directly from the LightSwitch development environment, but the other way is by creating an application package and manually installing it on the server. I’ll show you both.
Now that we have the server set up, the Web Deployment Agent service running, and remote access to SQL Server, we can publish our application directly from the LightSwitch development environment. For this first example, I’m going to show how to deploy an application that does not have any role-based security set up. We’ll get to that in a bit. So back on your LightSwitch development machine, right-click on the project in the Solution Explorer and select “Publish”.
The Publish Wizard opens and the first question is what type of client application you want, desktop or Web (browser-based). I’ll select desktop for this example.
Next we decide where and how we want to deploy the application services (middle-tier). I want to host this on the server we just set up so select “IIS Server” option. For this first example, I will also choose to deploy the application directly to the server and since I installed the prerequisites already, I’ll leave the box checked “IIS Server has the LightSwitch Deployment Prerequisites installed”.
Next we need to specify the server details. Enter the URL to the web server and specify the Site/Application to use. By default, this will be set to the Default Web Site/AppName. Unless you have set up another website besides the default one leave this field alone. Finally, specify an administrator username and password that has access to the the server.
Next you need to specify a couple connection strings for the application database. The first one is the connection that the deployment wizard will use to create or update the database. This refers specifically to the intrinsic application database that is maintained by every LightSwitch application and exists regardless of whether you create new tables or attach to an existing database for your data. Make sure you enter the correct server and instance name in the connection string, in my case it’s called LSSERVER\SQLEXPRESS. Leaving the rest as integrated security is fine because I am an administrator of the database and it will use my windows credentials to connect to the database to install it. Regardless of what connection string you specify, the user must have dbcreator rights in SQL Server.
The second connection string will be the connection string the application uses at runtime. The middle-tier components connect to the database with this connection string and it is stored in the Web.config file. LightSwitch warns us here that this should not be using integrated security. This is because the web application is going to be set up in the ASP.NET v4.0 Application Pool which runs under a built-in identity that does not have access to the database. I’ll show you later how we can set up our own application pools, for now click the “Create Database Login…” button to create a login for the application. This will set up a least-privileged account with access to just the database and roles it needs.
Here I’ll specify the login name and password for this application.
Next you specify a certificate to use to sign the client application (.XAP file). This should be a valid certificate from a trusted Certificate Authority like VeriSign or if this is an internal application then you probably have certificates you use for enterprise deployment. If you don’t sign the application then users will see a warning message when installing the desktop application and they will not be able to get automatic updates if you update the application.
Click Next one last time and you will see a summary of all the setting we specified. If you run the publish wizard again, you will be taken to this page automatically and all the settings will be remembered.
Click Publish and it will take a few minutes to get everything installed on your remote server. You can see the status of the deployment by looking in the lower left hand side of Visual Studio LightSwitch. Once the publishing is done, open up your browser to http://<servername>/<applicationname> and in the case of a desktop application you will see an Install button. Click that to install and launch the desktop application.
Users of desktop applications will see an icon on their Windows desktop as well as the Start Menu to re-launch the application. And users can uninstall the application normally through Add or Remove Programs.
Creating and Installing a LightSwitch Application Package
Sometimes you don’t have direct access to the server where you want to host your LightSwitch application so direct deployment isn’t an option. In this case, you’ll need to create a package on disk which you can hand to an administrator to install manually. So back on your LightSwitch development machine, right-click on the project in the Solution Explorer and select “Publish” and click on the first page, Client Configuration. You can select Desktop or Web – I did Desktop before so this time I’ll select Web.
Again I’ll select IIS server that has our prerequisites installed.
Now on the publish output, this time select “Create a package on disk” and then enter a website name and specify a location to where you want the package created.
On the next page you specify the Database Configuration details. You can either create a new database or specify a database that needs to be updated. This refers specifically to the intrinsic application database that is maintained by every LightSwitch application and exists regardless of whether you create new tables or attach to an existing database for your data. For the first deployment of the application you are always going to want to select the New Database option as you won’t have one created yet. If you are publishing an update to an existing application then you would select Update Existing option.
Just like in the case of direct deployment, you can specify a certificate to use to sign the client application (.XAP file). For a web application, this isn’t necessary.
Click Next and you will see a summary of all the setting we specified. Next click Publish and this will create a .ZIP file package in the publish location you specified. Copy that application package over to your web server then open up IIS Manager on the server and right-click on the Default Web Site and select Deploy –> Import Application. Note that you will need to be an administrator of the machine in order to install the package properly.
Browse to the .ZIP application package that we created then click Next. The contents of the package will then be displayed.
Similar to a direct deployment, when you install the package it’s going to ask for some database details. The first connection string will be used to create or update the database. Make sure you enter the correct server and instance name in the connection string, in my case it’s called LSSERVER\SQLEXPRESS. Using integrated security here is fine because I am an administrator of the database and it will use my windows credentials to connect to the database to install (or update) it.
The next four fields are used to create the connection string the application uses at runtime. The middle-tier components connect to the database this way and this information is stored in the Web.config file. By default you cannot specify an integrated security account because the web application is going to be set up in the ASP.NET v4.0 Application Pool which runs under a built-in identity and this identity does not have access to the database. (I’ll show you how to set up your own application pool using integrated security at the end.) Make sure you specify a least-privileged account with access to just the database it needs.
Click Next and this will kick off the installation that should be pretty quick. Once it completes, navigate your favorite browser to the website. Since I chose to deploy this as a Web application this time, the LightSwitch application will open like any other web site right inside the browser.
Deploying Applications that use Forms Authentication
Access control (checking user permissions) is a big feature in LightSwitch and there are hooks built in all over screens, queries and entities that allow you to easily check permissions you define. Here’s the library documentation to check out:
and I also recommend this video:
You specify user permissions and the type of authentication you want to use on the Access Control tab of the Project –> Properties.
Here you define user permissions that you check in code in order to access resources (for details on how to do that see the video and article referenced above). You also specify what kind of Authentication you want to use which affects how to application is deployed. The web application on the server must have the corresponding IIS authentication enabled.
First let’s walk through Forms authentication. This means you will be storing usernames and passwords inside the LightSwitch database (LightSwitch uses the ASP.NET membership provider model). This type of authentication is appropriate for internet-based applications. Once you go to publish your application that uses Forms Authentication, there will be a new section in the Publish Wizard that allows you to specify how the administrator is deployed.
Direct Deployment – Forms Authentication
In the case of direct deployment you will see a screen that asks for the Administrator user name and password. This has nothing to do with the connection to the database so don’t get confused. This is just the first user that gets deployed as actual data into the users table so you can log into the application and start setting up other users and roles. If you are re-deploying (i.e. updating) an application that was already deployed with Forms Authentication then choose not to create the application admin again.
Creating an Application Package – Forms Authentication
If you are creating a package on disk, then the Publish Wizard will only ask you whether you want to create the Application Administrator or not. If this is the first time deploying, select yes, otherwise if you’ve already gone through this once select no. You will be asked to specify the details later when you deploy the package on the server.
So now when you import the application package you will see additional fields that you need to enter that set up this Application Administrator. (Remember that to install the package on the server in the first place you have to be an administrator of the machine, but these fields just specify what data gets deployed in the application’s users table).
After you publish the application, whether you do it directly or create a package, if you’ve installed the LightSwitch prerequisites you will see that the corresponding Forms Authentication is set up properly on your web site. This is required in order for the application to work properly.
Deploying Applications that use Windows Authentication
Using Windows Authentication is appropriate if all your users are on the same network or domain, like in the case of an internal intranet-based line-of-business application. This means that no passwords are stored by your LightSwitch application. Instead the Windows logon credentials are used and passed to the application server. In this case you can also choose whether you want to set up specific users and roles or whether any authenticated user has access to the application.
Note that If you have permissions defined in your application and you are checking them in code, then those permissions will only be granted to users specified in the Users screen of the application. The “Allow any Windows authenticated user” setting will work, but users who are not also defined in the Users screen will not have any of the defined permissions. The best way to think of the two options for Windows authentication are:
- Give special permissions and roles to the Windows users that I administer within the application. (This is always on if you have selected Windows authentication)
- ALSO, let any Windows user access the unprotected parts of my application
In either case, the deployment and web application configuration is the same.
Direct Deployment – Windows Authentication
In the case of direct deployment you will see a screen that asks for the Application Administrator user. This should be a valid user on the domain where the application is hosted. Again, this is just the first user that gets deployed into the users table so they can open the application and start setting up other users and roles. If you are re-deploying (i.e. updating) an application that was already deployed with Windows Authentication then choose not to create the application admin again.
Creating an Application Package – Windows Authentication
If you are creating a package on disk, just like Forms Authentication above, the Publish Wizard will only ask you whether you want to create the Application Administrator or not. If this is the first time deploying, select yes, otherwise if you’ve already gone through this once select no. Again, you will be asked to specify the details when you deploy the package on the server. Here is where you will specify the application Admin user as a valid domain user.
After you publish the application, whether you do it directly or create a package, if you’ve installed the LightSwitch prerequisites you will see that the corresponding Windows Authentication is set up properly on your web site. This is required in order for the application to work properly.
And when you run the application you will see the authenticated user in the right-hand corner.
That’s it! We are now armed with the knowledge of how to deploy any type of LightSwitch application to a server. :-)
Configuring Application Pools & Security Considerations
Now that we know how to deploy LightSwitch Desktop and Web applications, next I want to talk a little bit about how application pools and Windows identities work. This will help you determine what is the best way for you to host any web application on a network. You don’t actually have to know much about this stuff when deploying a LightSwitch application because the installation package will set up all of this for you. However, I think it’s always a good thing to understand what’s going on, especially if you are trying to troubleshoot issues. If you don’t care, you can skip this section :-)
When you create a new website in IIS Manager you choose which application pool it should run under. When deploying applications with LightSwitch your applications are deployed to the ASP.NET v4.0 app pool. Application pools give you isolation between worker processes (so if one web application crashes it can’t take others with it) but they also allow you to run under different identities. The built-in application pools use built-in accounts that they run under.
If you create your own application pool you can set it to run under a specific Windows Identity and you can allow access only to the resources that identity needs to run the application. In the case of a LightSwitch application, that additional resource will be the database. If you are already on a Windows domain it’s best to create a least-privilege domain user, set that user as the identity of the application pool, and grant access for that user to the database (which is probably on another machine, if so you’ll probably want to read this).
Since I am hosting the database on the same machine as IIS I can use a local machine account. Open up the Local Users and Groups console and create a local user called LightSwitchApp. Then add this user to the IIS_IUSRS group so that it has read access to web application files on disk under the wwwroot. Next open up IIS Manager, right-click on Application Pools and select “Add Application Pool….” Type a name for your App Pool, I called mine LightSwitchAppPool and select the .NET Framework version 4. Then click OK.
Next right-click on the LightSwitchAppPool and select Advanced Settings and change the Identity to the account you just created. (Once we update our LightSwitch web application to run in this pool, it will run under this identity to access resources.)
Now we can set the Application Pool of the LightSwitch application we deployed earlier. In IIS Manager right-click on the Web application and select Manage Application – Advanced Settings. Here you can change the application pool to the one we just created.
Note that if your web application files are physically deployed to somewhere other than under inetpub\wwwroot then you will also need to add read file access permissions to that directory for the LightSwitchApp user account. Because we used LightSwitch earlier to deploy our application, our application is located under C:\inetpub\wwwroot\OrderManagement.
There’s one last piece to set up if your application is going to use Windows Authentication. When you use a custom user identity as the application pool identity in this situation you need to either use the NTLM provider (not Kerberos) or you need to Enable support for Kerberos authentication. Another option is to use the Network Service identity as the app pool’s identity and add that account access to the database instead. To use the NTLM provider (which is what I’m going to do) select the web site and select Authentication under the IIS section on the main window of the IIS manager. Select the Windows Authentication (which is enabled), right-click and select “Providers…” and then move Negotiate down to the bottom of the list.
Using Windows Integrated Security from the Web Application to the Database
Like I mentioned earlier, typically you want to set up Windows Integrated security between your web application and database. It’s a lot easier this way because you don’t have to worry about managing user names and passwords in your application connection strings. It also is a lot more secure — right now our username and password to the database is being stored in clear text on the web application’s Web.config. Only administrators of the server can see this file, however, you may not trust other people that have access to the machine. Let’s face it, you’re paranoid. ;-)
We’ve configured our LightSwitchAppPool to run under the LightSwitchApp user identity so the next step is to grant this user access to the database. You can do this through SQL Server Management Studio which you can also install via the Web Platform Installer. Open up SQL Server Management Studio and right-click on the Security node and choose New Login. On the General tab specify the local LightSwitchApp user account as the Login name, use Windows Authentication. On the User Mapping make sure you check off the database you want to grant access to, in my case OrderManagement. At minimum you will need to enable the following roles: aspnet_Membership*, aspnet_Roles*, db_datareader, db_datawriter, and public. Or you can grant the db_owner role which will include these.
Because we’ve configured our LightSwitchAppPool to run under the LightSwitchApp user identity we can now change the connection string in the Web.config to use integrated security and the middle-tier will connect to the database under this windows account instead. In IIS Manager right-click on the web application and select Explore to navigate to the physical folder. Open the Web.config in notepad and remove the uid and password and add Integrated Security=SSPI:
<?xml version=”1.0″ encoding=”utf-8″?>
<appSettings> … </appSettings>
<add name=”_IntrinsicData” connectionString=”Data Source=.\SQLEXPRESS;Database=OrderManagement;Integrated Security=SSPI;Pooling=True;Connect Timeout=30;User Instance=False” />
Save the file and now run your client application again and everything should be working, running under your own Application Pool and using Windows Integrated security to the database. As a tip, if you have trouble connecting to your database, double-check the connection string and also make sure the database user is a db_owner for the correct database.
Using Secure Sockets Layer (SSL) for LightSwitch Applications
To wrap up this post I’m going to leave you with some notes and recommendations on using Secure Sockets Layer with LightSwitch applications. As you’ve probably noticed by now, LightSwitch clients communicate with the server via HTTP which is the protocol used between web browsers and web servers. HTTP specifies that data be sent in clear-text, which means that a network eavesdropper could monitor the data exchanged between clients and servers. In any web application, including LightSwitch applications, if you want communications to be secure you need to use the HTTPS protocol. This hides the normal HTTP data in an encrypted tunnel called a Secure Sockets Layer (SSL).
In order to configure your web server to enable HTTPS, you use a certificate and set it up like any other secure web site. No LightSwitch-specific configuration is required on the IIS server in order to host LightSwitch applications with SSL. For information on setting up SSL see: How to Set Up SSL on IIS
When you enable SSL this protects not only the sensitive business data that is exchanged between client and server, but also the usernames and passwords when you are using Forms Authentication. It is a best practice to use HTTPS when using Forms authentication in conjunction with an IIS server exposed to the internet or when hosting in Azure. Otherwise, it is possible for an attacker to recover passwords and impersonate users. When using Windows authentication, an attacker cannot recover user passwords or impersonate users regardless of the protocol. However, business data transferred between client and server will still be subject to eavesdropping unless HTTPS is employed. (Note that HTTPS is not necessary when deploying a two-tier application because the client-server communication does not happen over the network – all LightSwitch assemblies are deployed locally on the same machine in this case.)
There may be situations where you want to host the same LightSwitch application using both HTTP and HTTPS, like if you have both internal (behind firewall) and external (internet) clients. By default in recent versions of IIS, the Default Web Site listens for both HTTP and HTTPS connections. You can also choose to force a LightSwitch application to require HTTPS and redirect any HTTP incoming connections to the HTTPS endpoint by modifying the Web.config of your LightSwitch application.
In the <appSettings> section of Web.config, you should see:
<!– A value of true will indicate http requests should be re-directed to https –>
<add key=”Microsoft.LightSwitch.RequireEncryption” value=”false” />
Set the value from “false” to “true”. You can configure this in Web.config after deploying, or from inside LightSwitch before deploying. To find your Web.config during development, in Solution Explorer switch to File View then enable Show All Files. It will be located in the Server Generated project.
Web servers that communicate via HTTPS rely on having a server certificate installed which does a couple things for you. The certificate verifies the identity of the server and also contains the secret key information used to encrypt any data sent to the client. For a web browser to be able to trust the identity of a server, the server’s certificate must be signed by a trusted Certificate Authority (CA) like VeriSign. Note that most CAs charge for this service and so it’s common during development for a server to use a test certificate which is a self-generated, unsigned — and thus untrusted — certificate.
If you connect to a LightSwitch web application via HTTPS and the server is using an untrusted certificate, the behavior depends on your web browser. At minimum your browser will tell you that there’s a certificate problem and ask if you’d like to proceed. This is what will happen if you have deployed a LightSwitch Web application. However, if you have a LightSwitch Desktop application and you want to use it over HTTPS, then your IIS server must be using a trusted certificate. This is because Silverlight, and thus LightSwitch, will not allow desktop applications to come from untrusted server certificates.
To fix this, you can either force your web browser to trust the server’s certificate by pre-installing it in the client’s certificate store, or you can replace the server’s certificate with one which has been signed by a trusted CA. Note that you should perform either of these steps before accessing the application for the first time from a client, otherwise it will appear to that client that the certificate has changed or been tampered with. If you’ve accidentally done just that then you will need to uninstall (via Add or Remove Programs) and then reinstall the client application.
So I think that about covers it. Deployment of web applications can be tricky no matter what the technology, but LightSwitch makes this a lot easier on you especially when you use the WPI and install the LightSwitch Server prerequisites. And you have a couple good options for deployment. You can either set up a web server for direct deployment by giving LightSwitch developers admin access to it (which is especially handy for testing and staging) or you can have them create packages that an administrator can easily install later. Now you should be a pro at 3-tier LightSwitch application deployment and all your applications should be running smooth. :-)
BTW, I’m working on some How Do I videos on 3-tier and Azure deployment so stay tuned.
UPDATE 8/9/2011: Here are the videos:
- How Do I: Deploy a Visual Studio LightSwitch Application?
- How Do I: Deploy a LightSwitch Application to Azure?
UPDATE 9/20/2011: For more troubleshooting tips see: Diagnosing Problems in a Deployed 3-Tier LightSwitch Application
UPDATE 3/23/2012: For info on how to deploy to IIS6 as well as automating installs of deployment packages see: Deploying LightSwitch Applications to IIS6 & Automating Deployment Packages