Wow Your End Users

Visual Studio LightSwitch Technical White Paper

Author: Andrew Brust, Blue Badge Insights

Published: August, 2011

Applies to: Visual Studio LightSwitch 2011

Summary: This is the fourth in a series of white papers about Microsoft® Visual Studio® LightSwitch™

2011, Microsoft’s new streamlined development environment for designing data-centric business

applications. We’ll explore the finer points of LightSwitch user interface design, including menus and

navigation, screen templates, search, export, and application deployment.

2

Copyright

The information contained in this document represents the current view of Microsoft Corporation

on the issues discussed as of the date of publication. Because Microsoft must respond to

changing market conditions, it should not be interpreted to be a commitment on the part of

Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the

date of publication.

This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,

EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the

rights under copyright, no part of this document may be reproduced, stored in, or introduced into

a retrieval system, or transmitted in any form or by any means (electronic, mechanical,

photocopying, recording, or otherwise), or for any purpose, without the express written

permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual

property rights covering subject matter in this document. Except as expressly provided in any

written license agreement from Microsoft, the furnishing of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-

mail addresses, logos, people, places, and events depicted herein are fictitious, and no

association with any real company, organization, product, domain name, e-mail address, logo,

person, place, or event is intended or should be inferred.

© 2011 Microsoft Corporation. All rights reserved.

Microsoft, Microsoft® LightSwitch® 2011, Microsoft® Excel, Microsoft® SQL Server®, Visual

FoxPro®, Visual Basic®, Microsoft® Windows® Azure™, are trademarks of the Microsoft group

of companies.

All other trademarks are property of their respective owners.

3

White Papers in this Series

1. What is LightSwitch?

2. Quickly Build Business Apps

3. Get More from Your Data

4. Wow Your End Users

5. Make Your Apps Do More with Less Work

4

Contents

Introduction .................................................................................................................................................. 6

Menu and Navigation.................................................................................................................................... 6

Screen Templates .......................................................................................................................................... 8

The New Data Screen Template................................................................................................................ 9

Some Property Settings ...................................................................................................................... 10

The Search Data Template ...................................................................................................................... 13

Making Queries and Fields Searchable ....................................................................................................... 14

Export to Excel ............................................................................................................................................ 15

Designing Screens ....................................................................................................................................... 15

Working with Generated Screens ........................................................................................................... 16

Building Your Own Screens ..................................................................................................................... 17

Designing Screens from the Members List ......................................................................................... 18

Using the “Add” Node ......................................................................................................................... 18

Adding Unbound Groups .................................................................................................................... 20

Modifying Layout and Control Types .................................................................................................. 22

Layout Types ....................................................................................................................................... 24

Composite Controls ............................................................................................................................. 25

Deployment ................................................................................................................................................ 26

Client Application Type ........................................................................................................................... 27

Application Server ................................................................................................................................... 27

On-Premise or Cloud ........................................................................................................................... 27

Configuring Your Deployment ................................................................................................................ 27

Further Requirements ............................................................................................................................. 28

Set Configuration to Release............................................................................................................... 28

Security Certificates ............................................................................................................................ 29

Server Prerequisites ............................................................................................................................ 29

Azure-Specific Requirements .............................................................................................................. 29

Conclusion ................................................................................................................................................... 30

LightSwitch Screen Design Nitty-Gritty ....................................................................................................... 31

Element Types ......................................................................................................................................... 31

5

Command Bars ........................................................................................................................................ 32

Common Properties .................................................................................................................................... 32

Sizing and Appearance Properties .......................................................................................................... 32

Row and Column Properties ................................................................................................................... 34

Group Properties..................................................................................................................................... 35

6

Introduction This is the fourth in a series of white papers about Microsoft® Visual Studio® LightSwitch™ 2011,

Microsoft’s new streamlined development environment for designing data-centric business applications.

We’ll explore the finer points of LightSwitch user interface design, including menus and navigation,

screen templates, search, export, application deployment.

In the first paper, we provided an overview of the product and an analysis of the market need it meets.

In paper #2, we provided and discussed the steps involved in the development of a sample LightSwitch

application. In paper #3, we discussed LightSwitch’s data capabilities more deeply. In this paper, we’ll

explore the finer points of LightSwitch user interface design, including:

menus and navigation

screen templates

search

export to Microsoft® Excel®

screen design, layout concepts and the visual tree

application deployment (including cloud deployment to Windows® Azure™ and SQL Azure)

We’ll discuss each of these features in turn, as understanding how to work with them will truly round-

