Introduction

In part 1 we setup the scene by creating a simple Silverlight/WCF application. In that application the Silverlight application is initialized, it made a call to the underlying WCF service operation "GetWelcomeText" and displayed the text on the UI. We used the basicHttpBinding to establish communication between the SL client and WCF service. In this part, we are going to make some modifications to the configuration files, IIS/Windows Server AppFabric settings and make the application work across boundaries between two different geographical locations using Azure AppFabric Service Bus. The high level picture is going to look like

Source: http://blogs.digitaldeposit.net/saravana

Prerequisite:

One of the challenges of Silverlight and Azure AppFabric service bus integration is configuring access to the clientaccesspolicy.xml file. I've explained in detail, how you can resolve it in this blog post. It's mandatory to complete the procedure explained in that post, before you proceed further.

It's also mandatory to have IIS/Windows Server AppFabric to complete this walkthrough. Please download and install it from http://www.microsoft.com/download/en/details.aspx?id=15848

Create Service Endpoint Behaviour

Expand "Advanced" and "Endpoint Behavior" from the navigation tree and click on the link "New Endpoint Behavior Configuration" as shown below

Click the "Add" button, which will bring "Adding Behavior element extensions" screen as shown below. From the list select "transportClientEndpointBehavior" and click "Add".

Change the name to "slsb_ServiceEndpointBehavior". The final screen should look as shown below

Double click on transportClientEndpointBehavior from the list and make sure CredentialType is SharedSecret.

Create a basicHttpRelayBinding

Navigate to "Bindings" and select "New Binding Configuration.." as shown below

On the "Create a New Binding" window select "basicHttpRelayBinding" and click OK as shown below.

Change the name to slsb_basicHttpRelayBinding, the final configuration should look as shown below.

Create a new Endpoint

Now we are going to create a new WCF end point using the endpointBehavior and basicHttpRelayBinding we created in previous steps.

Navigate to Services\Endpoints, right-click and select "New Service Endpoint" as shown below.

Once the properties window is displayed, provide the configurations as shown below.

The modified web.config file is going to look as shown below

We are going to make few changes here, which we couldn't do on the SvcConfigEditor.exe tool. The modified web.config file is going to look as shown below

The objective for this demo is establishing communication between Silverlight application and remote WCF service via Azure AppFabric service bus. So, we are going to ignore all the security settings for now, which I'll cover in future articles. Things to note

Security is set to "None"

Endpoint address is using "http" (not "https")

Also, I commented out previous local endpoint configurations and things that are not really relevant for this demo to keep it simple.

Configure Virtual Directory in IIS/Windows Server AppFabric

You'll need Windows Server AppFabric for this demo to work, which you can download from http://www.microsoft.com/download/en/details.aspx?id=15848

We are going to host our WCF service on IIS/Windows Server AppFabric. The main reason for that is, we need to take advantage of the "Auto Start" functionality of IIS/ Windows Server AppFabric to start our WCF service automatically when IIS starts and register its namespace in the Azure AppFabric Service bus. Previously this was one of the challenges, since the WCF services hosted just on IIS (without AppFabric) won't get started until the first request hit the service. In this section we will see the configuration required on IIS/Windows Server AppFabric for our WCF service.

Start Internet Service Manager, and click on our virtual directory AppFabricSBandSLIntegration.Web.

On the Actions column, under "Manage WCF and WF Services", click on "Configure" as shown below

Select "Auto-Start" and choose the option "Enabled" as shown below.

After closing the window, you can Start the application, as shown in the below figure.

Reset IIS by opening a command prompt as administrator and typing iisreset. Navigate to our WCF service as shown below and make sure there are no errors and it displays the page as shown below

One of the common errors I've seen, especially while working on corporate networks where a proxy server is used is

Unable to reach watchdog.servicebus.windows.net via TCP (9351, 9352) or HTTP (80, 443)

The solution for the problem is simple, on the web.config file just configure the proxy details as shown below.

<system.net>

<defaultProxy useDefaultCredentials="true">

<proxy proxyaddress="http://<your proxy>:<your port>"/>

