Recommended Downloads

• Visual Studio 2010 SP1 (required)
• Silverlight 5 Beta Tools for Visual Studio SP1 (required)
• Expression Blend Preview for Silverlight 5(optional)

VS/VWD 2010 SP1 + SL5Tools

SL4 development requires VS2010 or VWD2010 RTM and SL4Tools, and optionally Blend 4. VS2010 SP1 has SL4 support built in, so SL4Tools is not needed if you’ve already upgraded to VS2010 SP1. SL5 development requires VS2010 or VWD2010 SP1 and SL5Tools, and optionally Blend Preview for Silverlight 5.

Install

SL5 Beta Tools installs Silverlight 5 Beta Developer Runtime, SDK, Update to VS2010 SP1 (KB2502836), and WCF RIA Services V1.0 SP2 Preview.

Multi-targeting

Once installed, you can create SL5 projects like you used to with previous versions of SL:

SL5 projects can reference assemblies built against early versions of Silverlight. Below screenshot shows a SL5 project using SL4 SDK via Project->Add Reference…–>Browse:

And the result in .csproj file:

<Reference Include="System.Windows.Controls, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client\System.Windows.Controls.dll</HintPath>
</Reference>

Please notice the HintPath and assembly version (Btw, SL5 increased assembly version from 2.0.5.0 to 5.0.5.0).

You can also upgrade existing SL4 projects to target SL5:

The upgrade changes <ProjectGuid> and <TargetFrameworkVersion> in .csproj, as well as upgrading all SDK references to SL5’s.

Binding Debugging

A popular new feature in SL5Tools is xaml binding debugging:

Blend Preview for Silverlight 5

Optionally, you can also install Blend Preview for Silverlight 5, which is basically Blend 4 with SL5 support:

And you can use both VS and Blend on the same SL5 project and switch between them:

Troubleshoot & Uninstall

VS2010 SP1, SL5Tools and Blend Preview install all take a long time, so please be patient. If you run into install issues, you may want to take a look at install logs in %temp% directory, and attach those logs when you report install issues to Microsoft:

C:\Users\ningz\AppData\Local\Temp>dir /b /o-d *silver*
Silverlight 5 Beta Tools for Visual Studio 2010 SP1_20110413_220121704.html
Silverlight 5 Beta Tools for Visual Studio 2010 SP1_20110413_220121704-MSI_RiaServices.msi.txt
Silverlight 5 Beta Tools for Visual Studio 2010 SP1_20110413_220121704-MSI_silverlight_sdk.msi.txt
Silverlight0.log

To uninstall Silverlight 5 tools, use control panel to uninstall each component individually:

• SL5 runtime, SDK, RIA Services, Blend Preview

• And Update to VS2010 (KB2502836) (please click “View installed updates” to see below)

Enjoy developing against Silverlight 5!

Overview

Below class diagram shows key classes for Silverlight touch support:

• Touch
  • Touch events are asynchronous.
  • Touch events are always fired via application level Touch.FrameReported event.
  • Since touch events are global, they are direct, and there is no need for touch capture.
  • Multitouch is supported.
• Manipulation
  • Manipulation events are exposed by UIElement. They are routed events.
  • Manipulation events are always fired, IsManipulationEnabled property isn’t supported.
  • Manipulation events are synchronous.
  • Only translation and expansion are supported, rotation is not.
  • Concurrent multiple manipulations are not supported.
  • Gesture isn’t supported directly. It is supported by XNA and Silverlight for Windows Phone Toolkit.
• Controls: on Windows Phone 7, ScrollViewer supports pan & flick, Button supports tab.

Silverlight 3

Platform Requirements

Multitouch requires an environment (device; platform and operating system; hosting application such as a browser) that can propagate the touch input to an individual application, such as your Silverlight-based application.

Windows 7 supports multitouch input at the operating system level. This is supported in part through a message (WM_TOUCH). Already at this level, the operating system provides a promotion of multitouch messages to mouse messages. The promotion is present so that multitouch users can use touch and gestures to substitute as mouse moves or mouse clicks. This is useful when interacting with applications that may not be touch-aware, and the application does all its spatial input processing through mouse events and messages. Windows 7 also coalesces the messages when appropriate, so that applications do not have to process an overflow of intermediate messages that all generate incremental events.

Internet Explorer version 8 as a browser host is also multitouch aware. Internet Explorer version 8 forwards platform multitouch messages to plug-ins such as Silverlight that are running within Internet Explorer, such that Silverlight applications can interact with multitouch input.

Multitouch Input for Silverlight (shown for IE8 host)

Multitouch is also supported for Silverlight in current versions of Firefox hosts running on Windows 7, and for out-of-browser applications running on Windows 7. However, multitouch input is not supported for applications running in full-screen mode.

Registering for Multitouch

As part of the broader platform architecture for multitouch, each application that wants to receive multitouch messages must register its HWND (Touch API for Windows 7 includes RegisterTouchWindow for this purpose). The Silverlight 4 run time takes care of this registration step, and registers Silverlight as a runtime and all applications that use Silverlight as the runtime. Therefore it is not generally necessary to interact directly with platform code to process multitouch input. However, the characteristics of multitouch interaction within Touch API for Windows 7 and Silverlight 4 multitouch are fairly specific:

• Silverlight 4 is registered for raw touch input, not gestures. If your requirements include gestures, you have to process touch input into gestures using your own application code, within the context of Silverlight. Alternatively, you may need a larger interoperation design so that you can include a separate HWND that is multitouch registered for gestures from the platform, and interoperates with a Silverlight content area.

