-
Notifications
You must be signed in to change notification settings - Fork 91
Help, my app isn't working!
We often see questions on StackOverflow and MSDN forums that start with that very general question. The best way to figure out what's going on with your app is to isolate the problem to either your mobile client, your backend, or both.
First, we recommend that you either use Fiddler to capture traffic to your mobile app (more on that below), or use a simple logging handler in your client to log all outgoing requests. You can then try that request by itself in a REST client like Fiddler or Postman and see exactly what's happening.
Here's a sample HTTP delegating handler that logs all outgoing requests and responses. Use it when you create your DatasyncClient object:
var options = new DatasyncClientOptions
{
HttpPipeline = new HttpMessageHandler[] { new LoggingHandler(true) }
};
client = new DatasyncClient(YOURURL, options);The .NET Server SDK uses Entity Framework Code First with a database initializer that creates the database if it doesn't exist. By default, Code First creates the database (and seeds it with the optional Seed method) when the database is first accessed. So, just deploying a server project will not create the database for you--you have to first send a request. You can do this by either using a quickstart client app or by using a REST client (see below).
To learn more, see:
- Entity Framework “Code First” not seeding or creating databases - no errors
- Why is the seed method not being called?
- Database.Initialize Method
You should also enable breaking on exceptions in your client app. If you're using Visual Studio, turn on the exception assistant in Tools -> Options -> Debugging -> General -> Enable the exception assistant. You may also want to turn on first-chance exceptions in the Exceptions debug window (press Ctrl+Alt+E while debugging), or put a breakpoint on the line(s) of code that are causing errors.
Once you know what requests are being sent from your client, you can debug the request itself using a REST client such as Fiddler or Postman.
Just add the header ZUMO-API-VERSION with a value of 3.0.0 in your request. If using the v4.2.0 libraries, use a ZUMO-API-VERSION with the value of 2.0.0. The ASP.NET Core Service supports both versions.
For instance, to see all items in the default Todo table that is in the Mobile Apps quickstart, you would do:
GET https://service.azurewebsites.net/tables/TodoItem
ZUMO-API-VERSION: 3.0.0
If you get a 500 error, then you know the problem is in your backend code. The next step is to look at server side logs and/or debug your service.
If you are using authentication, you can use the same authentication token that your mobile client sent. Look for the header X-ZUMO-AUTH or Authorization and use the same header and value in your REST client request.
To see streaming logs as you have failed requests, turn on streaming logs for your mobile backend. In the Azure portal, go to Settings -> Diagnostic Logs and turn on Application Logging (Filesystem). Note that this setting turns itself off after 12 hours to minimize the effect on site performance.
To view the logs, go to Tools -> Log Stream. Alternatively, you can go to your Kudu site from Tools -> Kudu. Kudu will also show you detailed information about your site, such as environment variables and running processes.
To learn more about logging options, see Enable diagnostics logging for web apps in Azure App Service.
If logging doesn't help isolate the source of the problem, you can attach a debugger to your service. This is not recommended for production services, since it has a big impact on site performance.
First, try reproducing the problem when running the service locally in IIS Express. Make sure your connection strings in your appsettings.json match what you have in the Azure portal. If you are running your mobile client on a different machine than your IIS Express instance, see instructions below on how to use Fiddler to open up your service on your network.
If the problem doesn't reproduce locally, you can remote debug your service. First, redeploy your site using a Debug build, so that the symbols are present. Then, in Visual Studio right-click on your site in Cloud Explorer or Server Explorer, and select Attach Debugger. When you have finished debugging, use the debugger stop button to detach the debugger. For more on remote debugging, see Troubleshoot an app in Azure App Service using Visual Studio.
If you're using an iOS simulator, you can't run your server on the same machine as your mobile client. By default, IIS Express does not open ports that can be accessed by other machines, but you can use Fiddler to allow these requests.
For an iOS simulator, follow the guide Configure Fiddler for Mac, since the simulator inherits network settings from the host Mac. If you're using an iOS device, see Capture Traffic from iOS Device. For Android, see Configure Fiddler for Android.
If none of the above steps help you track down the problem, feel free to ask for help! Post a question on either StackOverflow or Discussion Forums and tap into the group of volunteers who support this product!