</defaultProxy>

</system.net>

You also need to make sure the virtual directory is configured to run under an IIS application pool, with the identity that access to proxy server.

Update the Silverlight application to point to Azure AppFabric service bus URL

The final change we need to make is to update the Silverlight application configuration file ServiceReference.Clientconfig.config file with url pointing to the Azure AppFabric service bus url as shown below

Press F5 to run the application, and now you should see the application working as before but this time via the Azure AppFabric service bus.

One of the key things to note here is, on the Silverlight client side, I only modified the address in the endpoint element. That's because basicHttpBinding is compatible with basicHttpRelayBinding.

The other important thing is, we relaxed the security completely and concentrated only on connectivity for this demo. So, don't use this configuration in production.

Nandri!

Saravana

Introduction

In this article we are going to see the end to end integration of Azure AppFabric Service bus and Silverlight. First we are going to create a very basic "Hello World" Silverlight application that interacts with a WCF operation called "GetWelcomeText" and displays the text returned in the UI. In order to explain the core concepts clearly, we are going to keep the sample as simple as possible. The initial solution is going to look as shown below. The SL application hosted on a local IIS/AppFabric(server) web server and accessed via a browser as shown below.

 

Next, we are going to extend the same sample "Hello World" example to introduce Azure AppFabric service bus as shown in the below picture and show the power of AppFabric Service bus platform, which enables us to use the remote WCF services hosted geographically somewhere in the wild.

Original Source: http://blogs.digitaldeposit.net/saravana

The first part of the article doesn't going to touch anything on Azure AppFabric service bus, it's all about creating a simple SL/WCF application.

Create a Hello World Silverlight Application

Open Visual Studio (use Run as Administrator), and Click New Project from the Start page, which will bring the "New Project" window as shown below

Select Silverlight from Installed Templates, and choose "Silverlight Application" from the list. Provide "AppFabricSBandSLIntegration" as the name and click OK. In the next screen ("New Silverlight Application"), just leave the default values and click OK. The solution structure will look as shown below.

Add a simple WCF service:

Right click on AppFabricSBandSLIntegration.Web ASP.NET application and select "Add New Item", which brings the "Add New Item" window as shown below.

Select "Web" from Installed templates and "WCF Service" from the list provide "AdminService.svc" as the name and click "Add".

Next, rename the default method name "DoWork" to "GetWelcomeText" and changed the return type from "void" to "string" both in IAdminService.cs and AdminService.cs files. The implementation now looks as shown below.

Rebuild the solution by pressing Ctrl+Shift+B.

Convert the web application to use IIS:

By default the ASP.NET web application will be configured to run on a local server (cassini), for our demo we are going to configure it to run under IIS/AppFabric(server). Right click on the AppFabricSBandSLIntegration.Web project, select "Properties". In the properties windows select "Web" from LHS and select the option "Use Local IIS Web Server". Click on "Create Virtual Directory" button to create the virtual directory and click OK on the popup window (you must have opened Visual Studio by Run as Administrator; else this step will give error.)

Build the solution by pressing Ctrl+Shift+B, and navigate to http://localhost/AppFabricSBandSLIntegration.Web/AdminService.svc and make sure no errors encountered.

Configure web.config file with appropriate WCF settings

For this step we are going to use the WCF service configuration tool SvcConfigEditor.exe. Open a Visual Studio command prompt and type SvcConfigEditor.exe. Once the application is opened, click File/Open and navigate to web.config file found under AppFabricSBandSLIntegration.Web folder.

Click on "Create a New Service" link and click the browse button. Navigate to AppFabricSBandSLIntegration.Web/bin/ AppFabricSBandSLIntegration.Web.dll and select AppFabricSBandSLIntegration.Web.AdminService once selected the screen should look as shown below

Click on the "Next" button in the wizard and make sure the contract is selected as shown below.

Click "Next", On "What communication mode is your service using?" option select "HTTP"

Click "Next", On "What method of interoperability do you want to use?" option select "Basic web service interoperability"