• In general, Silverlight 4 promotes raw touch input to mouse events. (However, on a per-touchframe basis, you can disable promotion, as is described in upcoming sections of this topic.)

• Within a host, certain gestures might be promoted by the browser host to become events other than mousedown/mousemove/mouseup.

Promotion to Mouse Events

Mouse event promotion exists so that multitouch users can use touch and gestures to substitute as mouse moves or mouse clicks. Conceptually this is the default, because applications that predate or do not consider multitouch would not know what API to call to perform the promotion, and therefore the platform does the mouse promotion in most cases. Silverlight 4 perpetuates the general concept of mouse event promotion for much the same reasons. Any given existing Silverlight control might have handlers for mouse events, but not specifically for multitouch events. For example, a button would be expected to act as if clicked when the user used a multitouch device to interact with it.

Mouse event promotion does have the potential for event dualism in cases where there is deliberate handling of a multitouch frame and its touch points. Within the body of the handler for a Silverlight multitouch event, you can suspend mouse event promotion for the duration of the primary touch down. For example, if you wanted to create a touch-aware button that performed different actions based on the touch characteristics, you could suspend the promotion so that your button did not promote to the usual "click" behavior, and instead went to your discrete logic for how to handle the input. To do this, call SuspendMousePromotionUntilTouchUp as one of the first operations of your handler.

The exact nature of mouse promotion is not documented here, because it is a platform characteristic. Generally speaking, the mechanism is a message-to-message promotion.

Touch to Gesture

Silverlight processes multitouch messages at the level of the raw message, analogous to the platform WM_TOUCH, along with access to other APIs that can capture touchpoint characteristics at that raw level that are then exposed as Silverlight APIs. Silverlight does not natively process touch to gestures, use the platform capabilities to that effect, or process WM_GESTURE. (Processing WM_GESTURE would require a registration state with the platform that Silverlight 4 does not opt into.)

If you want to process multitouch using the gesture metaphor, your code must handle the touch events and use the API exposed under Silverlight 4 and process into gestures, with or without using the platform API for gestures. This is not trivial.

Touch API

One important difference between multitouch input and other input techniques supported in Silverlight (mouse, keyboard, stylus) is that you register for multitouch events on an application-wide basis, not by adding handlers to specific input elements (UIElement objects). This is consistent with the metaphor that Silverlight as a whole is the "application" registered with the platform.

• To assign a multitouch event handler, you assign a handler for the static event Touch.FrameReported. System.Windows.Input.Touch is a static service class that exists solely for this purpose with Touch.FrameReported as its only API.

• The handler you write for Touch.FrameReported is based on the TouchFrameEventHandler delegate.

• In a typical UI design, you might have areas of the UI that you intend to support specific multitouch actions within, and other areas where it would be better to use mouse promotion and not necessarily process the input as multitouch. To determine where the primary touch point is, you may have to evaluate the overall coordinate against the location of your multitouch-aware element, and its bounds. See GetPrimaryTouchPoint for more information and example code.

• As mentioned previously, you may want to suspend mouse event promotion as part of your TouchFrameEventHandler logic. To do this, call SuspendMousePromotionUntilTouchUp as one of the first operations.

• Touch messages as reported to Silverlight 4 are typically combined as frames, which start with a primary "down" touch point. Sometimes you are only interested in the first touch point and the first "up" But the frame may contain other touch points and "move" actions. To access the full collection of points in a frame in your handlers, call GetTouchPoints. For a given touch point, probably the most important information is its Position.

• Other APIs expose information that in the platform API would be found in the TOUCHINPUT structure. Examples of such API are:TouchFrameEventArgs.Timestamp; TouchDevice.DirectlyOver; TouchPoint.Size; TouchPoint.TouchDevice. Depending on your scenario, you might not always need this level of information.

Manipulation API in Silverlight Version 4

The Silverlight 4 UIElement class has several events related to manipulations, as well as event support classes such as ManipulationStartedEventArgs. However, these APIs and the related manipulation concepts do not have full support under Silverlight 4 at run time. To handle these events, your application must be targeting Silverlight for Windows Phone. The events exist in the Silverlight 4 assemblies in order to provide common designer support for both Silverlight 4 and Silverlight for Windows Phone.

Silverlight for Windows Phone 7

Gesture Support in the Silverlight Framework

For a full list of supported Windows Phone Silverlight gestures, see the UI Design and Interaction Guide.

Silverlight for Windows Phone allows you to process touch input by using manipulation events. By using these events, you can move and scale objects in response to touch and multi-touch input. The events are described in the following table.

Event	Description
ManipulationStarted	This event occurs when the user starts a direct manipulation by placing their finger or fingers on the screen.
ManipulationDelta	This event occurs repeatedly while the user is moving their finger or fingers on the screen.
ManipulationCompleted	This event occurs when the user removed their finger or fingers from the screen

Note:

Silverlight controls that are supported on Windows Phone are gesture-aware, and support gestures such as tap, pan, and flick. You can handle simple gestures such as tap, double-tap, and tap-and-hold by using mouse events. For more information, see the Input for Windows Phone topic.

Gesture Support in the XNA Framework

The XNA framework offers a robust touch gesture system for developing applications. Developers can leverage this built-in gesture system instead of implementing one from scratch. The following XNA gestures are supported in Windows Phone.

