One of the first things I would do after installing CSWorks is to open a browser on another machine in the network and type in "http://MyTestBox/CSWorksDemo/PipesAndTanksDemo.html", where MyTestBox is the name of the machine where I installed CSWorks.

This doesn't work. And it's not supposed to work because of the cross-domain web service call restrictions imposed by your browser. If you have a look at ServiceReferences.ClientConfig file in the Pipes and Tanks Demo xap package (CSWorks.Client.PipesAndTanksDemo.xap in your CSWorksDemo/ClientBin folder; don't worry it's just a ZIP file with XAP extension), you will find endpoint description for LiveData web service calls that looks as follows:



In our case, when Silverlight is trying to make a web service call to http://localhost/CSWorksDemo/LiveDataWebService/Service.asmx, the browser checks the URL of the application which happens to start with "http://MyTestBox". Since it doesn't start with "http://localhost", the browser considers this a potential security threat and blocks the call.

To make things work, just replace "localhost" in the config file with the name (or IP address) of your CSWorks server:



and save updated config to the xap file. Now refresh the page in the browser on the remote machine - Pipes and Tanks Demo should work fine.

Update (June 25, 2010):

with Silverlight 4, you can use relative web service addresses, see this post for details.

While working on one of my projects, I had to make WCF run over a farm of load-balanced message queues. After several days of web search, asking questions and coding I have come up with the following "Step-by step guide for setting up certificate security for WCF over MSMQ communication".

The goal is to implement a secured WCF communication based on MSMQ under the following requirements/assumptions/recommendations.

• All MSMQ traffic must be encrypted and signed.
• No involvement of Windows Domain security and Active Directory.
• No code changes required on the client or on the server side.
• MSMQ version 4.0 (W2K8) is used, but it would be nice to have a solution that works on MSMQ 3.0 (W2K3) as well.
• There must be a well-established and straightforward routine for setting up secured communication that can be followed during test/staging/production deployment.

The weapon of choice is message-based certificate security. To put it simple, it means two things:

Read on...