Voici l’essentiel de l’épisode 137 du Cloud Cover Show paru il y a quelques semaines.

Dans cet épisode, Nick Harris, Chris Risner et Yavor Georgiev (Program Manager dans l’équipe Azure Mobile Services) nous présentent le support de .NET dans Azure Mobile Services.

 

Le support de .NET pour Azure Mobile Services a longtemps été la demande la plus populaire sur le UserVoice de l’équipe. Il devrait donc répondre aux attentes de beaucoup d’entre vous.

L’épisode commence directement par la création d’un nouveau service à partir de 0:48. On constate que c’est lors de cette première étape qu’il faut activer le support de .NET à la place de JavaScript grâce à une nouvelle liste déroulante. Cette option est en Preview actuellement et devrait être disponible en production dans les 6 mois environ. Elle vous permet d’utiliser les langages C# ou VB.Net pour créer le backend de vos applications mobiles, en bénéficiant des nombreuses fonctionnalités d’Azure Mobile Services (stockage des données, exécution de la logique métier, authentification facilitée, notifications pushs, …).

Une fois créé, l’interface dans le portail est très similaire avec un tenant Azure Mobile Services utilisant Javascript. L’une des différences est le fait que la solution exemple Quick Start contient à la fois le projet Visual Studio client (pour votre application mobile) et le projet Visual Studio serveur (pour le backend). L’autre différence majeure est l’absence de l’onget “Données” et “APIs personnalisées” car ces parties sont gérées par code dans le projet Visual Studio serveur.

A 2:10, Yavor ouvre une parenthèse en expliquant que l’intégration du service Azure Notification Hub dans Azure Mobile Services pour remplacer l’ancienne implémentation a commencée il y a quelque temps, et que c’est cette option qui est activée par défaut lorsqu’on choisit .NET. L’ancienne implémentation est toujours activée par défaut lorsqu’on choisit JavaScript mais à terme, il n’en restera qu’une.

A 2:45, la solution Visual Studio est ouverte, pour constater le découpage entre le projet client (projet Windows 8.1 ici) et le projet serveur contenant le code du backend. Ce dernier projet utilise le package Nuget WindowsAzure.MobileServices.Backend (ainsi que des “sous-packages” correspondant à des fournisseurs de données), qui contient le cœur du service et vous permet notamment de faire tourner votre serveur localement pour vos besoins de développement et de tests. A vous l’intelisense, le debugging, et autres joies du développement sous Visual Studio.
Yavor insiste également sur le fait que d’autres packages Nuget faisant références sont utilisés et que l’un des principes de conception des équipes était de ne pas réinventer la roue (ASP.Net Web API principalement, Owin, AutoMapper et même Mango si vous souhaitez utiliser Mango pour stocker vos données).

Après avoir lancée le serveur localement (un simple F5 dans Visual Studio), il est possible d’accéder aux pages d’aide et de tests de votre service (04:38) que connaissent surement déjà les développeurs ASP.Net Web API.

Au début de la 7e minute, il est temps de publier le projet serveur sur Azure, de manière assez similaire à la publication d’une application web dans Azure Web Sites, c’est à dire en passant par un fichier .PublishSettings que vous pouvez récupérer sur le portail, dans le tableau de bord de votre service.

Pour ceux qui veulent tout savoir de l’environnement d’exécution de la version .NET de Mobile Services, Nick et Yavor échangent sur le sujet à partir de 08:05. On y apprend que c’est version un peu différente du Runtime Mobile Services qui tourne en production sur le même environnement qu’Azure Web Sites, principalement pour des raisons de sécurité (pages d’aide désactivées par défaut, chaines de connexion spécifiques, possibilité pour Microsoft de mettre à jour le runtime en production sans que vous ayez besoin de republier votre projet, …).