Click "Next", On "What's your address of your end point", clear http:// and click "Yes" on the warning.

On the final summary screen, click "Finish". Your web.config file will now look as shown below.

Rebuild the solution by pressing Ctrl+Shift+B. Right click on AdminService.svc file and select "View in Browser". Make sure it displays as shown below without any errors.

Now we have completed all the required stuff on the WCF services side, let's move on to the client side Silverlight application.

Prepare the Silverlight application to communicate with the WCF Service.

Add Service Reference:

The very first step is to create the service reference to our AdminService.svc WCF service. Right click on the AppFabricSBandSLIntegration Silverlight project and select "Add Service Reference", which will bring the window as shown below.

Paste the url of our AdminService.svc file and click "Go". Once the service is resolved, provide "AdvancedServiceReference" as the namespace and click "OK".

The above step should automatically add ServiceReference.ClientConfig file to the AppFabricSBandSLIntegration Silverlight project as shown below.

Open the MainPage.xaml file and add a TextBlock as shown in the below snippet.

Open the MainPage.Xaml.cs file and add the following lines of code. Basically we are instantiating the proxy client, hooking up the "Completed" event and call the asyn method GetWelcomeTextAsync. Once we receive the response from WCF service, SL runtime will automatically execute the code present in the event handler. We are simply displaying the "Hello World from WCF Service" text returned from WCF service in the text block we created in the previous step.

At this stage everything is completed and pressing the "F5" button should execute the ASP.NET/Silverlight application and display the following result

In part 2 of the article, we'll see how we can introduce Azure AppFabric Service bus in the middle between the Silverlight client and the WCF service. You may be wondering, why I have used the SvcConfigEditor.exe to configure the WCF service rather just simply asking the user to paste 4 lines of configuration Xml. The main reason for using the tool is, when we modify the configuration for Azure AppFabric Service Bus, it makes it easy to understand all the available configuration options.

Nandri

Saravana Kumar

Just a quick tip, when you are trying to debug a Silverlight application by putting break point in the Silverlight code and you see the message "Breakpoint will not currently be hit. No symbols loaded for this document." with a hallow icon and warning symbol.

The reason for this is, Silverlight debugging is not enabled on the web application hosting the Silverlight XAP file. You can fix this easily by going to  "Properties" of the web application, choose "Web" from LHS tab, and under Debuggers section select the check box "Silverlight".

Nandri!

Saravana

By default Silverlight applications are allowed to access resources (services) only from the location from where they originated. From Silverlight 2.0 support was included to access services from a remote server (cross-domain), as long as the remote server allows the Silverlight application to access it. This gave administrators more control on who is accessing the resource, and can impose certain restrictions.

The security policy system in the Silverlight runtime requires that a policy file (clientaccesspolicy.xml) be downloaded from a target domain before a network connection is allowed to access a network resource under that target domain.

Basics:

When a connection request is initiated from Silverlight application, the SL runtime tries to download the security policy file using the HTTP protocol. The SL runtime first tries to download a SL policy file with the name "clientaccesspolicy.xml" at the root of the requested target domain using HTTP protocol. If it can't find "clientaccesspolicy.xml" file, it will try and download "crossdomain.xml" file, which was developed by Adobe for Flash. Both the files are recognised by SL runtime.

If the policy file retrieved is successfully parsed and grants permission, a connection is finally opened to the target host. If the policy file retrieved is invalid, the connection to network resource is denied by SL runtime. For more information on policy file please refer to http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx

Challenge with AppFabric Service bus

From the above AppFabric Service bus architecture picture, we can imagine your SL application is running on the LHS (on-premises). The WCF services that the SL application dependant on is deployed on the RHS (on-premises). The communication between the SL and WCF deployed on two geographically separate premises are connected using the Windows AppFabric Service bus.

The important point to note here is the SL application is not going to originate/reside in the same location as the WCF services (RHS on-premise). The SL application would have originated from different source, may be from a local web server on the LHS on-premise. So for the SL runtime the WCF services are from a different domain and cross-domain security policy file (clientaccesspolicy.xml/crossdomain.xml) is required to establish a connection.