out your LightSwitch knowledge. Not only will you understand how to be productive in LightSwitch

quickly but you’ll have real expertise in working with data and screens. The means you’ll be ready to

build applications that cater to most mainstream business application requirements and you will be

ready to put those applications in users’ hands. You will also be ready to take full advantage of the

review of LightSwitch extensions in the next (and last) paper in this series.

While screens provide the bricks of an application, the menu and navigation techniques are the mortar.

So let’s start with a deeper look at menu design and capabilities than we’ve had thus far, and then move

on to screens and deployment.

Menu and Navigation Screens aren’t all that make a user-friendly application. Menus and navigation are important as well. To

get ready to discuss this topic in full, let’s review what we’ve learned so far about LightSwitch

application menus. This is what we’ve seen, but haven’t called out explicitly:

1. Links are added to the menu under the Tasks group header as screens are created, and are

ordered based on when they were added to the project. The text of each link is based on the

name of the screen.

2. The first screen added to the menu becomes the application’s startup screen (displayed

automatically when the application starts).

3. No links are created for parameterized detail screens, which must be called from code or from

summary field data displayed as links.

7

4. A special Administration group is added to the menu if authentication is enabled, and is visible

to users granted the SecurityAdministration permission.

All of our examples so far have resulted in menus being generated, but we’ve been going about menu

design a bit passively. We can exert much more control over the composition and behavior of our

menus, with very little incremental effort. Command central for crafting menus more explicitly is the

Screen Navigation tab of the project properties. Here are some other things we can do there:

1. Rename (change the text of), reorder, or delete any link or group.

2. Add links and groups manually.

3. Control access to any link through its CanRun event handler1.

4. Set any link to be the application’s startup screen.

If you double-click the Properties link in Solution Explorer (or select the Project/projectname

Properties… menu option) and then click the Screen Navigation tab, the Screen Navigation property

sheet displays as shown in Figure 1.

Figure 1 - The Screen Navigation property sheet

1 Any link for which a user is denied access is not visible on the menu for that user. If the user is denied access to

all links in a group, then the group header is not visible either.

8

Notice the following highlighted, numbered elements:

1. Screen Navigation tab

2. reorder buttons

3. links’ context menu

4. Include Screen option

5. Add Group option

6. startup screen controls

As you can see, screen navigation in LightSwitch is quite flexible. However, the menu is not the sole

means of navigation. You can also add a custom button to a screen and configure it to load any other

screen in the application. You just need a single line of code in the button’s Execute event handler to

make this work.

For each screen in the application, LightSwitch creates a method on the Application object to load the

screen. The name of the method is formed from the word “Show” and the name of the screen. If the

screen is parameterized, then the method is as well, and you can pass a specific value to load the

appropriate data. For example, if we add a button to our EditableExpensesGrid screen to view

BudgetCategory detail data corresponding to the selected Expense record. That code is shown in Listing

1.

Listing 1 - Loading a parameterized screen programmatically

partial void ViewCatgeory_Execute() { Application.ShowBudgetCategoryDetail(Expenses.SelectedItem.BudgetCategory.Id); }

Another navigation technique is to render data in List and Data Grid controls as links using a Summary

control. When a user clicks these links, detail data screens are displayed automatically. Data for

relationship fields can be rendered as links using the Summary control’s Show as Link option in the

Properties window. Checking the Show at Link property enables the Target Screen drop-down list

property. The latter is automatically set to Default, but the drop-down list contains all related detail

screens. When the Default setting is used, LightSwitch generates an edit screen for your data on-the-fly,

unless a user screen is designated as the default details screen for that entity. In the latter case, the

default screen for the entity is shown instead.

Screen Templates We’ve now discussed how to move between screens, so it’s time to focus on screen design, specifically

on the different built-in types of screens LightSwitch offers. So far, we’ve looked at three of

LightSwitch’s built-in screen templates:

Editable Grid

9

List and Details

Details

Let’s now look at the two remaining templates – New Data and Search Data – and in the process we’ll

also gain a deeper appreciation of what a screen template actually is.

The New Data Screen Template The New Data screen template is similar to the Details screen template, with a couple of key differences.

The similarity lies in the fact that both types of screens are normally launched from toolbar buttons in

the Data Grid and List controls. Another similarity is that for a given entity, if either type of screen is

absent, LightSwitch can generate its own screen on-the-fly. We looked at this for the details data

scenario in the previous paper in this series, but let’s take a look at the new data scenario here.

