Updating the Data Model with Azure Mobile Service

Updating the Data Model with Azure Mobile Service

Whilst template and samples are great, often one of the hardest things is adapting the code to your particular scenario. One such example is with Azure Mobile Service when you decide that you want to change your data model for the first time. Firstly, the initial template that you download and publish to get an initial service up and running will create a ToDoItems table. Unless you happen to be building a ToDo task system then it is unlikely that you’ll want this table. So, how do we get rid of this table out of our Azure Mobile Service (and of course the SQL Server database that backs it)?

At this point a word of caution – this table was created by the Mobile Service, so don’t go messing with the table directly. For example you could use SQL Management Studio to connect to the SQL Azure instance and just delete the table but I think you’ll find that you run into some issues when you next run or attempt to deploy new versions of your Mobile Service. In fact, the Mobile Service template already provides a facility to do that. In fact, with any change to the Entity Framework data model the entire database structure will be dropped and recreated. This makes it really easy to remove the ToDoItems table, simply by commenting out the following line in the RealEstateInspectorContext:

//public DbSet<TodoItem> TodoItems { get; set; }

All I need to do now is publish and invoke the Mobile Service – I can do this by either running the Windows/Windows Phone applications wired up in the previous post or I can invoke it using Fiddler, as I did in an earlier post. It’s important to invoke the Mobile Service (even though it will fail with a 500 internal error because that’s what triggers the database initializer to kick in and restructure the database).

The next thing we need to change is that we don’t want to be dropping and recreating the database each time the data structure changes – this is a sure fire way in production to delete all that great app data! In the WebApiConfig.cs file there is a line which specifies the initializer for the database. In the template I downloaded this was already set as follows:

Database.SetInitializer(new realestateinspectorInitializer());

The realestateinspectorInitializer inherits from the generic class, ClearDatabaseSchemaIfModelChanges, which as you can imagine from the name is designed to clear up and recreate the database schema if the model changes (for example the above where we dropped the ToDoItems table). I’m going to change this to prevent the database being recreated; I’m going to start to apply migrations as I deploy new versions of my Mobile Service.

Note: In order to create the migrations that need to be applied you can use the tooling provided by the Entity Framework NuGet package via the package manager console. However, before you do this, make sure you run your Mobile Service locally with the TodoItems table comments out (don’t forget to invoke the service – just change the url in Fiddler to use localhost:XXXX where XXXX is the port number your service is running at). This will ensure you have a clean database to work from.