GestureType	Description
Tap	A finger touches the screen and releases.
DoubleTap	This gesture represents two taps in succession.
Hold	A finger touches the screen and holds it in place for a brief period of time.
FreeDrag	A finger touches the screen and moves in any direction.
VerticalDrag	A finger touches the screen and moves in an up or down direction.
HorizontalDrag	A finger touches the screen and moves in a left or right direction.
DragComplete	Marks the end of a FreeDrag, VerticalDrag, or HorizontalDrag gesture.
Flick	A finger drags across the screen and is lifted up without stopping.
Pinch	Two fingers press on the screen and move around.
PinchComplete	This gesture marks the end of a Pinch gesture.

The following list provides useful topics and articles for implementing gesture support in an XNA application:

• Working with Touch Input (Windows Phone)

• Detecting Gestures on a Multi-touch Screen (Windows Phone)

• Windows Phone 7 Gestures Compared

Overview

New hardware and API in the Windows 7 operating system provide applications the ability to receive input from multiple touches simultaneously. WPF enables applications to detect and respond to touch in a manner similar to responding to other input, such as the mouse or keyboard, by raising events when touch occurs.

WPF exposes two types of events when touch occurs: touch events and manipulation events. Touch events provide raw data about each finger on a touchscreen and its movement. Manipulation events interpret the input as certain actions.

Prerequisites

You need the following components to develop an application that responds to touch.

• Microsoft Visual Studio 2010.
• Windows 7.
• A device, such as a touchscreen, that supports Windows Touch.

WPF exposes two types of events when touch occurs: touch events and manipulation events. Touch events provide raw data about each finger on a touchscreen and its movement. Manipulation events interpret the input as certain actions.

Terminology

The following terms are used when touch is discussed.

• Touch is a type of user input that is recognized by Windows 7. Usually, touch is initiated by putting fingers on a touch-sensitive screen. Note that devices such as a touchpad that is common on laptop computers do not support touch if the device merely converts the finger’s position and movement as mouse input.
• Multitouch is touch that occurs from more than one point simultaneously. Windows 7 and WPF supports multitouch. Whenever touch is discussed in the documentation for WPF, the concepts apply to multitouch.
• A manipulation occurs when touch is interpreted as a physical action that is applied to an object. In WPF, manipulation events interpret input as a translation, expansion, or rotation manipulation.
• A touch device represents a device that produces touch input, such as a single finger on a touchscreen.

Controls that Respond to Touch

The following controls can be scrolled by dragging a finger across the control if it has content that is scrolled out of view.

• ComboBox
• ContextMenu
• DataGrid
• ListBox
• ListView
• MenuItem
• TextBox
• ToolBar
• TreeView

The ScrollViewer defines the ScrollViewer.PanningMode attached property that enables you to specify whether touch panning is enabled horizontally, vertically, both, or neither. The ScrollViewer.PanningDeceleration property specifies how quickly the scrolling slows down when the user lifts the finger from the touchscreen. The ScrollViewer.PanningRatio attached property specifies the ratio of scrolling offset to translate manipulation offset.

Class Diagram

Below class diagram highlights the key classes and their members for touch support:

• Touch
  • Touch events are exposed both by UIElement, UIElement3D, and ContentElement as bubbling events, and via Touch.FrameReported as application level event (to be compatible with Silverlight).
  • While touch down, move and up events are both tunneling and bubbling, touch enter and leave events are bubbling only.
  • Touch device capture is explicit via UIElement.CaptureTouch method.
  • Touch events are synchronous.
  • Touch events are always fired, whether manipulation events are fired or not.
  • WPF supports multitouch.
• Manipulation
  • Manipulation events are exposed by UIElement as bubbling event only.
  • Manipulation events are fired on an UIElement only its IsManipulationEnabled is true.
  • Manipulation events are synchronous.
  • WPF supports three types of manipulation: expansion and rotation (including single finger rotation with pivot point), and inertia.
  • Touch device capture is implicit with manipulation.
  • Static class Manipulation contains methods to get and update manipulation parameters outside of manipulation event handlers. It also contains methods for more advanced usage of manipulation logic, such as adding adding and removing manipulators. 
  • WPF supports multiple gestures.
  • WPF doesn’t support gestures, or 3D manipulation.
• ScrollViewer has built-in support for manipulation and inertia, and it is customizable by applications.

Touch

Touch Events

The base classes, UIElement, UIElement3D, and ContentElement, define events that you can subscribe to so your application will respond to touch. Touch events are useful when your application interprets touch as something other than manipulating an object. For example, an application that enables a user to draw with one or more fingers would subscribe to touch events.

All three classes define the following events, which behave similarly, regardless of the defining class.

• TouchDown
• TouchMove
• TouchUp
• TouchEnter
• TouchLeave
• PreviewTouchDown
• PreviewTouchMove
• PreviewTouchUp
• GotTouchCapture
• LostTouchCapture

Like keyboard and mouse events, the touch events are routed events. The events that begin with Preview are tunneling events and the events that begin with Touch are bubbling events. When you handle these events, you can get the position of the input, relative to any element, by calling the GetTouchPoint or GetIntermediateTouchPoints method.

The Execution Path of Touch Events

To understand the interaction among the touch events, consider the scenario where a user puts one finger on an element, moves the finger in the element, and then lifts the finger from the element. The following illustration shows the execution of the bubbling events (the tunneling events are omitted for simplicity).

The following list describes the sequence of the events in the preceding illustration.

1. The TouchEnter event occurs one time when the user puts a finger on the element.

2. The TouchDown event occurs one time.

3. The TouchMove event occurs multiple times as the user moves the finger within the element.

4. The TouchUp event occurs one time when the user lifts the finger from the element.