We’ll look at the EditableExpensesGrid screen for an example. On the toolbar, click the Add button (the

one with the “+” icon) to open a dynamically-generated popup. This is shown in Figure 2.

Figure 2 - A dynamically generated new data popup for the Expense entity

This pop-up is completely functional (complete with any validation logic contained in the entity

definition) and you don’t have to do anything to add it to an application. However in this example, there

is a couple of improvements we want to make, such as hiding the SharePointVendorId data, and

10

eliminating the space in “Share Point” displayed in the label for the SharePointVendor field. Two

property setting changes can be used to fix both problems.

Some Property Settings

To correct the two issues just described, we perform the following steps:

1. Stop the application and open the Expense entity in its designer.

2. Click the SharePointVendor field.

3. In the Properties window, change the Display Name property to “SharePoint Vendor” (to

remove the space between “Share” and “Point” that we saw in the popup).

This is shown in Figure 3.

Figure 3 - Changing a field's default display name

4. Click the SharePointVendorId field and clear its Display by Default property, as shown in Figure

4.

11

Figure 4 - Clearing a field’s Display by Default property

With those properties now correctly configured, we can be assured that any screens we create on the

entity are appropriately configured as well. This repairs the generated popup screen shown in Figure 2,

but we might wish to design our own screen anyway. To design our own New Data screen to use in

place of the generated one, we use the following technique:

1. Add a screen by using the Add New Screen dialog box.

2. Use the New Data Screen template.

3. Select Expense from the Screen Data drop-down list, and click OK.

There is an extra step required to coerce LightSwitch to use this screen when a user clicks the Add…

button in the EditableExpensesGrid screen. Unlike details screens, which support the notion of a default

screen per entity, new data screens are more standalone. To open this screen automatically, we need

to override the code for the toolbar’s Add… button.

As with most coding tasks in LightSwitch, this is relatively simple.

1. In Solution Explorer, double-click the EditableExpensesGrid node to open the screen in its

designer.

2. In the designer, expand the Command Bar node that is indented under the Data Grid node.

3. Right-click the Add… child node.

4. From the context menu, select Override Code.

This is all shown in Figure 5, with numbering corresponding to the steps in this numbered list.

12

Figure 5 - Overriding the Add… toolbar button's code

5. Once in the code editor, we modify the gridAddAndEditNew_Execute event handler2 as shown in

Listing 23.

Listing 2 - Showing the CreateNewExpense screen programmatically.

partial void gridAddAndEditNew_Execute() { Application.ShowCreateNewExpense(); }

2 You may also wish to modify the gridAddAndEditNew_CanExecute event handler to ensure that the appropriate

permission has been granted to the current user. If not, the Add... toolbar button is enabled even if permission on the CreateNewExpense screen is not granted. 3 Note that if you created the code in Listing 2, a new method named gridAddAndEditNew is added to the screen.

You see it displayed in the methods list on the left edge of the screen designer, towards the bottom of the list.

13

The Search Data Template The Search Data Screen template is now the only one we haven’t worked with, so let’s discuss it. If we

use this template in a new screen for the Expense entity, run the application, and then open the screen,

it looks as shown in Figure 6.

Figure 6 - The Search Expenses screen

You might notice that this screen looks a lot like the EditableExpensesGrid screen. However, there are

some subtle differences that we can observe to learn more about screen templates:

The grid is read-only.

The Add…, Edit…, and Delete buttons we have previously seen in other screens are not present

on the toolbar.

The Description column’s data is rendered as hyperlinks.

An auto-generated details screen opens if you click any of the links.

If you want to, eliminate these differences through three changes to the SearchExpenses screen:

Select the Data Grid’s Show add new row option.

Add AddAndEditNew, EditSelected, and DeleteSelected buttons to the command bar to add

data editing capabilities to the grid.

14

Deselect the Data Grid Row control’s Use Read-only Controls property.

This proves that templates are just starter designs for screens. You can change screens once they are

generated to differ greatly from the template they were generated from. While every screen starts out

based on a template, you can delete controls in its visual tree after generating it. You could even delete

everything below the root element to design the screen from scratch.

Making Queries and Fields Searchable One aspect of the Search Screen template we have not yet discussed is the search box itself. The search

box is actually part of the Data Grid and List controls so any screen with one of those controls has a

search box. The premise of the search box is simple. Type in text, press Enter (or click the magnifying

glass icon), and the Data Grid or List displays rows where one of the string fields contains the string you

typed.

You can make a string field non-searchable by editing the entity containing it, selecting the field, and

deselecting the Is Searchable option in the Properties window. Figure 7 shows making such a change to

