IIS7 – Classic mode weirdness: Failed to execute URL.

Posted on 1/5/2009 @ 12:06 AM in #SharePoint by | Feedback | 9807 views

Okay, this will affect anyone running SharePoint 2007 on Win2k8. I have made such a move to WCF, that I just don’t care about the in-built ASMX’s anymore .. until .. someone sent me some code that relies on an in-built ASMX.

The problem was, whenever I tried accessing the asmx, I got this weird error -

Application error when access /_vti_bin/<ootbservice>.asmx, Error=Failed to Execute URL.   at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.BeginExecuteUrl(String url, String method, String childHeaders, Boolean sendHeaders, Boolean addUserIndo, IntPtr token, String name, String authType, Byte[] entity, AsyncCallback cb, Object state)     at System.Web.HttpResponse.BeginExecuteUrlForEntireResponse(String pathOverride, NameValueCollection requestHeaders, AsyncCallback cb, Object state)     at System.Web.DefaultHttpHandler.BeginProcessRequest(HttpContext context, AsyncCallback callback, Object state)     at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()     at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Usually, the above error will manifest itself as a simple “Failed to execute URL”, or “Object moved to” error, but if you do set the error logging to verbose/information in SharePoint, you will see the full error message as shown above.

Now, in IIS 7 Manager, it clearly says on the right hand side, under Handler Mappings -

“The application is an application pool that is running in Classic mode, so you can manage ISAPI extensions and native modules that are mapped to paths. You must manage managed handers (system.web/httpHandlers) directly in the configuration file”

Well okay, that’s weird! Are you telling me that even an asmx won’t work.. unless, I re-add their httpHandlers in the web.config that sits under [12]\ISAPI. So I did, and bingo my ye olde tyme asmx’s work again. Wow, that stinks!

Now, apparently this issue doesn’t affect .svc’s. So yet another reason to make the move to WCF. I tell ya, my relationship with asmx’s is so over.

Sound off but keep it civil:

Older comments..


On 4/7/2009 8:35:03 PM Mat said ..
I am running into the same issue.. Could you please post the http handlers that you added to the web.config?


On 6/2/2009 10:03:42 AM yom said ..
Hello,


Could you please post or mail me the content and place of your Web.config ?


Since I'm also getting that strange behavior, it could really be usefull.


On 3/30/2010 12:18:16 AM Brian H. Madsen said ..
Sahil,

you're a legend!!!

fyi, here's the handlers i added to make this work:

<remove verb="*" path="*.asmx" />


<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />


<add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />


<add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false" />


<add verb="*" path="_vti_bin/ReportServer" type="Microsoft.ReportingServices.SharePoint.Soap.RSProxyHttpHandler, RSSharePointSoapProxy, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />


<add verb="*" path="Reserved.ReportViewerWebPart.axd" type="Microsoft.ReportingServices.SharePoint.UI.WebParts.WebPartHttpHandler, Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />

Got me on the right path there Sahil - cheers and thanks!


On 3/30/2010 3:59:46 AM Sahil Malik said ..
Hey Brian - thanks for the contrib. :)