5. The TouchLeave event occurs one time.

   When more than two fingers are used, the events occur for each finger.

Manipulation and Inertia

Manipulation Events

For cases where an application enables a user to manipulate an object, the UIElement class defines manipulation events. Unlike the touch events that simply report the position of touch, the manipulation events report how the input can be interpreted. There are three types of manipulations, translation, expansion, and rotation. The following list describes how to invoke the three types of manipulations.

• Put a finger on an object and move the finger across the touchscreen to invoke a translation manipulation. This usually moves the object.

• Put two fingers on an object and move the fingers closer together or farther apart from one another to invoke an expansion manipulation. This usually resizes the object.

• Put two fingers on an object and rotate the fingers around each other to invoke a rotation manipulation. This usually rotates the object.

More than one type of manipulation can occur simultaneously.

When you cause objects to respond to manipulations, you can have the object appear to have inertia. This can make your objects simulate the physical world. For example, when you push a book across a table, if you push hard enough the book will continue to move after you release it. WPF enables you to simulate this behavior by raising manipulation events after the user’s fingers releases the object.

For information about how to create an application that enables the user to move, resize, and rotate an object, see Walkthrough: Creating Your First Touch Application.

The UIElement defines the following manipulation events.

• ManipulationStarting

• ManipulationStarted

• ManipulationDelta

• ManipulationInertiaStarting

• ManipulationCompleted

• ManipulationBoundaryFeedback

By default, a UIElement does not receive these manipulation events. To receive manipulation events on a UIElement, set UIElement.IsManipulationEnabled to true.

The Execution Path of Manipulation Events

Consider a scenario where a user "throws" an object. The user puts a finger on the object, moves the finger across the touchscreen for a short distance, and then lifts the finger while it is moving. The result of this is that the object will move under the user’s finger and continue to move after the user lifts the finger.

The following illustration shows the execution path of manipulation events and important information about each event.

Manipulation events

The following list describes the sequence of the events in the preceding illustration.

1. The ManipulationStarting event occurs when the user places a finger on the object. Among other things, this event allows you to set the ManipulationContainer property. In the subsequent events, the position of the manipulation will be relative to the ManipulationContainer. In events other than ManipulationStarting, this property is read-only, so the ManipulationStarting event is the only time that you can set this property.

2. The ManipulationStarted event occurs next. This event reports the origin of the manipulation.

3. The ManipulationDelta event occurs multiple times as a user’s fingers move on a touchscreen. The DeltaManipulation property of the ManipulationDeltaEventArgs class reports whether the manipulation is interpreted as movement, expansion, or translation. This is where you perform most of the work of manipulating an object.

4. The ManipulationInertiaStarting event occurs when the user’s fingers lose contact with the object. This event enables you to specify the deceleration of the manipulations during inertia. This is so your object can emulate different physical spaces or attributes if you choose. For example, suppose your application has two objects that represent items in the physical world, and one is heavier than the other. You can make the heavier object decelerate faster than the lighter object.

5. The ManipulationDelta event occurs multiple times as inertia occurs. Note that this event occurs when the user’s fingers move across the touchscreen and when WPF simulates inertia. In other words, ManipulationDelta occurs before and after the ManipulationInertiaStarting event. The ManipulationDeltaEventArgs.IsInertial property reports whether the ManipulationDelta event occurs during inertia, so you can check that property and perform different actions, depending on its value.

6. The ManipulationCompleted event occurs when the manipulation and any inertia ends. That is, after all the ManipulationDelta events occur, the ManipulationCompleted event occurs to signal that the manipulation is complete.

Boundary Feedback

The UIElement also defines the ManipulationBoundaryFeedback event. This event occurs when the ReportBoundaryFeedback method is called in the ManipulationDelta event. The ManipulationBoundaryFeedback event enables applications or components to provide visual feedback when an object hits a boundary. For example, the Window class handles the ManipulationBoundaryFeedback event to cause the window to slightly move when its edge is encountered.

Mouse Promotion

You can cancel the manipulation by calling the Cancel method on the event arguments in any manipulation event except ManipulationBoundaryFeedback event. When you call Cancel, the manipulation events are no longer raised and mouse events occur for touch. The following table describes the relationship between the time the manipulation is canceled and the mouse events that occur.

The event that Cancel is called in	The mouse events that occur for input that already occurred
ManipulationStarting and ManipulationStarted	Mouse down events.
ManipulationDelta	Mouse down and mouse move events.
ManipulationInertiaStarting and ManipulationCompleted	Mouse down, mouse move, and mouse up events.

Note that if you call Cancel when the manipulation is in inertia, the method returns false and the input does not raise mouse events.

The Relationship Between Touch and Manipulation Events

A UIElement can always receive touch events. When the IsManipulationEnabled property is set to true, a UIElement can receive both touch and manipulation events. If the TouchDown event is not handled (that is, the Handled property is false), the manipulation logic captures the touch to the element and generates the manipulation events. If the Handled property is set to true in the TouchDown event, the manipulation logic does not generate manipulation events. The following illustration shows the relationship between touch events and manipulation events.

Touch and manipulation events

The following list describes the relationship between the touch and manipulation events that is shown in the preceding illustration.

• When the first touch device generates a TouchDown event on a UIElement, the manipulation logic calls the CaptureTouch method, which generates the GotTouchCapture event.

• When the GotTouchCapture occurs, the manipulation logic calls the Manipulation.AddManipulator method, which generates the ManipulationStarting event.

