We've been deploying our site a number of times to different environments successfully but have encountered an issue which seems to be related to the RIA services setup. We are deploying on a Windows Server 2008, 64 bit machine.
Basically we are unable to call any of our WCF RIA Services endpoints, we always get a 404 returned from the server. We are able to hit the the "raw" svc endpoint, receiving the standard autogenerated page but whenever we try to invoke a method we receive a 404.
Just to clarify, the following URL returns the standard autogenerated service page:
http://localhost/ClientBin/Our-Namespace-DomainService.svc
while the following URL simply returns a 404
http://localhost/ClientBin/Our-Namespace-DomainService.svc/binary/GetSchemaVersions
We've done a lot of searching on stackoverflow to no avail. We have been through the basic stuff of completely reinstalling the IIS. ensuring that aspnet_regiis is called, making sure that the svc mimetype is correctly registered (which should be evident by the "raw" page being returned), doing the WCF activation registration, even tried to install RIAServices on the server with SERVER=TRUE (we bin deploy the RIA stuff by default). We also have an additional service endpoint on the site that is "pure" WCF which works just fine (also using a *.svc URL). We see no error messages in our logs and Fiddler and the IIS logs just state that a 404 was returned. As mentioned, we've deployed this to what we think are similar environment (same OS, 64 bit etc.) recently.
We currently think that the somewhat odd URL syntax above (having a path segment after the file) is somehow not correctly interpreted by the IIS pipeline but are looking for clues as to understanding what might be happening.
Any experiences, insights or ways of understanding how/why the code is not properly executed would be much appreciated.
We eventually figured this out ourselves, just quickly adding the answer here for future reference.
Our issue was that the ExtensionlessUrlHandler was ordered before the SVC Handler in the ordered list of the Handler Mappings within IIS. Once we moved the SVC handler up before the ExtensionlessUrlHandler things were working again.
We are now looking into why this ordering somehow became different but that's another story