the LastUpdatedBy field in the Expense entity.

Figure 7 - Clearing the Is Searchable checkbox for the LastUpdatedBy field

Entities have their own Is Searchable option as well. If it is deselected:

the entity’s individual fields’ Is Searchable property settings have no effect

any List or Data Grid control bound to the entity has no search box in its UI.4

While it’s a bit beyond scope for this paper, it’s important to note that when using parameterized

queries, searching really should take place at the screen level; therefore, you may wish to hide control-

level Search boxes. Here’s how you can do so:

4 Note that even if you deselect the Is Searchable option for each and every string field in the entity, the search

box remains visible if the entity’s own Is Searchable option is selected.

15

Create your own UI to capture the parameter values and code to apply them.

Deselect either the screen-level query’s Support Search option or (as just mentioned) the

underlying entity’s Is Searchable option.

Export to Excel Like the Search box, Export to Excel is built into LightSwitch’s List and Data Grid controls. The Export to

Excel button is functional and visible by default as long as the application is configured to run on the

desktop (more on that later).

You can remove a toolbar’s Export to Excel button by selecting the Disable Export to Excel option in the

Properties window when a List or Data Grid control is selected. This is an “opt out” property – that is,

when it is selected, something becomes disabled. Most properties are opt-in, enabling something when

selected.

When a user clicks the Export to Excel toolbar button, Excel opens a new workbook with the following

characteristics:

the first sheet of the workbook is named identically to the control supplying the data and

contains the same data displayed in the control5

row 1 in the sheet contains the field name(s)

rows 2 and beyond contain the data

no formatting is applied to field names or the data (but you can add your own6).

The Export to Excel function in LightSwitch serves as a fully integrated, albeit bare-bones reporting

mechanism. SQL Server Reporting Services (SSRS) (including the free version included with Microsoft®

SQL Server® Express with Advanced Services), is a full-featured reporting tool. SSRS can report not only

on SQL Server data but data from several other major databases as well.

Other reporting options may include third party offerings that integrate into LightSwitch applications as

extensions (one of which we discuss in the next paper in this series).

Designing Screens The screen design techniques we have discussed to this point have involved generating screens from

one of the built-in screen templates and subsequently tweaking the designs slightly. In one case, we

briefly looked at adding a Modal Window group of controls to the EditableExpensesGrid screen, which

involved a more proactive screen design technique. Let’s now take a deeper look at screen design.

5 If paging is enabled for the control, only the data for the currently displayed page is exported.

6 Use Excel 2007’s and 2010’s Format as Table feature to make the entire data set look professionally formatted in

just a few clicks.

16

Working with Generated Screens Let’s consider a screen design example using a new List and Details screen on the BudgetCategory and

Expense entities. Let’s observe what is generated and take inventory of what is in the visual tree. Figure

8 shows the tree, and highlights layout groups of elements within it.

Figure 8 - List and Details screen with layout groups highlighted

This screen has the following characteristics:

The List and Details screen has a List control on the left side.

On the top of the right side, a Text Box displays a description of the selected List control record.

Beneath that Text Box is a Data Grid displaying the child detail records.

The above layout is achieved using Columns Layout and Rows Layout groups. Understanding how

these layout groups work is key to understanding LightSwitch screen layout in general. Here’s a

brief explanation of how layouts work in the screen in Figure 8:

The root of the tree contains a Columns Layout, which divides the screen into left and right

halves.

Each half is organized within a Rows Layout group, each of which stack its child controls

vertically.

17

The left half consists solely of a List control, which thus takes up the entire left half of the

screen.

The right half contains yet another Rows Layout group and the Data Grid.

Within the inner Rows Layout group is the Text Box for the Description field of the

BudgetCategory entity selected in the List.

If more controls are added here, they are vertically stacked above or below this Text Box.

This nesting of layout groups is common in LightSwitch. It allows for definition of regions and sub-

regions of a screen and enables you to control the layout of each as being vertically stacked (with a

Rows Layout) or horizontally organized (using a Columns Layout).

Building Your Own Screens Just because screen templates generate so much layout for you, doesn’t mean you have to use what

they generate. You can, essentially, design your own screens, and with surprisingly few clicks. Any

generated screen can be “stripped down” to just the data and a parent layout group, and then designed

manually. In the example shown in Figure 9, we removed the two outer Rows Layout groups, which

results in a nearly blank screen.

Figure 9 - An emptied screen

Now we can easily alter this screen. For example, we add the following:

18

the data from the BudgetCategories query in a List control

