While developing WAP custom resource providers, I have seen myself and others running into the issue of getting 404, resource not found when developing a new API controller.

Typically if we have atleast one API call working against the custom RP, it means that custom resource provider registration is working fine and WAP framework is routing the messages correctly. It is most likely a mismatch between how API client construct the URL or how route configuration is done in Web API. Attaching debugger, doesn’t really help in this scenario, as ASP .NET is not able to find the route to the controller class (yea, that is why it is sending 404). So how do we find out how is the messages get routed.

First and foremost, we need to understand how messages are flowing. Below diagram shows how it will typically be routed in a development boxes (I have marked the default ports in there).

We can use Fiddler tool to capture the traffic and understand the exact messages that are going between various Sites. Since fiddler is a proxy tool, we need to enable proxy at the origin of the message. So if you are interested in finding the messages that Resource Provider API receive, you should set the proxy at Admin API or Tenant API, depending on what specific messages you are trying to look at.

This is what I have done on my test environment (Windows Server 2012 R2), to troubleshoot messages coming to the tenant endpoint on my custom RP.

• Logged on to server as Administrator
• Install Fiddler tool (I used the downloads from Telerik)
• Changed the Identity of ‘Tenant API’ application pool to Administrator

• Opened a new instance of IE and launched Fiddler from Tools > Fiddler
• Configure Fiddler to capture HTTPS traffic (Fiddler : Tools > Fiddler Options)

• Accept the Fiddler Proxy Certificate installation
• From IE, accessed tenant portal and invoked custom resource provider tabs
• Now, messages that goes from Tenant API to custom RP starts showing up in Fiddler.

Note: Fiddler captures all traffic that originate from browser as well. To filter the requests that shows up in Fiddler UI, you can update the ‘Rules’ in Fiddler (Rules > Customize Rules). I have used the following rule to see only the messages that land on my custom resource provider.

static function OnBeforeRequest(oSession: Session) {
   if (oSession.host != “twe-wap01:30032”){
     oSession[“ui-hide”] = “true”;
  }
  ….
}

Thanks to Manish for helping me with the approach.

I was looking at an issue posted in the forum about not able to debug server controller for admin extension. Couldn’t really figure out what could be the root cause, as the controller should get loaded and return data (default expectation). Getting a 404, strange.

Looked at the issue over a remote session and we found the root cause of the issue from event log.

LogName: Microsoft-WindowsAzurePack-MgmtSvc-AdminSite/Operational Error:Unhandled exception: FileLoadException: Could not load file or assembly 'System.Web.Mvc, Version=5.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

For some reason, the NuGet package on the development environment updated the project to MVC 5.2 and the WAP Admin site was not loading the extension DLL because of the failed dependency.

Thought others might also run into this issue (knowingly or unknowingly) . As a quick resolution, we rebuilt the admin extension against MVC 4.x libraries and it started working.