0
votes
namespace StorageRoleMVC4.Controllers
{
    public class SearchController : ApiController
    {
        public Dictionary<string, string> Get([FromUri] string searchString, [FromUri] string searchObject)
        {
            var searchHelper = new SearchStorageHelper();
            var objectList = searchHelper.Retrieve(searchString, searchObject);

            return objectList;
        }
    }
}

Is there anything about this controller that makes it unreachable once it's deployed (to an Azure web role)? I just get a 404 error when I try to reach it. It works great on the local emulator.

The last 2 times I've deployed my project, all the controllers in my web service have returned 404 errors for several hours, until the project seems to fix itself. I'm not sure why, but it might be related.

UPDATE There is a WARNING in the event log on the web role VM after I publish: The application '/' belonging to site '1273337584' has an invalid AppPoolId 'ea7a2e15-9390-49e1-a16b-67ff1cdb7dcb' set. Therefore, the application will be ignored.

This is the id of my site, but the AppPoolId is not correct. Changing the app pool turns the 404 into a 502.

Also, after publishing, the World Wide Web Publishing Service is turned off. When I turn it on and do an IIS reset, after the reset it's turned off again.

When I reboot the web role VM, most of the controllers work again, and the World Wide Web Publishing Service is turned on. But still, this SearchController doesn't work. Or any other new controllers I've created since this problem started happening.

1
Do you have any big dependencies in this project (Windows Identity Foundation needs to install etc.)? One of my solutions has multiple services and it does take a couple minutes or more to spin up after deployment. However, taking a couple hours is not normal. Have you tried to RDP right after the solution is deployed and check any logging you have or hit the page locally (custom errors off)? - Bart Czernicki
Hi Bart, I don't think so. This seemed to start happening right after I implemented simple http authentication, but I published that, and then tested, and everything seemed to work, and then went to bed, and the next morning it was broken. Now, a week later, I published again and broke the controllers. It seems like rebooting the instance fixes the other controllers, but this one I've posted above never works at all - just returns a 404. - Andrew B Schultz
Have you tried profiling with fiddler? ...comparing the request and response headers? Sometimes if they are not correct they will not work. Do you have an ELMAH module deployed with your API to ensure everything is firing? - Bart Czernicki
Yea, all my testing is with Fiddler. I publish, all controllers return 404. I reboot the web role instance, and they're fixed, except for this one. All I do is change the parameters in the URL in the composer. The headers are identical. I even created a new controller and deployed it just to see what happened, and that one is a 404 also. It's almost like I've just reached the limit for how many controllers I can have or something ... any new ones do a 404. - Andrew B Schultz
Also, I've never heard of ELMAH - I'll look into it. I found an error on the web role VM - I'm updating the original post with it. - Andrew B Schultz

1 Answers

1
votes

Well, after a ridiculous amount of unsuccessful troubleshooting, I just rolled back to an earlier version of the code and found that it didn't read the web service when I deployed it. So I started over with that version and re-built the delta.

This involved removing a few web.config entries and removing some libraries, creating a few classes and referencing them in the global.asax (I think that's where it was) in order to override te Authorize attribute...

If anyone has a better answer, I will switch the answer to what you post.