the details of the selected BudgetCategory entity in a collection of simple controls

child data from the Expenses query in a List control (showing just the ExpenseAmount value)

To understand manual screen design better, let’s explore how we implement this example.

Designing Screens from the Members List

There are several ways to add the content outlined above. Perhaps the easiest is to drag and drop items

from the members list on the left of the screen designer onto the visual tree. If we dragged the

BudgetCategories query onto the tree7, a Data Grid control bound to the BudgetCategories query

displays as shown in Figure 10.

Figure 10 – Adding BudgetCategories data in a Data Grid via drag and drop of a query into the visual tree

We then click the Data Grid control and change its type to List.

Using the “Add” Node

If we next clicked the new List control’s child Add node, a context menu appears and within it is an

option for the Selected Item of the BudgetCategories query. Selecting this option adds details controls

7 Individual fields can be dragged and dropped in a similar manner.

19

displaying the values of fields for the currently selected budget category in the List control. The option

is highlighted in Figure 11.

Figure 11 - Using the Add node to insert selected item details data in the visual tree

Selecting that option adds a Rows Layout group with the CategoryDescription field within it. We then

drag the Id field from the BudgetCategories query and insert it right above the CategoryDescription field.

The newly added content that results is highlighted in Figure 12.

20

Figure 12 - Simple controls bound to the selected BudgetCategory item added to the visual tree

The Rows Layout group acts as a container for the Id field’s Label control and the CategoryDescription

field’s Text Box control and assures the two display one beneath the other.

Adding Unbound Groups

To add the child Expense items, we use either of the two techniques we’ve just explored, or we use a

third technique: adding an unbound Rows Layout group and a Data Grid control within it.

Here’s how to implement the third technique:

1. Select the root node Columns Layout group and then click its child Add node.

2. From the context menu, select New Group.

This adds an empty Rows Layout group as a child to the Columns Layout at the tree’s root.

3. Select that new layout group and click its child Add node.

4. From the context menu, select Expenses.

This adds a Data Grid bound to the Expense query, as shown in Figure 13.

21

Figure 13 - A details Data Grid added to an inner Rows Layout group

It’s important to point out that we could have added this Data Grid as a direct child of the Columns

Layout group, rather than within a child Rows Layout. The difference is that we can now add other

content to the Rows Layout group and be assured it appears together with the Data Grid.

We have now seen three ways of adding content to a screen:

Drag and drop from the members list to the tree.

Use a layout group’s child Add node to add specific data.

Add an empty child group and then add content within it.

Were we to run the application and open the new screen, it appears as shown in Figure 14.

22

Figure 14 - Our manually designed screen, executing

Modifying Layout and Control Types

The screen as shown in Figure 14 has a couple of problems. Only two columns in the Data Grid on the

right are visible without scrolling and the middle section adds little value over what’s shown in the List

control. Improving this is simple in LightSwitch, because once elements are laid out in a screen’s visual

tree they can be individually altered without disrupting the rest of the screen’s elements. Consider these

clicks (depicted in Figure 15).

23

Figure 15 - Changing a Columns Layout group to a Rows Layout group, while executing

While executing the application, we click Design Screen on the application ribbon.

Change the parent Columns Layout group to a Rows Layout group.

Highlight and delete the middle child Rows Layout group (to remove the simple controls

displaying the selected BudgetCategory details – this removal is not reflected in Figure 15).

Click Save.

The screen appears as shown in Figure 16.

24

Figure 16 - Our manually designed screen, in a Rows Layout formation

LightSwitch screen design is a practical alternative to approaches that involve positional placement of

controls on a design canvas. The hierarchical relationship between containers and controls means that

aspects of the layout can be changed and the other elements fall into line without requiring any further

explicit configuration.

If you’ve ever done web design and edited HTML, or worked with Silverlight or WPF and edited XAML,

you have seen this concept at work. Changing the type of a parent element does not disrupt its

children. Working with the visual tree is a lot like editing markup, but you do it visually instead of with a

text editor and angle brackets.

Layout Types

LightSwitch allows other layouts. For example a Table Layout group is available. It functions much like a

Columns Layout, but ensures that the elements within a given column region are vertically aligned with

their counterparts in the other column regions. A Tabs Layout, which creates separate tabs for its child

elements rather than separate horizontal or vertical screen regions, is also available. We saw in a

previous paper that a Modal Window group, which displays its contents in a separate popup window,

can be used as well.

25

Composite Controls

Aside from Data Grid and List controls, which bind to collections of records, the only control types we

