CommunicationException instead of FaultException

Sep 25, 2012 at 10:48 AM
Edited Sep 25, 2012 at 10:49 AM

We have a problem when running our tests using StatLight and SOAP services.  When using the production Silverlight client, we get FaultException<> from the SOAP services whenever they through an exception.  When running the same code in StatLight tests, we get a CommunicationException instead.

Any pointers on where to start looking at this?  We would really like to write integration tests that verify the exception behavior of the  SOAP services.

/Martin

Coordinator
Sep 25, 2012 at 6:50 PM

When the tests are run within StatLight they need to be considered as 'hosted' by the statlight web server. So any communication to external web services will be tricky and there are a number of things that need to be setup correctly.

  1. Your remote web service needs to make sure it's returning a valid clientaccesspolicy.xml
  2. Your tests need to know where those remote endpoints are located and cannot assume calling the 'home base' will be your web services as StatLight is the web server hosting your tests.
  3. I'm sure there's more things to consider, but check those out and give it a go.

Also, how are you running tests now? (Are you trying to run them from the test project's auto-generated TestPage.html file?) Or have you created your own test web site that hosts the xap?

Sep 26, 2012 at 9:38 AM
Edited Sep 26, 2012 at 10:43 AM

Good suggestionsUnfortunately, we have all of our client access policy files in order. Our existing tests work beautifullyHowever, when we try to assert that the correct SOAP faults are propagated to the client, we only get CommunicationException, not the expected FaultException<>.

If we inspect the HTTP response using Fiddler, we do seem to get a correct SOAP faultso I do not understand how it can map to a CommunicationException and not FaultException<>. Why does that differ when running in StatLight compared to a normally hosted Silverlight application?

All test code is placed in a separate Silverlight assembly that is compiled into a XAP file, hosted in a standard Silverlight web project, running under IIS. Basically, we have done Add -> New Project -> Silverlight Application and written the test cases in the resulting Silverlight class library.  The tests are executed through TeamCity with the service layer hosted on a different machine. (We allow cross-domain access using a standard clientaccesspolicy.xml file.)

Coordinator
Sep 27, 2012 at 6:25 PM

I'm not sure this will be much help either, but possibly something to research...

(Check out the second answer) http://stackoverflow.com/questions/4831651/silverlight-client-doesnt-understand-faultexception

Also read this http://msdn.microsoft.com/en-us/library/ee844556%28v=vs.95%29.aspx

Beyond that, I'm afraid I'm not going to be of much more help.

Sep 28, 2012 at 10:14 AM
Edited Sep 28, 2012 at 10:14 AM

Thank you! Of course, we use the alternative client HTTP stack for this very reason. Thus, we have the following code in our client to switch HTTP stack:

  var httpResult = WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
  var httpsResult = WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);

  if (!httpResult || !httpsResult)
  {
    ...
  }

This stack switch code was lacking in the test Silverlight application.

/Martin (blushing)

Coordinator
Sep 28, 2012 at 4:40 PM

I'm not all that familiar with changing out the client HTTP stack. Out of curiosity, if you put that code in your test does it start working? Also does StatLight work with your changing it out?

You probably already know this, but you can leverage the [AssemblyInitialize] attribute to throw any global setup code.

Anyway, glad you figured it out.