Recently, I had to deal with a challenging Silverlight 2.0 problem, namely trying to make a synchronous web service call from the UI thread. I made some interesting discoveries which I’d like to share.

The best solution I found to this problem was a knowlegde base article from Daniel Vaughan: http://www.codeproject.com/KB/silverlight/SynchronousSilverlight.aspx

Daniel writes:

… you may have heard that synchronous web service calls are not possible in Silverlight 2 … Well, in fact, they are. In this article I’ll show you how to perform synchronous web service calls, and introduce you to some types that make performing synchronous calls with generated channel proxies a breeze.
…
Some readers may initially protest that synchronous web service calls have no place in a principally GUI application, because it risks blocking the UI thread, leading to an unresponsive UI etc. And while I agree that it’s critical not to block the UI thread as to maintain an application’s responsiveness, I do believe there is a legitimate case for synchronous web service calls on non-UI threads.

In our case the solution was even much more simple.

To be able to explain it, I first have to describe our problem. We wanted to use the following procedure:

• loading of additional assemblies during our application startup
• which are dependent from both a configuration placed within a config file and some content read out from a database
• where the database content is retrieved as an Xml stream by calling a web service
• and the stream is read out with a .NET XmlReader for performance reasons

Unfortunately we had to switch between parsing the Xml and loading the assemblies. Because of using the XmlReader, this could only be done, if the assemblies were loaded synchronously. Our solution was, to load the Xml stream into a XDocument object and parse it with LINQ each time we needed some information to load an assembly, instead of parsing it on the fly with the XmlReader.

This solution had also a drawback, since using an XmlReader instead of an XDocument and LINQ is more performant. However, in our case we could make some changes to the config file, so we were able to load several assemblies concurrently, which saved us more time than we lost using the XDocument object and LINQ.

As soon as the opportunity arises, I will also give Daniel’s solution a shot an blog about my experiences.

Until then, hang in there!