• When the TouchMove events occur, the manipulation logic generates the ManipulationDelta events that occur before the ManipulationInertiaStarting event.

• When the last touch device on the element raises the TouchUp event, the manipulation logic generates the ManipulationInertiaStarting event.

EventArgs Class Diagram

Below class diagram shows all the touch and manipulation EventArgs classes and relevant types.

Diagram

Summary

• Timeline is the base class of animation classes and Storyboard. It provides BeginTime, Duration, FillBehavior, RepeatBehavior, AutoReverse etc. dependent properties, and Completed event.
• Storyboard is a collection of Timelines, including animations and storyboards. It provides Begin, Stop, Pause, Resume etc. methods, and TargetName and TargetProperty attached properties.
• Basic animations: [Double|Point|Color]Animation classes animate correspondingly typed dependent properties between two values specified by From, To, By properties. They use EasingFunction property to animate changes non-linearly:
  • Easing functions: Silverlight provides 11 easing function classes ([Back|Bounce|Circle|Cubic|Elastic|Exponential|Power|Quadratic|Quartic|Quintic|Sine]Ease), all subclass of EasingFunctionBase, which provides dependent property EasingMode. 
• Key-frame animation: key-frame animations support animating through a collection of key frames, each with KeyTime and Value properties. They also support multiple interpolation methods between key frames: discrete, easing, linear, spline. So there are 13 key frame classes: [Discrete|Easing|Linear|Spline][Double|Point|Color]KeyFrame and ObjectKeyFrame.

Table

Visual Studio setup cannot run in compatibility mode. For more information see the ‘Installing’ section in the Visual Studio Readme at "http://go.microsoft.com/fwlink/?LinkId=143397".

After searching the Internet and tried a few things, what worked for me is to uncheck “Run this program in compatibility mode” in vm_web.exe’s Properties dialog:

If the checkbox is checked and grayed out, click “Change settings for all users” button at the bottom of the dialog, and then uncheck “Run this program in compatibility mode” in the popped up “Compatibility for all users” dialog:

After that, rerun vm_web.exe and it should succeed.

Below is relevant section in Visual Studio readme at http://go.microsoft.com/fwlink/?LinkId=143397. I removed the registry entry for vm_web.exe and VS2010’s setup.exe, but not sure whether it helped or not.

2.1.10 Visual Studio Setup cannot be run in Program Compatibility Mode

Visual Studio 2010 and/or the .NET Framework 4 Setup fails with 1603 error code or blocks running in Program Compatibility Mode.

Windows Program Compatibility Assistant indicates that Visual Studio Setup might not have installed correctly, and prompts the user to reinstall by using the recommended setting (program compatibility mode).

To resolve this issue:

Visual Studio Setup cannot run in program compatibility mode.  Ensure that the compatibility mode setting is not enabled system-wide or for the Visual Studio Setup application.

Check the manual setting

Compatibility mode could have been set manually on the Compatibility tab on the executable file properties.

1. On the Visual Studio Setup media, locate setup.exe.
2. Right-click setup.exe and then click Properties.
3. On the Compatibility tab, clear "Run this program in compatibility mode for" and then then click OK.

Check Program Compatibility Assistant registry settings

Compatibility mode could have been set by Program Compatibility Assistant on earlier failed or canceled attempts to run Visual Studio setup.exe.

1. Click Start, and then click Run.
2. Type regedit, and then click OK.
3. Browse to each of the following keys and delete any value that refers to setup.exe in the Visual Studio install path:
   • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted
   • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

Rerun Visual Studio Setup

1. Open Windows Explorer.
2. Browse to Visual Studio setup.exe.
3. Double-click setup.exe to run Visual Studio Setup.

Related KB Article

http://support.microsoft.com/kb/931709

Another Workaround:

Instead of executing the <DVD ROOT>\setup.exe, execute <DVD ROOT>\setup\setup.exe

Troubleshooting Steps

• Is Silverlight installed?
  on Windows, make sure “Microsoft Silverlight” is in Control Panel –> Programs and Features:
  
  On Mac, make sure /Library/Internet Plug-Ins/Silverlight.plugin is there. If Silverlight isn’t installed, you can install the latest version from http://www.silverlight.net or http://www.microsoft.com/silverlight.
  • Do you have administrative privilege on the machine?
    You will need local administrative privilege to install Silverlight.
  • Do you have webshots/kiwee toolbar installed?
    There are known issues with Silverlight and old version of Webshots/Kiwee from American Greetings. The fix is to upgrade to their latest version from their web sites. Please see Why do I keep getting prompted to install Silverlight? for details.
• Is Silverlight enabled?
  For Internet Explorer, select menu item Tools –> Manage Add-ons, make sure Microsoft Silverlight is enabled for all web sites:
  For Firefox, select menu item Tools –> Add-ons, click Plugins tab, make sure Silverlight Plug-In is enabled:
  
• Is the issue site specific?
  try http://silverlight.net: if you see the showcase Silverlight application on the top right of the page, then your issue is likely to be site specific, please report the issue to the site owner. O/w, please click the Forums tab at http://silverlight.net page, search and/or report the issue there.  
• Is the issue browser specific?
  try open the page in a different browser (IE/Firefox/Chrome on Windows, Safari/Firefox/Chrome on Mac) and see whether the issue repros. If it doesn’t repro, it is likely to be a browser specific configuration issue. Again, it may help to search http://forums.silverlight.net to see whether this is a known issue; and if not, report it.

Report Silverlight Setup Issue

When you report a Silverlight setup issue, it’d help a lot if you can include the following information:

• a short description of the issue
• operating system and browser you are using
• the site you are having problem with
• Silverlight setup log: under %temp% folder (like C:\Users\ningz\AppData\Local\Temp on Win7 or C:\Documents and Settings\ningz\Local Settings\Temp on WinXP), there are two files: a short Silverlight0.log and a longer SilverlightMSI.log).

Other Helpful Sources

• For Vancouver Olympics:
  • http://www.mediaevangelism.com/olympics/faq2.aspx
  • http://www.mediaevangelism.com/olympics/faq.aspx
• How to manually clean up a broken Silverlight installation?
• Uninstalling Silverlight 4 Beta on OSX
• http://silverlight.net

This is first version, I will keep adding content to the post and keep it up to date with issues I see reported. Thanks!

Solution: if you have old version of Webshots Toolbar or Kiwee Toolbar from American Greetings, you should upgrade to latest version from their web sites.

Details:

A few people trying to view Olympics videos from www.nbcolympics.com got prompted to install Silverlight, so they did and then hit F5; the page somehow prompted them to install Silverlight again, so they did again; but this time Silverlight install fails with a telltale error code 1514: Silverlight is already installed; if you want to reinstall, you need to uninstall first. So they uninstall and reinstall, but that didn’t help: they got prompted to install Silverlight again.

After quick investigation, I’ve found a common cause of old version of Webshots or Kiwee installed on those users’ machines. To check, you can find Webshots from Control Panel –> Programs and Features:

or on disk:

The fix is to go to www.webshots.com and upgrade to the latest version (3.1.5.7617 for now):

then you should be able to watch Olympics video just fine with Webshots toolbar enabled as well:

I will publish another blog post with common setup issues and solutions for Silverlight.

Disclaimer:

• I am publishing this blog in a hurry to help those with trouble viewing Olympics video, so I may not get all facts right. I’d appreciate all feedback/correction/suggestion.
• This is my personal blog. What I say in this blog is my opinion only. It doesn’t represent Microsoft or any other organization.

If you write Silverlight controls, you should consider writing design time assemblies for your controls too, for two simple reasons:

• developer productivity: try to imagine Silverlight development without tools like Visual Studio or Blend! For custom controls, you may need to provide much of the design time experience for your controls in Visual Studio or Blend yourself.
• designers: XAML and tools like Blend enable developers and designers work together. A key design criteria for Silverlight controls is to make sure designers can use them without writing a single line of code.

Design time experience usually includes (but not limited to) the following:

1. Metadata for property window, like category, infotip, custom property/binding/collection editors etc.
2. Metadata for design surface, like initializer, adorner, context menu, adapters etc.
3. Toolbox integration, like icons, control registration
4. intellisense for code editor

Except intellisense (please see Add Rich Intellisense for Your Silverlight Controls) and control registration (please see Register Silverlight Controls with visual Studio and Blend), above design time experience are usually delivered through design time assemblies. Below I will discuss various approaches of delivering design time experiences, in increasing complexity and flexibility, and gradually introduce pieces of the naming convention for design time assemblies.

Runtime Assembly Only

The simplest way to deliver design time experience is to package design time code into the runtime assemblies, especially when design time metadata are meaningful at runtime too, like TypeConverterAttribute.

The pros and cons of this approach:

• Pro: simple
  • no separate design time assemblies, simpler setup
  • design time attributes are specified directly on the runtime code, easier to maintain
• Con: tight coupling of runtime and design time code
  • perf degradation because of useless design time code at runtime
  • design time dependencies (like MWDs and other VS/Blend assemblies) get dragged into runtime unnecessarily
  • can’t service runtime or design time independently
  • can’t support multiple designers (like both VS2008/Blend2 and VS2010/Blend3)

The cons are particularly bad for Silverlight, because design time assemblies are actually .NET assemblies, with references to Silverlight types. Mixing Silverlight and .NET assemblies can be challenging and confusing, and may lead to subtle bugs. Also, Silverlight applications are mostly web applications, so download size and performance are particularly important. Dragging in .NET assemblies in Silverlight applications certainly doesn’t help. So this approach is highly discouraged, unless there is strong justification for it.

Shared Design Time Assembly

So the revolutionary step forward is to decouple design time and runtime code, release and service them with separate assemblies. This opens up all kinds of possibilities. Of course, we need a way to link design time assemblies to their corresponding runtime assemblies, without introducing any unnecessary dependency or perf degradation to runtime assemblies. Hence the naming convention: if a runtime assembly Foo.dll is referenced in a Silverlight project, the designer (like Visual Studio and Blend) will first try to load design time information like icons (via another naming convention, see How to Add an Toolbox Icon for Your Silverlight Control) and design time metadata (via interface, like IRegisterMetadata for VS2008 and Blend2, or IProvideAttributeTable for VS2010 and Blend3. Please see How to Write Silverlight Design Time for All Designers: Visual Studio 2008, Blend 2; Blend 3, and Visual Studio 2010) from the runtime assembly; it will then look for a design time assembly by the name Foo.Design.dll in the same directory as Foo.dll; if found, the designer will try to load design time information from Foo.Design.dll as well.

Designer Specific Design Time Assembly