have looked at so far are all simple controls (like Text Box controls), that bind to a single field in a single

record. Between these collection controls and simple controls lie another type: composite controls.

Composite controls contain a number of child controls, each of which gets bound to a specific field.

However, composite controls function as indivisible elements on the screen, with their own functionality

that involves all the child controls collectively. LightSwitch’s built-in composite controls include the

Address Editor, Address Viewer, Picture and Text, and Text and Picture controls.

To add a composite control, first add a bound Rows Layout group, and then change its type to one of the

composite control types enumerated above. This is shown in Figure 17.

Figure 17 - Changing a Rows Layout group to a composite control

After the composite control type has been selected, you must link each of its child elements to a specific

field in a query on the screen. Figure 18 shows this for an Address Editor control.

26

Figure 18 - Configuring an Address Editor control

As you can see, composite controls exhibit qualities of both layouts and simple controls. In this paper’s

appendix, we present an annotated list of screen element types and explore further screen design topics

including:

working with command bars

sizing and appearance properties

row and column properties

group properties

The material discussed so far, combined with the detailed content in the appendix, provide all the

coverage we’ll need on screen design. That content, in combination with what we’ve discussed in

previous papers gives us all the information we need to build powerful applications in LightSwitch. But

those powerful applications won’t do any good unless we get them into end-users hands. So for the

remainder of this paper, we’ll discuss application deployment in LightSwitch.

Deployment We’ve learned how to build some cool stuff, but having an application work on your own machine, in

Visual Studio LightSwitch, is just the beginning. Your next task is to get that application working on

someone else’s machine. All of this requires a little planning and a little learning. While we can’t take

you through every click, in this section of the paper we’ll discuss your main options and some of the

requirements for each.

27

Client Application Type LightSwitch applications can run as standalone desktop software, or can run within a web browser.

When run in a web browser on an end-user machine, the applications run with fewer security

permissions. This disables certain functionality, including export to Excel. In some computing

environments, that is the preferred model. You need to consider which application type suits your

application best as it is one of the major questions you need to answer during deployment.

Application Server LightSwitch applications are logically architected in a 3-tier fashion. The database, the data

access/business logic, and the client application are separate entities. Whether or not those entities are

deployed to three different physical machines is another matter. All three can run locally on a single PC,

but usually at least the database is physically separated. If this is the case, you have the choice of

running the data access/business logic tier locally on the end-user’s machine (in which case your

application is physically 2-tier) or deploying your data access/business logic layer to its own physical

server (which makes your application physically 3-tier).

On-Premise or Cloud

If you do decide to deploy your data access/business logic layer to a server, you should consider if you’d

like that to be a Windows server (for example, one on a corporate network or managed by a

conventional hosting service) running Internet Information Services (IIS), or in the cloud on the

Microsoft® Windows Azure™ cloud computing platform. Should you decide the cloud is the best place

for your data access/business logic layer, you may want to deploy your database to Microsoft’s SQL

Azure cloud database platform as well.

Configuring Your Deployment Once you have decided on your client application type, number of physical tiers, and whether or not

you’ll be deploying to the cloud, you’ll need to configure your LightSwitch application appropriately.

There are two places you can do this. The first is the Application Type properties page, which you can

select after double-clicking the Properties node in Solution Explorer. The Application Type page is

shown in Figure 19.

28

Figure 19 - the Application Type properties page, where you can specify the client and application server types for your deployment

Click Publish… to open the LightSwitch Publish Application Wizard8. The Wizard is the second place you

can specify your client and application server types. It also solicits further information that may be

required for the specific options you have selected.

Further Requirements There are prerequisites to using LightSwitch Publish Application Wizard, including both procedures you

must execute beforehand and information you must have ready to answer the Wizard’s questions. To

get you fully prepared, let’s look through a quick summary of what these requirements are.

Set Configuration to Release

If you’re using Visual Studio 2010 Professional, Premium or Enterprise, before publishing your

application, use the Solution Configurations drop-down control on Visual Studio’s standard toolbar to

change your project’s configuration from Debug to Release. You can also select Configuration

8 You can right-click the project node in Solution Explorer and select Publish… from the context menu

option, or you can also select Build/Publish projectname from the main menu.

29

Manager… from that drop-down list and then set your individual project configurations in the resulting

dialog box.

Security Certificates

All LightSwitch deployments produce a deployment package file containing all your client application

assets. It is preferable that you sign this file using a digital certificate. While you can leave this file

unsigned, doing so results in a warning message during installation on client machines. You can even

