Fresh Updates to Azure Mobile Services .NET

  • Article

Today we are rolling out a new set of updates to Azure Mobile Services .NET including:

  1. Better SQL Azure database initializers,
  2. Using local config settings, and
  3. Detecting when the service is unhealthy.

Azure Mobile Services provide an easy way for building cloud connected mobile applications across any platform including iOS, Android, Windows Phone, Windows Store, etc. For a quick overview, check out this Microsoft Azure Mobile Services Overview from Microsoft DevRadio.

Btw, if you missed it then last week we rolled out real-time support which enables you to build real-time, bi-directional communications with your mobile applications, so do check that out as well.

Support for .NET is still in preview but we are pushing hard to make it as useful and painless experience as possible for building and running an awesome, cloud connected mobile app. Features you get out of the box include unified authentication, push notifications, real-time communications, flexible backend stores (SQL, Azure Table Store, Mongo, etc.), scheduled jobs, and much more. You develop & test your Mobile Service using Visual Studio and then deploy it to Azure where we check that it is running normally.

If you have questions, feedback or comments then reach us on StackOverflow or @frystyk on twitter.

Getting the Updates

As usual you can get the updates (version 1.0.303) from NuGet – go to the NuGet Package Manager in your Visual Studio project, select Updates, and type windowszure.mobileservices in the search window. It should look similar to this:

NuGetUpdate303

Install the updates and you are ready to go!

SQL Azure Database Initializers

One of the current pain points using Azure Mobile Services with SQL Azure is that the Mobile Service for security reasons only has permissions to access a particular data base schema and not the entire database. This means that the default Entity Framework database initializers don’t work as they rely on being able to drop the entire database which the user is not permitted to do.

In this update we added two new database initializers that work by just deleting database objects found within a particular schema making it much simpler during development to update your data models. The new initializers are

  1. ClearDatabaseSchemaAlways which can be dropped in for DropCreateDatabaseAlways
  2. ClearDatabaseSchemaIfModelChanges which can be dropped in for DropCreateDatabaseIfModelChanges

and to use them you simply drop them in where you currently use the existing database initializers, for example:

    1: public class henrikntest09Initializer : ClearDatabaseSchemaIfModelChanges<henrikntest09Context> 
    2: {
    3:     protected override void Seed(henrikntest09Context context)
    4:     {
    5:         List<TodoItem> todoItems = new List<TodoItem>
    6:         {
    7:             new TodoItem { Id = "1", Text = "First item", Complete = false },
    8:             new TodoItem { Id = "2", Text = "Second item", Complete = false },
    9:         };
   10:  
   11:         foreach (TodoItem todoItem in todoItems)
   12:         {
   13:             context.Set<TodoItem>().Add(todoItem);
   14:         }
   15:  
   16:         base.Seed(context);
   17:     }
   18: }

Note: The database initializers delete your data model and data so only use them when you don’t have data you want to preserve. As soon as you want to modify existing data then you have to use Entity Framework Migrations instead.

Using Local Config Settings

Azure Mobile Services is a hosted service which means that we continuously monitor the health of your service and detect issues where we can. This means that when you deploy a Mobile Service, it is deployed into a hosting environment which we run and maintain. You can configure your service running within this environment through the Azure Portal as well as through the code you write (see Making it Yours: Configuring Mobile Services .NET Backend).

In addition, we have now added support for configuring your service directly using your deployed web.config file by importing application settings and connection strings from the deployed web.config file into the hosted environment. The way it works is that the portal gets first dips on the settings and then any application settings and connection strings that haven’t already been set are added from the deployed web.config file.

Not only can you now include your own app settings and connection strings directly but you can also control settings for configuring notification hub, or the identity providers directly from your web.config file without having to go through the portal. For example, instead of configuring identity settings through the portal, you can just set the application settings in the web.config file – if not set in the portal then these values will be active:

    1: <add key="MS_MicrosoftClientID" value="Specify value here or in portal" />
    2: <add key="MS_MicrosoftClientSecret" value="Specify value here or in portal" />
    3: <add key="MS_FacebookAppID" value="Specify value here or in portal" />
    4: <add key="MS_FacebookAppSecret" value="Specify value here or in portal" />
    5: <add key="MS_GoogleClientID" value="Specify value here or in portal" />
    6: <add key="MS_GoogleClientSecret" value="Specify value here or in portal" />
    7: <add key="MS_TwitterConsumerKey" value="Specify value here or in portal" />
    8: <add key="MS_TwitterConsumerSecret" value="Specify value here or in portal" />
    9: <add key="MS_AadClientID" value="Specify value here or in portal" />
   10: <add key="MS_AadTenants" value="Specify value here or in portal" />

Unhealthy Sites – Say Hello To Frowny

When you deploy a service into a hosted environment, you want an easy way to know whether you deployment is healthy and working as expected. Now, when you deploy a site, we immediately give you an indication of problems by showing you a sad frowny:

Frowny

To see what the issue is directly in Visual Studio, use the Service Explorer and go under the Azure tab, then Mobile Services, then right click on your service and select View Logs:

VsLogs

That will give you the logs explaining what is wrong and how to correct it. When the service is healthy again, you will see a smily instead of the frowny :)

You can also get the health information of a service programmatically by sending a request to the /status endpoint:

StatusEndpoint

Other Updates

Some additional fixes and features in this release include

  1. Wired up OWIN logging to the user logs so now you will also see logs from the various OWIN middleware directly in your user logs.
  2. Added support for the portable HttpClient found in the Microsoft.Net.Http Nuget package.
  3. Fixed regression in Azure Storage Table Data Model where system properties that already mapped to Table Storage columns were still mapped to their own columns.

Have fun!

Henrik