Visual Studio is mostly for developers, while Blend is mostly for designers, so they have different requirements for design time experiences. Putting all design time code in one shared design time assembly introduces tight coupling among designers. So the naming convention is enhanced: for runtime assembly Foo.dll, there is a shared design time assembly Foo.Design.dll that’s loaded by all designers; each designer will also try to load its own design time assemblies, like Foo.VisualStudio.Design.dll for Visual Studio, and Foo.Expression.Design.dll for Blend. The designer specific design time assembly is loaded after the shared design time assembly. Third party designers can define their own designer specific design time assembly. Silverlight Toolkit December 2008 Release is using this naming convention. Please see Design Time Features in Silverlight Toolkit and Design Time Feature Implementation in Silverlight Toolkit for more information.

Design Sub Folder

So to support both Visual Studio and Blend, each runtime assembly has three design time assemblies, in the same directory, and a package (like Silverlight SDK or Silverlight Toolkit) usually contains several runtime assemblies. So the directory gets a bit crowded. A minor improvement is to put the design time assemblies under a Design subfolder. So the naming convention is further enhanced: if a designer (like Visual Studio or Blend) can’t find corresponding design time assemblies in the same directory as a runtime assembly, it will look for them in the Design subfolder, if it exists. 

Support Multiple Versions of MWDs

Design time are built on top of designer extensibility framework, which consists of several dlls like Microsoft.Windows.Design.Extensibility.dll and Microsoft.Windows.Design.Interaction.dll. We usually call them collectively as MWDs. To make life more interesting, sometimes we have to introduce breaking changes to the extensibility framework, like VS2008 and Blend2 use MWD version 3.5, VS2010 and Blend3 use MWD version 4.0, and they are incompatible. So if you have a runtime assembly Foo.dll, and you want your users to be able to develop against it with both VS2008 and VS2010, you have to provide two sets of design time assemblies: one set built against v3.5 MWDs and used by VS2008, and another set built against v4.0 MWD and used by VS2010. The two sets of design time assemblies probably have a lot of code in common, while the one for VS2010 may have some new code to leverage the new functionalities exposed by VS2010. Since design time assemblies are loaded by name and you can’t have two files with the same name, so the naming convention is enhanced yet again:

for a runtime assembly Foo.dll, the shared design time assembly is named Foo.Design*.dll, the Visual Studio specific design time assembly is named Foo.VisualStudio.Design*.dll, and the Blend specific design time assembly is named Foo.Expression.Design*.dll, where * can be zero or more valid characters for file names. When a designer (like Visual Studio or Blend) tries to load a design time assembly and several fit the naming convention, zero or one will be loaded:

• If the MWD version referenced by the design-time assembly has a different major version number than the designer’s MWD version, then the design-time assembly will not load and is bypassed.
• If more than one design-time assembly is compatible with the designer’s MWD version, the Designer loads the one compiled against the highest MWD version that is less than or equal to the designer’s MWD version.

Silverlight 3 Toolkit October 2009 Release uses this naming convention to support both VS2008 and Blend3/VS2010. Please see Silverlight Design Time: Toolkit October 2009 Release Update, How to Write Silverlight Design Time for All Designers: Visual Studio 2008, Blend 2; Blend 3, and Visual Studio 2010, and Extensibility Series – WPF & Silverlight Design-Time Code Sharing – Part I more information.

Support Both WPF and Silverlight

To complicate life further, since WPF and Silverlight are so awfully similar, you may be tempted to try to write it once and run with both WPF and Silverlight. You are not alone. There are many articles on how to share source code and/or binaries across Silverlight and WPF. We’d like to do that for design time assemblies too, i.e. have the same design time assemblies for both WPF and Silverlight controls. One approach is to make most of the design time assemblies platform agnostic, and limit platform specific (WPF or Silverlight) code and references to a small platform specific assembly. Silverlight 3 SDK GDR 2 (installed by VS2010 automatically too) uses this approach for DataGrid designer (there is a System.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dll in the SDK directory). Please see Extensibility Series – WPF & Silverlight Design-Time Code Sharing – Part I for more information.

Last One Wins

The same design time metadata for a class or its member can be specified multiple times in multiple design time assemblies, which allows the shared design time assembly to specify default/common behavior and then designer specific design time assemblies to override it if necessary. The same design time metadata can also be specified multiple times within a single design time assembly (please see Design Time Feature Implementation in Silverlight Toolkit as an example, where DescriptionAttribute for a class or its property can be added by AddDescriptions, AddAttributes and AddTables methods). So we need to know which metadata wins. The simplest and most logic design is last one wins. This is mostly true but not always. Sometimes the result can be un-deterministic when the same design time metadata is specified several times but with different values.

Feedback

Design time sounds easy, but devil is in the details! Feedbacks are always appreciated. Please let me know what issues you run into, what requests/improvements you’d like to make, for both design times experience and designer extensibility framework. Thanks!

Drag and drop is a common UX paradigm and a top requested feature. In Silverlight 4 Beta, we introduced a basic set of API to enable the most common scenario of dragging pictures files and dropping them to Silverlight applications, and we designed the API to allow us to expose more drag and drop functionalities down the road without API change, hopefully.

API

Below is the core of the new API:

namespace System.Windows
{
    public abstract class UIElement : DependencyObject
    {
        // Fields
        public static readonly DependencyProperty AllowDropProperty;

        // Events
        public event DragEventHandler DragEnter;
        public event DragEventHandler DragLeave;
        public event DragEventHandler DragOver;
        public event DragEventHandler Drop;

        // Properties
        public bool AllowDrop { get; set; }
    }

    public delegate void DragEventHandler(object sender, DragEventArgs e);

    public sealed class DragEventArgs : RoutedEventArgs
    {
        // Methods
        public Point GetPosition(UIElement relativeTo);