create a test certificate from the Wizard itself. But for commercial-grade deployments, make sure to

purchase a certificate from your web hoster or a trusted certificate issuer. Install it on your machine and

then use the Wizard to select it from your machine’s certificate store, or browse for the physical

certificate file on your hard drive or a network share.

Server Prerequisites

If you have selected IIS as your Application Server type (that is, you’re deploying an on-premise or

conventionally hosted, 3-tier application), you’ll need to make sure the target IIS server has the

necessary prerequisites for LightSwitch applications and their deployment. If not, you’ll need to install

the Visual Studio LightSwitch Server Prerequisites on the server using Microsoft’s Web Platform

Installer.

Azure-Specific Requirements

Of all Microsoft development tools, LightSwitch is the easiest from which to deploy applications to

Windows Azure and SQL Azure, Microsoft’s cloud computing and cloud database services. The

LightSwitch Publish Application Wizard still requires a few things of you, however. If you haven’t

created accounts on Windows Azure and SQL Azure, you need to do so. Free trials are available. See

http://www.microsoft.com/windowsazure/free-trial/ for details. Once your accounts are correctly

created and provisioned, you’ll need the following information to successfully deploy your application:

your Azure subscription ID

the name of a management certificate you have created for your project

the name of the hosted service you created for your project

your Azure Storage account name

the name of an SSL certificate uploaded to your Azure account

your SQL Azure connection string (you can connect to a conventional SQL Server instance from

an Azure-deployed application, but it must have a public facing host name or IP address and

have appropriate ports open for communication).

It takes some practice before deployment feels fully straightforward to you, but using the information

we’ve discussed in this section, you should be well-armed to get your application in users’ hands.

Combine this with all the application design techniques and information we have discussed and you’re

now ready to build and deploy powerful and highly useful business software applications with Visual

Studio LightSwitch.

30

Conclusion The previous papers in this series gave an overview of how LightSwitch works, showed you how to build

your first LightSwitch application and gave you a deeper understanding of how LightSwitch manages

data. This paper took you from a somewhat passive, intermediate knowledge of LightSwitch, to having a

very explicit understanding of LightSwitch’s menu navigation, screen templates, search, export to Excel

functionality, screen design, and deployment.

In our next and last paper, we’ll look at the world of LightSwitch extensions, and how to integrate them

into your applications.

For more information:

Visual Studio LightSwitch Website: http://www.microsoft.com/lightswitch

Visual Studio LightSwitch Dev Center: http://msdn.microsoft.com/lightswitch

31

Appendix

In the body of this paper, we discussed several important screen design topics, including screen

templates, search, adding screen elements, and the core concepts of LightSwitch screen layout. In this

appendix, we go a bit further. We catalog screen elements, detail how to work with command bars, and

discuss the property settings that pertain to sizing and appearance, row and column layouts, and control

groups.

LightSwitch Screen Design Nitty-Gritty It may seem like LightSwitch screen elements are neatly divided into layouts and controls, with the

former always acting as a container of the latter. But LightSwitch layout is actually more nuanced than

that. First, as we saw in this paper, layouts can be nested within each other. In addition, some controls

contain child controls of their own. So the layout/control distinction isn’t so clearly cut.

The proper way to look at LightSwitch screens is as a collection of groups (as opposed to layouts) and

controls. Layouts are groups, but not all groups are layouts. In addition, controls as a category can be

broken down into at least three subcategories. LightSwitch also features the concept of command bars.

These are special groups that appear in numerous contexts in the visual tree. (Command bars can be

seen in numerous screenshot figures in this paper.)

Here is a more thorough accounting of screen element types (groups and controls) and command bars:

Element Types Layouts define the regions of a screen, including their relative position and the contents of each.

Layouts contain controls. There are five layout types:

o Rows Layout

o Columns Layout

o Table Layout

o Tabs Layout

o Modal Window

Collection controls contain one or more child controls, each of which is rendered once for each

row of data to which the collection control is bound. Data Grid and List controls are both

collection controls.

Composite controls (like the Address Editor) contain one or more child controls.

Simple controls (like Text Box and Label) have no child controls.

Layouts, collection controls, and composite controls are all groups. (Understanding this is key to

mastery of LightSwitch screen organization and design.)

Groups can contain child groups as well as child controls.

32

Some groups can only appear as a child group within a specific group type. For example, a Data

Grid Row can only appear as a child to a Data Grid control and no other group types can serve as

such children.

Command Bars Command Bars, which contain child Button controls, are very important in LightSwitch.

Virtually any screen element can have a command bar. For some elements, the command bar

