Troubleshooting Silverlight, WorkflowServices, WCF and Behavior Extensions

Article
12/14/2011

In my previous posts I’ve written about my experiences with WorkflowServices and Silverlight.

Problem with Extensions

This morning I got an email notification that someone had posted a question about my Silverlight / State Machine Workflow Service sample on MSDN Code Gallery.

“Downloaded current version and ran. Generated remote server not found error at: public SecurityDoor.SecurityWeb.AuthorizeResponse EndAuthorizeKey(System.IAsyncResult result) Can you help? Thanks.”

Since I just updated this sample to use the most recent version of Microsoft.Activities.Extensions I was concerned that I may have broken the sample code somehow. I finally figured out the problem and I thought it might be useful to share with you the cause in case you run into this.

Step 1: Reproduce the problem

I downloaded the bits from Code Gallery and ran the sample in the debugger. Sure enough this is what I saw.

Step 2: Look at the Visual Studio output window for exceptions

My first stop for clues is to see what kind of exceptions are popping up and here they are

A first chance exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll
A first chance exception of type 'System.Configuration.ConfigurationErrorsException' occurred in System.Configuration.dll
A first chance exception of type 'System.ArgumentException' occurred in System.ServiceModel.dll
A first chance exception of type 'System.ServiceModel.ServiceActivationException' occurred in System.ServiceModel.Activation.dll
A first chance exception of type 'System.Net.WebException' occurred in System.Windows.dll

From the bottom up I can see that Silverlight is getting a WebException and that WCF is throwing a ServiceActivationException which is caused by an ArgumentException from the config file because a FileNotFoundException happened.

These are all good clues and I could go and examine the config file right now but there is an easier way…

Step 3: Browse the XAMLX file

I wrote about this previously WF4 WorkflowServices Troubleshooting Tip: Browse the XAMLX and this is a good case to show why it is important to do so. Look what happens when I do.

Server Error in '/' Application.

Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: An error occurred creating the configuration section handler for system.serviceModel/behaviors: Extension element 'silverlightFaultBehavior' cannot be added to this element. Verify that the extension is registered in the extension collection at system.serviceModel/extensions/behaviorExtensions.
Parameter name: element
Source Error:

 Line 12:       </behaviorExtensions>
Line 13:     </extensions>
Line 14:     <behaviors>
Line 15:       <serviceBehaviors>
Line 16:         <behavior>

Source File: D:\code\sd\C#\SecurityDoor.Web\web.config Line: 14

ASP.NET has given me everything I need to know right here. But here is another mystery… this used to work just find and now it’s not. I began to worry that I had somehow broken the SilverlightFaultBehavior class from Microsoft.Activities.Extensions.

Step 3: Search the Web for Exception Info

This has saved me many times. I just copied the exception info and Bing’d it Smile

The first search link saved me a ton of time as it lead me to the answer… a Connect bug

WCF fails to find custom behaviorExtensionElement if type attribute doesn't match exactly

Now this bug claims to have been fixed in .NET 4.0 but clearly it is not.

Step 4: Fix the Unit Tests

I decided that clearly there was a problem and my unit tests were not catching it. After a quick review I realized that I did not have a unit test which verified the SilverlightFaultBehavior added via code or configuration so I opened Microsoft.Activities.UnitTesting and started writing tests. Soon I had a unit test which was failing just like the Silverlight sample was failing.

Why not just fix the sample?

Really? If I do that, how will I know if I do break this behavior at some point in the future? A bug in released code should always raise a red flag about the unit tests. The bug in the code means that I don’t have a test that will catch it. Also, fixing the tests ensures that I correctly understand the bug and that it isn’t something about the sample code itself that is producing the bug.

Finally in my unit tests I realized the problem…

Step 5: Fix the Problem

The problem was so simple and unexpected… I needed to put a space after the comma between the type name and the assembly name in the configuration file.

I verified that the test fails without the space and passes with it. Then I ran all my tests again just to be sure and checked in the changes. These changes affect the unit tests only so I don’t need to issue a patch for Microsoft.Activities.Extensions.

Step 6: Document the Workaround on Connect

Since this problem was listed as a connect bug, I signed in and did two things.

I reported that I can reproduce this error
I added the following workaround

“Be sure to watch out for spacing in the assembly name string. "MyType,MyAssembly" won't work but "MyType, MyAssembly" (note the space after the comma) will.”

Step 7: Update the Sample Code

Now I update the sample code (both VB and C#) on MSDN Code Gallery and post an answer about the problem.

Happy Coding!

Ron Jacobs

twitter: @ronljacobs

blog: https://blogs.msdn.com/rjacobs