Walter Almeida's Blog

SilverLight 4.0 + WCF: How to bubble service error messages to client

Developing with SilverLight 4.0 and WCF for the service side, I wanted to do the following:

1- For known/expected service side exception, I want the user to have a clear feedback with the error message shown to him

2- For all exceptions, and for development scenarios, I want the full exception message displayed back to the user.

I used to do that very easily with rich client (WPF) + WCF service. You indeed just need to add the following behavior, server side, to your service:

 

  
<behavior name="metadataAndDebug">
   <serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>

 

Using SilverLight however, this is not enough. Even with the behavior set, you get the following error message at the client level

the server returned an error :  not found

Not very useful... After some research I found out this is due to a limitation of web browsers and the HTTP stack: By default, WCF services return fault messages with an HTTP 500 response code. Due to limitations in the browser networking stack, the bodies of these messages are inaccessible within Silverlight, and consequently the fault messages cannot be read by the client.

This source from Microsoft explains two workarounds to the issue:

http://msdn.microsoft.com/en-us/library/ee844556(VS.95).aspx

The one I used is the following:

Modify the HTTP status code: You can modify your service to return SOAP faults with an HTTP status code of 200, Silverlight 4 so that faults will be processed successfully. How to do this is outlined below. Note that this will make the service non-compliant with the SOAP protocol, because SOAP requires a response code in the 400 or 500 range for faults. If the service is a WCF service, you can create an endpoint behavior that plugs in a message inspector that changes the status code to 200. Then you can create an endpoint specifically for Silverlight consumption, and apply the behavior there. Your other endpoints will still remain SOAP-compliant. 

This is done by create the following behavior extension:

 

  
public class SilverlightFaultBehavior : BehaviorExtensionElement, IEndpointBehavior
    {         
        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
        {
            SilverlightFaultMessageInspector inspector = new SilverlightFaultMessageInspector();
            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(inspector);
        }
        public class SilverlightFaultMessageInspector : IDispatchMessageInspector
        {     
            public void BeforeSendReply(ref Message reply, object correlationState)
            {
                if (reply.IsFault)
                {
                    HttpResponseMessageProperty property = new HttpResponseMessageProperty();

                    // Here the response code is changed to 200.
                    property.StatusCode = System.Net.HttpStatusCode.OK;

                    reply.Properties[HttpResponseMessageProperty.Name] = property;
                }
            }

            public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
            {
                // Do nothing to the incoming message.
                return null;
            }
        }

        // The following methods are stubs and not relevant. 
        public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
        {
        }

        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
        {
        }

        public void Validate(ServiceEndpoint endpoint)
        {
        }

        public override System.Type BehaviorType
        {
            get { return typeof(SilverlightFaultBehavior); }
        }

        protected override object CreateBehavior()
        {
            return new SilverlightFaultBehavior();
        }

    }

 

And registering server side this way:

 

  
<system.serviceModel>
    <extensions>
      <behaviorExtensions>
        <add name=”silverlightFaults” 
             type=”Microsoft.Silverlight.Samples.SilverlightFaultBehavior, 
             SilverlightFaultBehavior, 
             Version=1.0.0.0, 
             Culture=neutral, 
             PublicKeyToken=null”/>
      </behaviorExtensions>
    </extensions>
    <behaviors>
        <endpointBehaviors>
          <behavior name=”SilverlightFaultBehavior”>
            <silverlightFaults/>
          </behavior>
        </endpointBehaviors>
    </behaviors>
    <services>
        <service name=”Calculator.Web.Service”>
            <endpoint address=”” 
                      binding=”basicHttpBinding” 
                      contract=”Calculator.Web.Service” 
                      behaviorConfiguration=”SilverlightFaultBehavior” />
        </service>
    </services>
</system.serviceModel> 

 

Warning: There was an issue in SilverLight 3.0 which is still not fixed in SilverLight 4.0:

The Type for the extension has to be specified in one line, with the correct number of white spaces... type definition is checked as string comparison rather that Type comparison... Be aware of that!

 

 

Model-View-ViewModel Design Pattern - An implementation of RelayCommand for SilverLight

A common pattern for developping applications with SilverLight and WPF is the Model-View-ViewModel (MVVM) Design Pattern. The MVVP pattern is an evolution of the MVC and MVP well-known pattern, specially adapted to the advanced data binding features of WPF and SilverLight. Please refer to the following excellent MSDN article from Josh Smith for a complete description and implementation of the MVVM Pattern for WPF:

WPF Apps With The Model-View-ViewModel Design Pattern

However, as stated in this article title, we're talking about an MVVM pattern for WPF. For those who have tried to develop portable applications working on both WPF and SilverLight, you know this frustration of discovering small differences between WPF and SilverLight and missing classes in  SilverLight as compared to WPF. 

And in our specific case, Josh defines a RelayCommand class, used to simplified the binding with user interface elements commands with underlying actions in the ViewModel class.