appears automatically as a child element in the visual tree. If the command bar does not

appear, then you can create it by right-clicking the element and selecting Add Button… from the

context menu.

Command bar groups render differently in different circumstances. For Data Grid and List

controls, the command bar renders in the toolbar.

o For a screen’s root layout element, the command bar renders in the ribbon.

o For a Data Grid Row control, the command bar renders as an additional column named

“Commands” to the right of the last data field.

o For a simple control, the command bar renders as a row of buttons beneath the control.

Button controls in the command bar can be changed to Link controls if the command bar is not

rendered to the ribbon or a toolbar.

Button and Link controls in a command bar are typically operation-bound (for example,

AddNew, DeleteSelected). You can also add a generic button and then edit its Execute event

handler code to make it functional.

In toolbars and the ribbon, Button controls can have images.

In the ribbon, Button controls can be small (if the Use Small Button property is set) or large (if

the property is not set, which is the default). This setting affects the button’s height.

If a command bar has no child controls, then it is not be visible when the application executes.

Common Properties Every element type in LightSwitch has its own unique properties. To try and catalog each one would be

difficult and inefficient. However, there are a number of properties that are common to large groups of

screen elements. It does make sense to discuss these common properties here since they appear

frequently, and because understanding them makes the task of learning about the remaining properties

much less overwhelming. Let’s start with the very common alignment and sizing properties that almost

all elements support, and then look at properties specific to various types of groups.

Sizing and Appearance Properties Virtually all elements support Horizontal Alignment and Vertical Alignment properties.

Horizontal Alignment can be set to Left, Right, Center, or Stretch.

Vertical Alignment can be set to Top, Bottom, Center, or Stretch.

The default is Stretch in both cases, and often that is just right. However, there are times when you

want your controls to align to specific edges of its group, and these two properties allow for that.

33

Two companions to the Alignment properties are Width and Height. These can each be set to Auto (the

default), in which case MinHeight/MinWidth and MaxHeight/MaxWidth properties can be set as well to

assure the autosizing doesn’t make an element too compressed or too stretched. You can also set the

Pixels property, which accommodates an explicit height or width (in pixels). Auto and Pixels are

mutually exclusive property options. Selecting one disables the other.

The above properties are contained within the Properties window’s Sizing section. Two important

properties within the Properties window’s Appearance section are:

The Is Visible property, which is supported by most screen elements. It is an option that controls

whether the element is displayed or hidden.

The Label Position property, which is supported by many elements as well and controls where

an element’s label appears relative to the element itself. This property has allowable values of:

o LeftAligned

o RightAligned

o Top

o Bottom

o None

o Collapsed

Figure 20 shows these properties in the Properties window (in this case for a List control):

34

Figure 20 - Portion of Properties window showing common Appearance and Sizing properties

Row and Column Properties Elements in the visual tree which are direct children of Rows Layout, Columns Layout, and Table Layout

groups have the following features:

35

They constitute rows and columns within the screen, or within a region of the screen.

The rows and columns can be sized immutably, but can also be made resizable by the user, and

for groups, can have scrolling enabled.

The Is Column Resizable and Is Row Resizable properties control whether the rows and columns

in a screen display with splitter bars between them.

The Horizontal Scroll Enabled and Vertical Scroll Enabled properties control whether

corresponding scrollbars appear and function.

Figure 21 shows a three-column screen where the left-most column’s Is Column Resizable property and

the middle column’s Horizontal Scroll Enabled property are each selected. The resulting splitter bar and

scroll bar are highlighted.

Figure 21 - Three-column screen with resizable left column and horizontal scroll enabled for middle column

Group Properties Two more properties are worthy of mention. The first is the Use Read-only Controls property which

appears as an option in the general section of the Properties window. Selecting it causes all child data-

bound elements to be rendered as read-only controls such as Label, Money Viewer, and Address Viewer

rather than editable controls such as Text Box, Money Editor, and Address Editor that appears if it were

not selected. The property is deselected by default.

36

Remember that since groups can be nested, the Use Read-only Controls property of one group affects

that of its child groups, and thus the type of controls used within them. Setting the Use Read-only

Controls property in a child group differently than in its parent overrides the property setting in the

parent.

The last property to consider is one that is available only on the parent group for the entire screen (that

is, the element in the root node of the visual tree). That property is Allow Multiple Instances. The

property is deselected by default, which means that clicking a menu link for a screen that is already

open simply makes that screen active. If the property is selected, a second instance (copy) of the screen

loads and displays instead.