Contact   •   Products   •   Search

Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs

AspNetCompatibility in WCF Services – easy to trip up


This isn’t the first time I’ve hit this particular wall: I’m creating a WCF REST service for AJAX callbacks and using the WebScriptServiceHostFactory host factory in the service:

<%@ ServiceHost Language="C#" 
        Service="WcfAjax.BasicWcfService"                 
        CodeBehind="BasicWcfService.cs"        
        Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory" %>

 

to avoid all configuration. Because of the Factory that creates the ASP.NET Ajax compatible format via the custom factory implementation I can then remove all of the configuration settings that typically get dumped into the web.config file. However, I do want ASP.NET compatibility so I still leave in:

<system.serviceModel>        
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
</system.serviceModel>

in the web.config file. This option allows you access to the HttpContext.Current object to effectively give you access to most of the standard ASP.NET request and response features. This is not recommended as a primary practice but it can be useful in some scenarios and in backwards compatibility scenerios with ASP.NET AJAX Web Services.

Now, here’s where things get funky. Assuming you have the setting in web.config, If you now declare a service like this:

    [ServiceContract(Namespace = "DevConnections")]
#if DEBUG 
    [ServiceBehavior(IncludeExceptionDetailInFaults = true)]
#endif
    public class BasicWcfService

(or by using an interface that defines the service contract)

you’ll find that the service will not work when an AJAX call is made against it. You’ll get a 500 error and a System.ServiceModel.ServiceActivationException System error. Worse even with the IncludeExceptionDetailInFaults enabled you get absolutely no indication from WCF what the problem is.

So what’s the problem?  The issue is that once you specify aspNetCompatibilityEnabled=”true” in the configuration you *have to* specify the AspNetCompatibilityRequirements attribute and one of the modes that enables or at least allows for it. You need either Required or Allow:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]

without it the service will simply fail without further warning.

It will also fail if you set the attribute value to NotAllowed. The following also causes the service to fail as above:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.NotAllowed)]

This is not totally unreasonable but it’s a difficult issue to debug especially since the configuration setting is global – if you have more than one service and one requires traditional ASP.NET access and one doesn’t then both must have the attribute specified. This is one reason why you’d want to avoid using this functionality unless absolutely necessary. WCF REST provides some basic access to some of the HTTP features after all, although what’s there is severely limited.

I also wish that ServiceActivation errors would provide more error information. Getting an Activation error without further info on what actually is wrong is pretty worthless especially when it is a technicality like a mismatched configuration/attribute setting like this.

Make Donation
Posted in ASP.NET  WCF  AJAX  


Feedback for this Post

 
# re: AspNetCompatibility in WCF Services – easy to trip up
by jmorris April 12, 2010 @ 8:59pm
Good WCF 'gotcha' post! WCF is awesome but the myriad of configurations possible make it a bit tedious at times. I am in the process of converting a bunch of ASMX's to WCF and have run into my fair share of "Why doesn't this work?", then I change a setting or two and it just works.
# re: AspNetCompatibility in WCF Services – easy to trip up
by Ronald April 14, 2010 @ 4:37am
Usually the Windows event log gives a more detailed description of why things went wrong when a ServiceActivationException occurs (or any other vague internal WCF exceptions). I hit several weird WCF issues during development and the event log always contained the necessary info to solve the issue.

Note that you even need to add the AspNetCompatibilityRequirements attribute when your service isn't available on a http binding. I had a service that could only be reached via net.tcp but even then you have to add this attribute. Otherwise it fails with the same error.
# AspNetCompatibility in WCF Services – easy to trip up - Rick Strahl's Web Log
by PimpThisBlog.com April 19, 2010 @ 8:39am
Thank you for submitting this cool story - Trackback from PimpThisBlog.com
# re: AspNetCompatibility in WCF Services – easy to trip up
by Warren June 07, 2010 @ 11:23am
Hi Rick,

I have an ajax-enabled WCF service that sometimes does not return to either the success or failure callback. I set up tracing and notice that I'm getting 1 less message when it fails to send back. I'm stumped at this point. I don't know where to look to further investigate the issue to see where the failure is happening.

Basically, I'm returning a list of objects which is being serialized as json. When the object list is small it pretty much always returns. If the list is larger (say around 300 items) then it will only periodically return results. I may need to call the javascript function 4 or 5 times before the call successfully reaches the "OnSuccess" function. However, the server side service functions are executed on every single call. Any insights you could help with would be much appreciated.

Thanks,
Warren
# re: AspNetCompatibility in WCF Services – easy to trip up
by Scott Hannen June 26, 2014 @ 1:42pm
Thank you. Thank you very, very, very much. Really, thank you.
 


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2014