Here comes the challenge, as explained in the basics topic earlier. The SL runtime is going to look for clientaccesspolicy.xml file on the root of the requested target domain. In the AppFabric Service bus case, the root is actually the Service bus namespace. Ex:

http://yournamespace.servicebus.windows.net , not the actual location of WCF services on the RHS on-premise. The SL runtime will try to make a HTTP request, equivalent of

http://yournamespace.servicebus.windows.net/clientaccesspolicy.xml

And since that file is not available in that location, it will throw a security exception and won't allow any further network connection.

Previous hacky solutions:

So far developers tackled this challenge by creating a REST service on the WCF RHS on-premise covering the root URL, something as shown below.

[ServiceContract]

public interface IClientAccessPolicy

{

[OperationContract]

[WebGet(UriTemplate = "clientaccesspolicy.xml")]

Message GetPolicyFile();

}

Few examples:

http://blogs.u2u.be/peter/post/2011/02/08/Silverlight-and-the-Windows-Azure-AppFabric-Service-Bus.aspx

http://code.msdn.microsoft.com/CSAzureServiceBusSLRest-41878c00

One of the challenges with this approach is you need to make sure you register the REST service at the end, after registering all your real WCF services. Since the REST service is at the root and it doesn't have a unique URI, registering it first will result in taking the complete namespace and trying to register any other services will result in an error saying

"The specified address already exists.Address....."

Developers tacked this scenario by either manually registering the REST (clientacccesspolicy.xml) service at the end, or by using some custom WCF behaviour logic to delay its registration process.

Hidden Gem in AppFabric SDK 2.0 CTP - Easy Solution

As part of the AppFabric SDK V2.0 CTP samples (download details provided at the end), Microsoft released a sample application called "ClientAccessPolicyPublisher", which allows you to upload your clientaccesspolicy.xml file to your root service bus namespace. Once the file is uploaded you can access it by simply navigating to it using the URL as shown below.

http://yournamespace.servicebus.windows.net/clientaccesspolicy.xml

This completely eliminates all the challenges we have discussed so far and it makes AppFabric service bus easily accessible via Silverlight applications.

The tool is simple to use, open command prompt and execute the exe Microsoft.ServiceBus.Samples.ClientAccessPolicyPublisher.exe

After providing AppFabric Service bus shared secret credentials, it will show the options as shown above. "P" will upload the default clientaccesspolicy.xml file (found under the same folder), which is pretty generic and allows the entire http* and https* connections. If you got specific restrictions you can specify your own.

The other options are self explanatory, which allows to see the existing policy file and delete it if required.

Important: The sample project points to the "appfabriclabs.com" and its hardcoded in code, so you need to open program.cs file and find and replace all "appfabriclabs.com" with "windows.net".

Example:

var acsEndpoint = "https://" + serviceNamespace + "-sb.accesscontrol.windows.net/WRAPv0.9/";

Download Details:

http://www.microsoft.com/download/en/details.aspx?id=17691

WindowsAzureAppFabricSDKSamples_V2.0-CS.zip

\AppFabric SDK V2.0 CTP\Samples\ServiceBus\Silverlight\ClientAccessPolicyPublisher

Special thanks to Mikael Hakansson for pointing me to this SDK sample. When I was there in Stockholm, Sweden for the BizTalk user group meeting and biztalk360.com promotion, I was discussing this topic with Mikael, since it's in our road map to enable biztalk360 to use AppFabric service bus to support remote customer BizTalk server environment.

Nandri

Saravana

When you are trying to build a solution that contains Silverlight or WPF projects using MsBuild you may encounter the error "CS0103: The name ‘InitializeComponent’ does not exist in the current context". While searching I have found various tactics that involves editing the project files, including namespaces etc.

 

But the real reason is you are using the wrong version of Msbuild. Multiple versions of Msbuild gets installs in your machine, through various versions of .NET framework, Visual Studio etc. So, check the path variables and make sure you are using the correct version. If you are using Silverlight 4, you need to use MsBuild.