Here is the definition of the RelayCommand class:

public class RelayCommand : ICommand
{
 #region Fields

 readonly Action

This class makes use of the CommandManager object and the RequerySuggested event. When a user actions the UI in WPF, this triggers the CommandManager to requery all the commands. In Silverlight the CommandManager class does not exist: you have to do the work yourself!

So I created the following RelayCommand implementation, working for SilverLight:

 public class RelayCommand : ICommand
 {
 #region Fields

 readonly Action

And here is the definition of the ICommandManager interface:

 public interface ICommandManager
 {
 event EventHandler RequerySuggested;
 }

Now when creating a new command, you should pass a reference to an object implementing the ICommandManager interface. This object will usually be the ViewModel class itself. It is then the responsability of the ViewModel class to trigger the RequerySuggested event when anything in the state of the ViewModel changed that requires the command to be rebinded. That's it, this completes the SilverLight implementation of the MVVM pattern. 

Great resource for SilverLight development on SharePoint 2010

Here is a great resource about SilverLight development on SharePoint 2010:

http://code.msdn.microsoft.com/SP2010Silverlight/

Include sample code and a video explaining how to develop with SilverLight for SharePoint 2010. Including topics like: SilverLight WebPart development, SilverLight field controls development, the use of the HTML bridge to pass data between SilverLight WebPart and the web page. And last but not least: how to connect SilverLight WebParts with no page refreshes and using the standard WebPart connection mechanism.

Also a sample making use of the new restfull access to SharePoint lists using ADO.NET services.

A must read for those who are starting developping with SilverLight on SharePoint 2010!

SilverLight/WPF: Handling mouse Entering/Leaving composite controls

I have been struggling sometime now trying to handle the following scenario, which seems quite simple at first. This problem highlights the difficulties one can face when doing WPF and/or SilverLight developments: while the most cases are working just fine and great, you will regularly face issues you were not expecting. Making WPF/SilverLight development rather complex.

The scenario is the following: I have a page, composed of several controls. The composing controls are themselves composite controls : there are composed of multiple UI controls

I want to style my page the following way: whenever the user moves his mouse cursor over a control, I want to play an animation to highlight this control. And whenever the user moves his mouse cursor out of a control, I want to play an animation to remove highlight on this control

Let illustrate this with a concrete example: I have a page showing a grid view of products and a form view displaying the details of the selected product. The grid view and the form view are two composite user controls composed of other controls.

Whenever the grid view is focused, I want the following visual result:

 

 

And whenever the form view is focused, I want the following visual result:

 

 

Well... seems quite obvious at first: why not just add a Trigger on the control, triggered by a changing value of the property "IsMouseOver" (for WPF. For SilverLight there is no "IsMouseOver, so instead we should add EventTriggers on "MouseEnter" / "MouseLeave"). When "IsMouseOver" changes, then we can then just play the adequate storyboard.

However the reality is more complex than that... The main control will receive MouseEnter and MouseLeave events (with associated changes of "IsMouseOver" ) whenever the mouse cursor enters/leaves the targeted control AND when the mouse cursor enters/leaves any of the sub-controls composing the targeted control!

Which results in a flickering display: in our example, while moving the mouse inside the scope of the product form view, the form view will be constanlty switched from highlighted to not-higlighted when for example the mouse enters the scope of a TextBox.

I have tried quite a few things to fix that issue. I registered to the MouseEnter/MouseLeave events, in order to generate custom events that will really reflect entering/leaving the main control, and hiding entering/leaving internal controls. However this was a failure and there is no easy way to really be able to know if a MouseLeave event on the main control is because we're really leaving the main control or entering a sub-control.

I have made some research to see what others are doing but could not find a satisfactory answer. I had to admit this is not an easy task on WPF/SilverLight where it just should be!!

So here is the final solution that I implemented:

The problem is really on the MouseLeave event: we have no easy way to figure out if we are really leaving the main control or just entering a sub-control. No problem on the MouseEnter event: whenever we receive a MouseEnter event it means that we are entering the main control or already are over the main control and entering a sub control. But the important point is: we know we are over the main control.

The solution is therefore the following

• Only rely on MouseEnter event: whenever a MouseEnter event is received, we do the animation for Highlighting the control (and keep a flag set to do the animation only once)
• We know we are leaving a control, when we are entering another one (in our example we know we are leaving the product grid view when we are entering the product form view.
• So: when a MouseEnter event is received, in addition to  do the animation for Highlighting the controlwe, we also do the animation to remove higlight from all other controls

That's it! It is working great!

And a few quick tips for doing it on WPF, using the MVVM pattern:

• Add an "IsActiveView" Property on the ViewModel of each composite control
• In the main page loaded event, register to the composite controls MouseEnter events, and in the handlers: set/unset accordingly the "IsActiveView" property of each control
• Create DataTriggers binded on the "IsActiveView" to trigger the appropriate animation

Hope it can help others facing the same issue!