Back in March, we announced Azure App Service, which includes the preview of Mobile Apps, a new version of the existing Mobile Services product. Mobile Apps makes it easy for developers to leverage great App Service features to build scalable and feature-rich backends which are easy to consume from mobile devices.

Today, I’m pleased to announce an update to the Mobile Apps .NET Server SDK. We took a good look at our SDK and the customer feedback around it, and we’ve been hard at work revising it. With this update, there are a few breaking changes, so we have incremented the minor version number, and we are now at version 0.2.549. Please note that the major version is still zero as the SDK remains in preview.

Our original SDK was fairly aggressive in taking over the ASP.NET pipeline and modifying configuration settings. This was a problem for advanced users, and it meant that certain features such as ASP.NET MVC could not be used, a huge limitation to developers of hybrid web and mobile applications. The major goal of this update was to make the SDK compose well with any ASP.NET site, and we’ve also given developers a lot more control in how the site runs.

Using the .NET server SDK

Probably the easiest way to get started with the new SDK is to download a quickstart project from the Azure Management Preview Portal. Try one of the Create a Mobile App tutorials which will walk you through those steps. Or just install the latest Microsoft.Azure.Mobile.Server NuGet package into any ASP.NET site.

You only need a little bit of code to get started with the Mobile Apps Server SDK. In WebApiConfig.cs, typically you get an HttpConfiguration object passed into the Register() method. If that object is called “config,” then I just need to add the following to the start of that method:

new MobileAppConfiguration()
 .ApplyTo(config);

This gets things started, but it doesn’t actually enable any of the cool mobile features. We opted to decompose the packages a little bit so that you have more control over what gets brought in, and what features you enable. The following is the dependency graph for the Server SDK packages.

If you want to get started quickly, you can just grab the Quickstart package and it will pull in the others. It also provides a UseDefaultConfiguration() extension method for MobileAppConfiguration which sets everything up similarly to earlier versions of the SDK. You can use it like this:

new MobileAppConfiguration()
 .UseDefaultConfiguration()
 .ApplyTo(config);

And just like that, you have a fully-featured mobile backend ready for your next great app.

Alternatively, you can call the underlying methods individually, and you can remove any of the ones you don’t need.

new MobileAppConfiguration()
 .AddMobileAppHomeController()             // from the Home package
 .MapApiControllers()
 .AddTables(                               // from the Tables package
  new MobileAppTableConfiguration()
   .MapTableControllers()
   .AddEntityFramework()     // from the Entity package
  )
 .AddAppServiceAuthentication()            // from the Authentication package
 .AddPushNotifications()                   // from the Notifications package
 .MapLegacyCrossDomainController()         // from the CrossDomain package
 .ApplyTo(config);

What else has changed?

In terms of functional changes, the first is as I described above – features now need to be enabled explicitly. In general, we are no longer making assumptions about desired behavior. This has led to changes such as removing our dependency on Autofac. You can now use any dependency injection framework you choose.

One major difference that folks will notice is that there is no longer an [AuthorizeLevel] attribute, and instead we ask users to decorate their controllers with the standard ASP.NET [Authorize] attribute. We also no longer assume Application Key protection for APIs by default, and in fact the Application Key and Master Key are no longer used by the SDK. This is important to note for customers switching between SDK versions.

Another change in this release is that ApiControllers are not, by default, mapped to any route or given any mobile-specific configuration. This allows you to use your own non-mobile ApiControllers alongside mobile-specific ApiControllers. To designate an ApiController as a mobile controller, specify the [MobileAppController] attribute on your class.

Other than those items, the SDK should feel fairly familiar to existing customers. There is a lot more that you can accomplish with Mobile Apps now, and we look forward to seeing what you build!

Please give the new SDK a try, and be sure to send us your feedback in the comments, forums, or on Twitter ( @AzureMobile). We always love hearing your thoughts!

Enjoy!