This post was co-authored by Matthew Henderson.
 

We’re happy to announce the latest updates to the .NET Server SDK for Azure Mobile Apps. If you haven’t already seen it, we recommend you check out last month’s blog post, where we outlined the integrated web and mobile experiences.

This month, we have some new updates in version 0.2.575 of the .NET Server SDK: 

• (New!) Support for Azure Table Storage
• (Breaking change) Removed automatic OWIN setup for better integration with ASP.NET
• (Breaking change) Improvements to authentication middleware setup
• (Breaking change) Better defaults for database schema setup
• (Breaking change) Clients no longer need to request system properties, they are sent by default

The easiest way to get started is to install the Microsoft.Azure.Mobile.Server.Quickstart NuGet package, which brings in the other dependencies. You can also just pull in specific Microsoft.Azure.Mobile.Server.* packages you need.

Azure Storage

You can now use Azure Table Storage as a backing data provider for your TableControllers through the new Microsoft.Azure.Mobile.Server.Storage package.

To connect to Storage, add the following to the Initialize() method of your TableController:

DomainManager = new StorageDomainManager(connectionStringName, tableName, Request);

Here, connectionStringName is the app setting key for your Storage connection string, and tableName is the name of the table you want to access. This is often just the name of the controller: controllerContext.ControllerDescriptor.ControllerName.ToLowerInvariant().

The StorageDomainManager works a little differently than the EntityDomainManager, and it implements a different subset of the TableController helper methods. Namely, your TableController “get” methods should look similar to the following:

public Task> GetAllTodoItems(ODataQueryOptions queryOptions)
{
    return QueryAsync(queryOptions);
}

public Task> GetTodoItem(string id)
{
    return LookupAsync(id);
}

The Mobile Apps client SDKs all work with this Table Storage domain manager. However, currently the iOS client does not support offline sync against a table controller using the StorageDomainManager.

OWIN startup

The .NET server SDK has a few uses of OWIN middleware. The Microsoft.Azure.Mobile.Quickstart package formerly contained an OWIN startup class which would wire some of the components together for you.

While this was convenient, it was also hard to customize the behavior and it couldn’t be easily integrated into existing apps. The Quickstart package no longer contains this startup class. This is a breaking change.

To upgrade from an older version of the Quickstart package, you need to add a new Startup class and move your configuration there:

1. In Visual Studio, right click on your project and select Add -> New Item. Select Web -> General -> OWIN Startup class. 
2. Move the code for MobileAppConfiguration from WebApiConfig.Register() to the Configuration() method of your new startup class. If you are creating a new HttpConfiguration rather than the global one passed in by Global.asax, call app.UseWebApi(config) at the end of the method.

Alternatively, use the server quickstart project from the Azure Portal as starting point for your project.

OWIN middleware

We’ve improved the authentication experience in this update. All of our auth components are now in their own OWIN middleware! Not only does this give more control to developers, but now the Mobile App authentication components can be integrated with any ASP.NET app type, including SignalR routes.

This is a breaking change: the method MobileAppConfiguration.AddAppServiceAuthentication() has been removed and is no longer necessary.

To use authentication, you only need the following call in your OWIN startup class:

app.UseMobileAppAuthentication(config);

Here, config is either the global HttpConfiguration or whichever one you are using for Web API OWIN self-host. To learn more about authentication setup, see the documentation topic How to: Add authentication to a server project.

Database schema

Previously, the .NET Server SDK used the mobile app name as the default schema name in the Entity Framework setup. We heard from customers that this wasn’t a very useful default, since they often wanted to use either dbo or a custom schema name.

Now, the .NET Server SDK Quickstart uses the same default schema name as Entity Framework, dbo. If you want to use a different schema name, specify it in your DbContext.OnModelCreating() implementation:

modelBuilder.HasDefaultSchema(schema); // specify the schema string 

As part of this change, we have removed the method MobileAppSettingsDictionary.GetSchemaName(), which would use the app setting MS_TableSchema (if present) or MS_MobileServiceName (otherwise).

(Note: The class ServiceSettingsDictionary was renamed to MobileAppSettingsDictionary in the last set of server SDK updates.)

This is a breaking change. If you are using the method GetSchemaName(), make the following changes:

// string schema = MobileAppSettingsDictionary.GetSchemaName(); // method removed

// ensure you have an app setting for MS_MobileServiceName
string schema = System.Configuration.ConfigurationManager.AppSettings.Get("MS_MobileServiceName"); 

Note: The Quickstart project no longer adds a setting for MS_MobileServiceName to your web.config. We recommend you create your own key for a schema name and specify it either in your web.config or in the App Settings blade in the Azure Portal.

System properties

Previously, the system properties of __createdAt, __updatedAt, __version, and __deleted would only be sent to the client if the query __systemProperties=* were sent to the server. In Mobile Services, this behavior was necessary for backward compatibility, but it made it difficult to test and develop client SDKs.

With this new release, the query string __systemProperties is ignored and the service will always return these system properties. When using a $select to retrieve particular columns, simply add system properties to this clause. If there's no $select specified, all properties will be returned, including system properties.

This is a breaking change. The client SDKs will behave the same in the majority of cases, but there are two cases to be aware of:

• On iOS and the JavaScript client, if the online table APIs are used, Update and Delete operations will send the __version field back to the server by default. If you do not want conflict handling support for simultaneous updates (optimistic concurrency), then you should remove this field from your client object before doing the update. The offline sync APIs are not affected.
• On any client, if a query includes both $select and __systemProperties, only the system properties in the $select clause will be returned. The query should be changed to include the desired system properties in the $select clause.

Mobile Apps is still in preview, but we hope you'll try things out! Please let us know what you think in the comments, MSDN forums or @AzureMobile. If you have suggestions for something you’d like to see in the product, let us know on our feedback site.

We'll continue to post any changes to the SDK and will also include them in the .NET server SDK changelog.