Nandri!

Saravana

I been working for a while on an internal application involving the following technologies.

• Silverlight 3,
• .NET 3.5
• VS 2008,
• Prism,
• WCF RIA Service Beta,
• Silverlight Toolkit (Nov 2009 Release)

Project Statistics:

Here is the content of our VS solution file, quite reasonable sized application.

• .NET Library Projects : 8
• WCF RIA Services Project : 4
• Prism Modules (Silverlight  Application Projects) : 8
• Silverlight Business Application : 2 (Client and the Server)

First I converted the solution to VS 2010 by just opening the solution file from VS 2010 and navigating through the conversion wizard. No errors encountered during the migration. But obviously the solution didn't compile for few reasons. Majority of the errors were mainly due to 2 references

• System.ComponentModel.DataAnnotation, and
• System.Web.DomainService

I changed the target framework setting in all the .NET Library projects to ".NET Framework 4.0", and fixed the System.ComponentModel.DataAnnotation reference.

RIA Services Changes:

Server Side: Removed the following references from the server side (RIA services) project

• System.Web.DomainServices
• System.Web.Ria

and added the following new references

• System.ServiceModel.DomainServices.Server.dll
• System.ServiceModel.DomainServices.Hosting.dll

which can be found under c:\Program Files\Microsoft SDKs\RIA Services\v1.0\Libraries\Server\.

Client Side: Removed the following references from the client side (Silverlight Application) project

• System.Windows.Ria

and added the following new references

• System.ServiceModel.DomainServices.Client.dll
• System.ServiceModel.DomainServices.Client.Web.dll

In addition to the above RIA dll's you also need to add reference to System.ServiceModel.Web.Extensions.dll (found under c:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client).

On both the server and client projects you need to correct the "using" statements in all the source files.

RIA Services Link Not Visible:

By default after the conversion your WCF RIA Client projects will still remain on "Silverlight 3" target settings. WCF RIA services is not supported on Silverlight 3 and hence you won't see any option to configure the  "WCF RIA Services Link" in the properties windows.  Change the "Target Silverlight Version" to Silverlight 4 and you'll see the option to select the RIA services link.

Option to copy xap files (PRISM Modules) to ClientBin folder was broken

The xap files were not automatically copied to the ClientBin folder (as part of build process) after the migration. I had to reconfigure it by going to Properties (In the Web - Server side project) and selecting Silverlight Applications tab.

Silverlight Toolkit Changes:

Remove the existing references for older version of Toolkit and add the following from the .NET list

• System.Windows.Controls.Toolkit

Silverlight Business Application Template Changes:

This was the biggest challenge for me and took considerable amount of time. At the end, I couldn't fix the existing solution, so recreated a standalone project using the new template and added the files from the previous solution.

Busy Indicator:

The Silverlight Business Application template uses its own version of BusyIndicator (source included) instead of the one from ToolKit, which resulted in some conflicts. I deleted the files under Control (BusyIndicator.*), removed the references and configured to use the one from Toolkit. Beware you need to comment the lines in Style.xaml.

Note:

After the upgrade there is no choice for you to go back to VS 2008. If you are using WCF RIA RC2 then the only choice is VS 2010, SL 4.

Nandri!

Saravana

I've structured my visual studio solution so that the WCF RIA domain services live in a separate project (assembly) from the actual web project. Today I was greeted with the following exception (via Fiddler) when trying to access an operation in the domain service.

