In my previous posts I’ve written about my experiences with WorkflowServices and Silverlight.
- Troubleshooting Workflow Services / Silverlight
- Using Workflow Services and Silverlight Together
- WorkflowServices, CanCreateInstance 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.
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
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
The first search link saved me a ton of time as it lead me to the answer… a Connect bug
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.