Les fonctionnalités et caractéristiques suivantes sont ensuite détaillées dans la deuxième partie de la vidéo :

  • A 09:30, le remote debugging est utilisé, pour utiliser Visual Studio afin de debugger votre service déployé sur Azure
  • A 13:30, la structure du projet serveur est détaillée, ainsi que l’architecture permettant l’abstraction de la méthode de stockage des données (Entity Framework, Table Storage, MongoDB, …)
    Vous constaterez que l’ensemble est très proche d’un projet ASP.Net Web API et que les notions de TableController, de Data et de DomainManager sont les seules spécifiques à Azure Mobile Services.
  • A 16:07, le scénario de la réutilisation d’un modèle Entity Framework existant est présenté.
    A noter que l’API cliente Mobile Service est volontairement très simple et ne comprend pas la notion de relation entre entités. Le Framework AutoMapper est donc utilisé pour faire comprendre cette notion de relation à Mobile Services. Dans ce cas, c’est le DomainManager de type ExistingDomainManager qui doit être utilisé et non le EntityDomainManager réservé aux projets utilisant un nouveau modèle Entity Framework.
  • A 21:01, Yavor présente l’utilisation d’un modèle NoSQL utilisant MangoDB (Azure Table Storage est une autre alternative).
  • A 23:51, le sujet de l’authentification OAuth est traité.
    Concernant l’authentification, il est intéressant de constater que les niveaux d’autorisation sont traités par attribut sur les méthodes concernées du controller (attribut RequiresAuthorization et énumération AuthorizationLevel), tandis que les paramètres d’authentification (configuration de l’authentification via compte Facebook ou Microsoft par exemple) sont configurés directement au niveau de votre tenant Azure Mobile Services.
  • A 28:16, c’est au tour du sujet des notifications Push d’être abordé
    Yavor en profite pour faire un point sur l’objet de type APIServices, récupéré par injection de dépendances qui est utilisé notamment pour accéder aux fonctionnalité de Push.

 

Si vous souhaitez tester cela par vous-mêmes et que vous n’avez pas encore de compte Windows Azure ni d’abonnement MSDN, ouvrez un compte de test gratuit, vous obtiendrez 150 € de ressources pendant 1 mois.

Vous trouverez ci-après quelques images de l’épisode.

Benjamin (@benjiiim)

image

Début de l’épisode, avec Yavor Georgiev, Program Manager dans l’équipe Azure Mobile Services.

image

Sélection de l’option .NET lors de la création d’un nouveau tenant Azure Mobile Services

image

Azure Mobile Services dans le portail Microsoft Azure

image

Intégration de Azure Notification Hub dans Azure Mobile Service

image

Solution Visual Studio exemple et ses deux projets : le client et le serveur

image

Packages Nuget utilisés dans le projet exemple

image

Essayez de jouer avec le Smiley sur la landing-page de votre Mobile Service pouvant maintenant s’exécuter en local

image

Page de test d’une méthode de l’API vous évitant de sortir Fiddler ou PostMan

image

Lancement du projet client pour tests via l’application

image

Import des paramètres de publication grâce au fichier .PublishSettings

image

Sélection de la configuration Debug pour pouvoir utiliser plus tard le Debug à distance

image

Configuration du Remote Debugger

image

Utilisation des bons paramètres de connexion dans le projet client pour ne plus utiliser la version locale.

image

Preuve du Remote Debugging en explorant les variables d’environnement contenant différentes chaines de connexion que seul le serveur connait

image

Projet Visual Studio plus complexe pour le scénario de la réutilisation d’un modèle Entity Framework existant

image

Configuration de AutoMapper dans le fichier WebApiConfig.cs

image

Utilisation du MongoDomainManager pour stocker les données dans MongoDB au lieu de SQL Database

image

Configuration du niveau d’autorisation grâce à l’attribut RequiresAuthorization et de l’énumération AuthorizationLevel

image

Pour tester l’authentification en local, il est nécessaire de renseigner les clés correspondantes à la configuration des fournisseurs d’identité utilisés dans le Web.config. Ces valeurs seront remplacées automatiquement par la configuration de votre tenant Azure Mobile Services une fois votre code publié.

image

Conclusion du show avec un peu de pub pour le compte Twitter de Yavor