System.ServiceModel.CommunicationException: Unrecognized message version.
   at System.ServiceModel.Channels.ReceivedMessage.ReadStartEnvelope(XmlDictionaryReader reader)
   at System.ServiceModel.Channels.BufferedMessage..ctor(IBufferedMessageData messageData, RecycledMessageState recycledMessageState, Boolean[] understoodHeaders)
   at System.ServiceModel.Channels.BinaryMessageEncoderFactory.BinaryMessageEncoder.ReadMessage(ArraySegment 1 buffer, BufferManager bufferManager, String contentType)
   at System.ServiceModel.Channels.MessageEncoder.ReadMessage(ArraySegment`1 buffer, BufferManager bufferManager)
   at BinaryMessageFiddlerExtension.BinaryInspector.GetWcfBinaryMessageAsText(Byte[] encodedMessage)
   at BinaryMessageFiddlerExtension.BinaryInspector.UpdateView(Byte[] bytes)

I couldn't find any resources explaining the solution to this issue, but looks like few people encountered it. In my scenario, the error was caused because the client could not reach the service, and it was returning 404 (thanks to Fiddler), but the exception details on the client side were completely misleading.

The solution to my issue is just to add a project reference to my external assembly which contains all of my WCF RIA services.

Nandri!

Saravana

I guess most of my readers are from BizTalk/BPM background. So, some of these post may not be relevant to them. I'm just using the blog as reference archive for all of the issues I'm encountering during my Silverlight learning. So, please feel free to ignore id ;-)

Exception Detail:

System.InvalidOperationException was unhandled by user code
  Message="The IModuleCatalog is required and cannot be null in order to initialize the modules."
  StackTrace:
       at Microsoft.Practices.Composite.UnityExtensions.UnityBootstrapper.InitializeModules()
       at Microsoft.Practices.Composite.UnityExtensions.UnityBootstrapper.Run(Boolean runWithDefaultConfiguration)
       at Microsoft.Practices.Composite.UnityExtensions.UnityBootstrapper.Run()
       at UI.App.InitializeRootVisual()
       at UI.App.Application_Startup(Object sender, StartupEventArgs e)
       at System.Windows.CoreInvokeHandler.InvokeEventHandler(Int32 typeIndex, Delegate handlerDelegate, Object sender, Object args)
       at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, String eventName)
  InnerException:

Resolution:

Set the following settings on your modulecatalog.xaml file.

Build : Content (Default is page)

Cusom Tool Namespace: (just empty content, default will look something like MSBuild:MarkupCompilePass1)

Event though the extension of the file is xaml, we don't need to compile it. It's just going to be a content file available on the SilverLight app.

Nandri!

Saravana

Just a small reminded for myself. When you are using Publish/Subscribe EventAggregation mechanism provided by PRISM along with Unity to resolve types. It's important to specify the Action method on subscribe to be public.

Example:

TextChangedEvent evt = eventAggregator.GetEvent<TextChangedEvent>();
           evt.Subscribe(OnSubscibeForNewText);

///

///

public void OnSubscibeForNewText(string payload)

If it's not public, Unity will have issues resolving the type and you'll see an exception as shown below

Attempt by method 'Microsoft.Practices.Composite.Events.DelegateReference.TryGetDelegate()' to access method 'ModuleA.ViewModel.ModuleAView2VM.OnSubscibeForNewText(System.String)' failed.

Nandri!

Saravana

When you start learning Silverlight or even to some extend on a medium size project, you'll be fine with deriving your user controls directly from System.Windows.Controls.UserControl. But soon you'll be in a situation to derive your user controls from your own custom user control to keep something consistent. Here are the steps

Step 1:

Create a custom user control derived from System.Windows.Controls.UserControl. Ex:

public class EnvironmentAwareUserControl : UserControl

{

public EnvironmentSettings EnvironmentSettings { get; set; }

}

Step 2:

Once you added a new Silverlight User Control to your project, change it to

from:

public partial class SilverlightControl1 : UserControl

to:

public partial class SilverlightControl1 : EnvironmentAwareUserControl

Step 3:

This is the confusing bit (or the way Silverlight/WPF works). You need the change the XAML as well to reflect that you are deriving it from a custom control.

from :

<UserControl x:Class="Test.UI.SilverlightControl1"

to:

<EnvironmentAwareUserControl x:Class="Test.UI.SilverlightControl1"

or

<local:EnvironmentAwareUserControl x:Class="Test.UI.SilverlightControl1"
xmlns:local="clr-namespace:Test.UI.Controls"

depending on your namespace declaration.

Common Error message you'll see when you try to figure out this "Partial declarations of must not specify different base classes"

Nandri!

Saravana