Fresh Updates to Azure Mobile Services .NET

Article
06/07/2014

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

Better SQL Azure database initializers,
Using local config settings, and
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:

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

ClearDatabaseSchemaAlways which can be dropped in for DropCreateDatabaseAlways
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:

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:

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:

Other Updates

Some additional fixes and features in this release include

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.
Added support for the portable HttpClient found in the Microsoft.Net.Http Nuget package.
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

Comments

Anonymous
June 06, 2014
Got the forwny yesterday during a deploy. :-( However thanks to the logs, was able to find the issue. i.e. You cannot use Autofac > 3.0.0 inside of WebApiConfig.Register(). Do not update to 3.4
Anonymous
June 07, 2014
Shayne, we'll update that for the next drop
Anonymous
June 08, 2014
The comment has been removed
Anonymous
June 08, 2014
Hi,Thanks for the article. I would like to ask you if you know when will we get single sign on for .Net backend. My application is ready to go and I don't want to publish ir in the Windows Store until I get this feature working.Thanks
Anonymous
June 08, 2014
Ilya, you are right that the new initializers are primarily useful for when you are initially building your app and don't have any real data in your database. Obviously you wouldn't want to delete important data :) There are already some blogs on the mapped domain manager, see for example this one: blogs.msdn.com/.../mapping-between-database-types-and-client-type-in-the-net-backend-using-automapper.aspx
Anonymous
June 09, 2014
Faical,If your target is Windows Store, you can actually get an SSO experience by setting an additional Boolean parameter in the LoginAsync method (see msdn.microsoft.com/.../microsoft.windowsazure.mobileservices.singlesignonextensions.loginasync.aspx). However, I suspect you are referring to the client-directed flows where you are using a provider SDK. We are working on opening up this scenario soon. Which login provider are you targeting?
Anonymous
June 09, 2014
I'm targetting Microsoft account but as soon as I add the singlesignon parameter and make it true. The screen at the login stays white after pushing the login button. I read in a forum That this feature is not yet implemented. Is this true?Thanks
Anonymous
June 09, 2014
Faical,It's a bug, which we'll fix :)Thanks,Henrik
Anonymous
June 10, 2014
Oh thanks a lot for your feedback. I was wondering if it was me that I'm doing something wrong :D .
Anonymous
July 05, 2014
Hi, how often is a mobile service recycled...? I would like to host a SignalR hub on my .NET Backend, will users be kicked-off in case of recycling ?Thank you.Best Regards.
Anonymous
July 09, 2014
The comment has been removed
Anonymous
November 22, 2015
Hi, My services is running fine locally but when i published, it give me "The Service is Unhealthy ". It give me error “ERROR Boot strapping failed: executing ‘WebApiConfig’ caused an exception: ‘Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.” Please Help me. Thanks..

Partager via