The first thing to do is to invoke Enable-Migrations from the package manager console (full details of the commands are available online – http://msdn.microsoft.com/en-au/data/jj591621.aspx). This will create a Migrations folder with a Configuration class and an initial migration, which assuming you have removed the TodoItems table will contain two empty methods, Up and Down.

Note: Make sure the Mobile Service project is the startup project for the solution when attempting to use the package manager console for generating migrations.

To use the Configuration class and the associated migrations I need to replace the following line:

Database.SetInitializer(new realestateinspectorInitializer());


var migrator = new DbMigrator(new Configuration());

At this point you can run your Mobile Service but you will still see a 500 error since there is still no TodoItems table. In fact at this point we’re going to introduce a RealEstateProperty entity that we’ll be working with:

public class RealEstateProperty : EntityData
    public string Address { get; set; }

I need to add this to the realestateinspectorContext as follows:

public DbSet<RealEstateProperty> RealEstateProperties { get; set; }

At this point if I attempt to run the Mobile Service I’ll get an AutomaticMigrationsDisabledException and if I look further at the description it indicates that there are pending model changes that haven’t been applied to the database via a migration. Essentially it’s detected that my model doesn’t align with the database schema.

Rather than hand craft the migration, which would be time consuming and rather mundane, I can again return to the package manager console and issue the Add-Migration command:

Add-Migration AddingRealEstatePropertiesToSchema

The “AddingRealEstatePropertiesToSchema” is a friendly name for this migration and a date-time stamp will be appended to the front of the newly created migration file eg 201501051134554_AddingRealEstatePropertiesToSchema.cs. This command in itself doesn’t update the database schema, all it does is determine the migration that needs to take place. To update the local database I can either call Update-Database, or simply run and invoke the Mobile Service. However, to do the latter I need to add a RealEstatePropertyController which will be the endpoint I’ll be invoking – the easiest way to do this is to simply rename the TodoItemController to RealEstatePropertyController, and change the generic parameter from TodoItem (this class can now be deleted) to RealEstateProperty.

When I run this I can now test the service by invoking a GET to http://localhost:51539/tables/realestateproperty (you may need to change the port number for your Mobile Service) which will of course return no data at this point but it doesn’t generate a 500 which means that it has run the migrations and that the model is aligned with the database schema. I can now publish this into my Azure Mobile Service and make a similar GET request to http://realestateinspector.azure-mobile.net/tables/realestateproperty. Don’t forget that you’ll need the X-ZUMO-APPLICATION header when calling a Mobile Service in Azure, whereas it is not required when running the Mobile Service locally.

The last thing I wanted to point out is that you can easily add data by issuing a POST command (don’t forget the Content-Type header)

POST: http://realestateinspector.azure-mobile.net/tables/realestateproperty
X-ZUMO-APPLICATION: wpxaIplpeXtkn————————-cg12
Content-Type: application/json

{‘Address’:’123 Sample Avenure, Random City’}

This should generate a 201 response if successful with a JSON body similar to the following (viewed using the JSON pane in Fiddler)


My service is starting to feel like it is more realistic now, although very simplistic. I’ll need to extend this model quite a bit more and then update the applications to access the data from it.

Connecting Windows/Windows Phone Apps to Azure Mobile Service

Connecting Windows/Windows Phone Apps to Azure Mobile Service

In my previous post I created Windows and Windows Phone applications using the universal app template, and created and published a Mobile Service, The next step is to connect the apps to the Mobile Service using the Windows Azure Mobile Service NuGet package. In my solution I simply right-click on the solution node and select manage NuGet Packages. Locate the NuGet package by searching for “azure mobile service” and click Install next to the SDK package. Add the SDK to both Windows and Windows Phone projects but not the Service project.


Add a new file to the Shared project, MainPage.shared.cs and replace the MainPage class definition with the following:

public partial class MainPage
    public static MobileServiceClient MobileService = new MobileServiceClient(

    protected async override void OnNavigatedTo(NavigationEventArgs e)

        var items = await MobileService.GetTable<TodoItem>().ToListAsync();

public class TodoItem
    public string Id { get; set; }
    public string Text { get; set; }
    public bool Complete { get; set; }

I can run either the Windows or Windows Phone application and see that the items variable gets populated with the contents of the TodoItems table. Of course we need to switch out this table with one that is more applicable to the property inspector application I’m building but this demonstrates how easily you can retrieve data using the Azure Mobile Service SDK.

Creating Your Solution and Your Azure Mobile Service

Creating Your Solution and Your Azure Mobile Service

As I discussed in my initial post there are a number of components that make up the property inspection tool. In this post we’ll start by creating the initial solution structure, create and add in the Azure Mobile Service, and publish the Azure Mobile Service.

Initial Solution Structure

A lot of blog posts will start by creating the Azure Mobile Service and then use the template projects provided on the home page of the newly created Mobile Service. Sometimes this isn’t an option and you want to be able to integrate a Mobile Service into an existing application. For this reason I’m going to start with a new project creating Visual Studio using the Blank App Universal template.


This will create Windows and Windows Phone projects, with a Shared code project to handle files shared between the two applications.



Creating the Azure Mobile Service

The next step is to create the Azure Mobile Service. This can actually be done by right-clicking on the Mobile Services node in the Server Explorer window in Visual Studio but I’m going to have to go to the management portal to download the initial project for the Mobile Service anyhow. To create the Azure Mobile Service, navigate to the Azure Management Portal and select New >> Compute > Mobile Service > Create from the toolbar at the bottom of the screen. Complete the setup wizard – make sure you select the .NET backend.


After completing the setup wizard, a few moments later the new Mobile Service will be available. However, before I can use it I need to publish the set of services –  you can think of what I’ve done so far as just setting up a placeholder for where the services will live.

Publishing the Mobile Service

To publish the Mobile Service I expand out the Get Started section on the home page of my newly created Mobile Service, and click on the Download link. I save the downloaded zip file, unblock and then extract the zip file.


I then copy the service folder (in my case realestateinspectorservice) into the solution folder of the solution I created earlier. Back in Visual Studio I then add the existing realestateinspectorservice project into the solution.


Right-click on the services project and select Publish. Select Microsoft Azure Mobile Services as the publish target


At this point if you’re not already signed in, you’ll need to sign into you Azure subscription with your Microsoft Account in order to select the previously created Mobile Service:


After selecting the Mobile Service to publish to, click OK and then the Publish button. This will cause the project to be compiled (and any required NuGet packages to be downloaded) and then published up to the Mobile Service. This may take a few minutes the first time as all referenced libraries will have to be copied up. However, future publish operations will be significantly quicker as they are by default differential.

After publishing the Mobile Service I can test that it’s operational using Fiddler (or curl etc) to simulate a GET request. I need two pieces of information: firstly the url of the Mobile Service I created. This can be found either in the Output window of Visual Studio at the end of publishing the Mobile Service, or from the dashboard pane of the Mobile Service in the Azure portal. The second thing is that I need one of the two assigned access keys. This again comes from the Azure management portal by clicking on the Manage Access Keys button in the toolbar at the bottom of the page. This key needs to be added to the request as the X-ZUMO-APPLICATION header. The following images show the request and response samples





So this gets me part of the way through setting up my solution – the next thing to do is to connect the Windows and Windows Phone applications so that they can call out to the Mobile Service…..

Field Engineer Sample for Azure Mobile Services

Field Engineer Sample for Azure Mobile Services

Over on the Windows dev center there is a code sample, Field Engineer, which covers a good portion of the application scenario I painted in my previous post. I won’t be delving into the sample in too much detail but I did want to do a quick review of the solution structure so that you get an idea of what’s there and what I’ll be adding to my scenario that extends this sample.


The sample solution in made up of four projects and only offers a Windows application frontend (in contrast to my scenario where we want to support both native apps and a web frontend). The mobile services are in the Services project which has an accompanying Test project. The interesting thing about the test project is that it does raw httpclient calls to validate that the services work as expected, instead of using the Azure mobile service client wrapper classes. Lastly there is a Setup project which is simply a command line utility that is designed to assist in the setup of the Azure components required in order to run this sample.

I’d highly recommend downloading this sample, setup and run it (follow all the instructions otherwise it’s not likely to work), before we move onto exploring my scenario in the coming posts.

Mobile First, Cloud First and How it Applies to Line of Business Software

Mobile First, Cloud First and How it Applies to Line of Business Software

I’m going to start the year by dissecting a typical business scenario which will demonstrate how the use of Windows, Windows Phone and Azure can be plugged together to quickly deliver a line of business solution. Throw in a bit of Xamarin and a web front end and you have a solution that will enable employees to use any device they choose in order to access the software.

The first thing to cover is the scenario, which in this case is going to be a property inspection tool that could be used by a property manager to do periodic property inspections required under most rental agreements. At first glance this appears to be a tool that is specific for the real estate industry but as we’ll see there are a number of components that make it similar to any task, defect or issue tracking system:

– Property managers will have a number of properties assigned to them to manage
– Properties will have a history of inspections which may include images and/or videos
– Property information, and perhaps most recent inspection, needs to be available offline (just in case there is no internet inside a property being inspected)

– Inspections need to be able to be created, edited and submitted from a mobile device

This will probably do for the time being; as we go we may introduce other elements to demonstrate the use of various platform components. What’s interesting to note at this point is that properties can be switched out for projects, and inspections for tasks, if this scenario were a task/issue/defect tracking system.

At a high level let’s discuss the major components:

– Mobile devices – Naturally as .NET developers we gravitate to what’s easiest so we’ll include Windows and Windows Phone applications based on the universal app template which uses a shared code project to prompt reuse. However, we shouldn’t neglect the other platforms so we should include iOS and Android projects, using the Xamarin tooling. Our business logic we’ll abstract into a portable class library (PCL) to attempt to give us maximum reuse.

– Services – Azure Mobile Services will give us the raw scaffolding to stand up a SQL Server backend with services exposed to surface data to our mobile applications. These services support synchronisation which we’ll use to give the mobile applications offline support.

– Blobs – Azure Blob Storage will be used to store the images and videos collected as part of the solution. Whilst the service tier will be used to control access to Blog Storage (by issuing Shard Access Signatures) the upload will be done from the mobile applications directly into blob storage

– Authentication – As this is a line of business solution we’d prefer users to not have to remember another set of credentials. To this end the solution will use Azure Active Directory (AAD) to authenticate users and grant them access to the software. The users can be synchronised from the corporate AD into AAD so as to maintain a single set of credentials for any user.

– Web application – An Azure Website will be used to provide desktop and mobile solution for those unable to use the mobile applications. Whilst this could go directly to the SQL Server backend, it will in fact be routed via the service tier to ensure a common authentication pattern and usage model for the data.

– Scheduling – A scheduler will be setup in Azure for use by the solution in order to schedule particular jobs or operations to be carried out. For example the periodic generation and sending of reports.

– Push Notifications – When new data is available, push notifications can be sent out to the mobile applications to either alert the appropriate user, or perform a background synchronisation of the new data.

I’ll use this post as a reference for the components that I’ll be discussing in the coming posts. The components aren’t in any particular order and the posts won’t focus on individual components, rather how they connect together and what you need to know to get them to work together.

Demo rule #1 practice again and again and again, particularly the night before….

Demo rule #1 practice again and again and again, particularly the night before….

Tomorrow is round 2 of TechEd Australia and after my demos all seemed to go well in Melbourne I figured I was all set. However as I usually do I wanted to double check that everything was going to work (particularly since I’m running the Windows 10 preview build). Anyhow, it’s a good thing I did because the wonderful Azure team have changed the syntax of one of the manifest files I have to manually edit mid-way through my first session. The step I walk through is actually taken from a post over on Azure Mobile Services site (http://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-adal-sso-authentication/) and includes this change:


Well, no more – if you try to do this you’ll find that the appPermissions node doesn’t exist in the manifest file. Luckily I have a working mobile service with this change already applied, so I figured if I download the manifest file I should be able to see what’s changed. It turns out that the syntax has changed and that instead of replacing the appPermissions node, you now have to replace the oauth2Permissions node ie change:

“oauth2Permissions”: [],


“oauth2Permissions”: [
      “adminConsentDescription”: “Allow the application access to the mobile service”,
      “adminConsentDisplayName”: “Have full access to the mobile service”,
      “id”: “b69ee3c9-c40d-4f2a-ac80-961cd1534e40”,
      “isEnabled”: true,
      “origin”: “Application”,
      “type”: “User”,
      “userConsentDescription”: “Allow the application full access to the mobile service on your behalf”,
      “userConsentDisplayName”: “Have full access to the mobile service”,
      “value”: “user_impersonation”

The upshot of this is that had I just assumed that my demos would all just work tomorrow I would have been fighting this fire on stage (argh). Moral of the story is practice, practice and practice some more – you never know when the demo gods will strike, and it’s best to be prepared when they do.