        // Properties
        public IDataObject Data { [SecuritySafeCritical] get; }
        public bool Handled { get; set; }
    }
}

namespace System.Windows.Controls
{
    public abstract class Control : FrameworkElement
    {
        protected virtual void OnDragEnter(DragEventArgs e);
        protected virtual void OnDragLeave(DragEventArgs e);
        protected virtual void OnDragOver(DragEventArgs e);
        protected virtual void OnDrop(DragEventArgs e);
    }
}

• AllowDrop: this is dependency property, indicating whether an element is a drop target.
• DragEnter, DragLeave, DragOver & Drop: these are routed events. They bubble up, and fire only on elements with AllowDrop set to true.
• OnDragEnter, OnDragLeave, OnDragOver & OnDrop: these are protected virtual functions for subclasses to override. 
• DragEventArgs: this class allows drop target event handlers or method overrides to access the data being dragged or dropped.

Usage

There are primarily two ways to use Silverlight’s drag and drop API:

• Silverlight applications can handle those drop target events and process the files dropped in the event handlers.
• Silverlight controls can override those drop target virtual functions to process the data being dragged and dropped, and enable themselves to be drop targets.

Limitations

The drag and drop functionality shipped in Silverlight 4 Beta only enables the most common scenario: Silverlight plugin as a file drop target. Please notice the following limitations with current implementation:

• there is no drop source support (QueryContinueDrag & GiveFeedback).
• there is no DragDropEffects or DragDropKeyStates in DragEventArgs.
• there is no visual for the dragged object or DragDropEffects.
• only file drag and drop is supported:
  • all drop target events fire only when files are being dragged and dropped.
  • IDataObject, DataObject and DragEventArgs.Data support only one format: “FileDrop”, and the data is of type FileInfo[].
• most of IDataObject methods throw NotImplementedException.
  
• for drag and drop to work on Windows, Silverlight plugin must be windowed. In another word, if <param name="windowless" value="true"/> is specified, drop events won’t fire.
• since Silverlight plugin on Mac is always windowless, you need to hook up JavaScript drop events to trigger Silverlight drop events. In another word, if you want your Silverlight application to support file drop on Mac as well as Windows, you will need to add following script and Silverlight plugin attributes to the hosting html or aspx page:

  <!-- add following script before end of HEAD tag -->
  <script type="text/javascript">
      function handleDragEnter(oEvent) {
          // Prevent default operations
          oEvent.preventDefault();
  
          var flag = silverlightControl.dragEnter(oEvent);
  
          // If we handled it successfully then stop propagation of the event
          if (flag)
              oEvent.stopPropagation();
      }
  
      function handleDragLeave(oEvent) {
          // Prevent default operations
          oEvent.preventDefault();
  
          var flag = silverlightControl.dragLeave(oEvent);
  
          // If we handled it successfully then stop propagation of the event
          if (flag)
              oEvent.stopPropagation();
      }
  
      function handleDragOver(oEvent) {
          // Prevent default operations
          oEvent.preventDefault();
  
          var flag = silverlightControl.dragOver(oEvent);
  
          // If we handled it successfully then stop propagation of the event
          if (flag)
              oEvent.stopPropagation();
      }
  
      function handleDropEvent(oEvent) {
  
          // Prevent default operations
          oEvent.preventDefault();
  
          var flag = silverlightControl.dragDrop(oEvent);
  
          // If we handled it successfully then stop propagation of the event
          if (flag)
              oEvent.stopPropagation();
      }
  </script>
  <!-- use JavaScript drop target events to trigger Silverlight's drop target events -->
  <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%"
    id="silverlightControl" ondragenter="handleDragEnter(event)" ondragover="handleDragOver(event)" 
    ondragleave="handleDragLeave(event)" ondrop="handleDropEvent(event)" >
  

  
  

• DragEventArgs.Data is only accessible in Drop event. Accessing DragEventArgs.Data in DragEnter, DragOver and DragLeave may cause SecurityException. And accessing Directory, DirectoryName or FullName property of the FileInfo object from DragEventArgs.Data may cause ArgumentNullException. 

Demo App

Below is a demo app:

• the top left nested grids use drop target event handler to display DragEventArgs info.
• the top right nested grids contain an ImageDropTarget user control, which overrides OnDrop method to render the dropped file if it is an image.
• the bottom listbox shows the sequence of drop target events, their bubbling up, and DragEventArgs info.

you can find the complete source here.

Feedback

While we are excited to add drag and drop to Silverlight, we know there are a lot to finish/improve, and what we released is just a Beta. As always, your feedback is highly appreciated, and will be used as an important data point to help us prioritize the work. Thanks!

• Install, configuration and runtime UI are in Arabic and RTL layout on Arabic culture
• Support mixed BiDi/ComplexScript text
• Support RTL layout with FlowDirection attribute and implemented by all controls

Below screenshots demonstrate some of the support:

• Install UI:
  
• Configuration UI:
  
• Controls with FlowDirection set to RightToLeft:
  

For those curious, you may notice that:

• there is a new ar directory under %programfiles%\Microsoft Silverlight\4.0.41108.0, besides the 10 directories that have been there since SL3: de, en-us, es, fr, it, ja, ko, zh-Hans, zh-Hint. The ar directory contains Arabic resources for Silverlight runtime assemblies.
• the MUI resource dlls contain Arabic resources:
  

We will continue adding more support to more cultures in Silverlight. The Arabic support debuted in Silverlight 4 Beta is particularly important, since it is the first RTL language Silverlight supports. If you notice any bug or have suggestions, please let me know.