Comment exposer une application WCF RIA Services à d’autres clients : la migration vers Azure (5/5)

Nous allons voir ici comment porter l’application vue dans les 4 articles précédents vers Windows Azure et SQL Azure. Il faudra gérer ainsi la migration de la base contenant les livres et les catégories mais aussi la base servant à l’authentification d’ASP.NET. Par ailleurs, il faudrait revoir la manière de gérer un peu le stockage car nous allons être hébergé potentiellement dans un environnement multi-instances.

Cet article est donc le dernier d’une série de 5:

1 – Revue de l’application initiale
2 – Exposition du service sous la forme d’un flux OData consommé par Excel puis par une application écrite avec WebMatrix
3 – Exposition du service en WCF “classique” pour une consommation depuis WPF puis depuis Windows Phone 7
4 – Exposition du service en JSON pour une consommation par une application HTML5/jQuery 
5 – Les étapes à suivre pour porter cette application vers Windows Azure et SQL Azure (cet article)

Cet article étant un peu plus long que les autres, voici un découpage via ce sommaire :

- C’est quoi Azure et comment avoir un compte ?
- Migration des données vers SQL Azure
- Administration des bases SQL Azure
- Utilisation de la base SQL Azure dans l’application RIA Services
- Connecter les Membership Providers d’ASP.NET vers SQL Azure
- Transférer l’exécution dans un WebRole Windows Azure
- Gestion des multi-instances pour l’écriture des images de profiles

C’est quoi Azure et comment avoir un compte ?

Windows Azure représente notre offre PaaS (Platform As A Service) vous permettant d’héberger votre solution dans nos datacenters en bénéficiant de tous les avantages d’une plateforme de Cloud Computing : élasticité, géolocalisation, infrastructure gérée pour vous, etc. Si vous souhaitez comprendre en moins de 5 minutes ce que c’est, rendez-vous sur notre centre de développement Azure et regardez la petite vidéo en haut à gauche. Si vous souhaitez aller plus loin, nous avons un coach MSDN sur Windows Azure à votre disposition.

Pour le compte, si vous êtes abonné MSDN, vous bénéficiez d’avantages particuliers décrits ici : https://msdn.microsoft.com/fr-fr/subscriptions/ee461076.aspx .

Cependant, si vous souhaitez tester Windows Azure pendant quelques heures, gratuitement et sans devoir utiliser la moindre carte bleue, voici le lien qu’il vous faut : https://www.microsoft.com/france/windows-azure/tester/Azure-Demo-France.aspx . C’est en utilisant cette offre gratuite que je vais vous montrer comment déployer notre solution RIA Services dans les nuages. Bien entendu, les modifications et les étapes à suivre seront strictement équivalentes avec l’offre payante ou l’offre MSDN de Windows Azure.

Rendez-vous donc sur cette offre, créez vous un compte et vous arrivez sur cette page :

Cliquez sur “Réserver un environnement Azure” et choisissez votre lieu d’hébergement (restez en Europe si vous voulez avoir les serveurs pas loin de chez vous ) :

Cette opération va vous pré-provisionner un environnement d’exécution, de stockage Azure et une base de données SQL Azure. Vous aurez donc des clés d’accès valides pendant 24h.

Cela correspond à cette partie du portail complet Windows Azure : https://windows.azure.com qui a récemment été entièrement refait en Silverlight :

Migration des données vers SQL Azure

SQL Azure étant particulièrement proche de SQL Server 2008, il va être très simple de migrer nos données dans le cloud. Récupérez les informations de connexion dans l’onglet “Votre base de données SQL Azure”:

Cela correspond à cette partie du portail complet :

Si vous utilisez votre propre base SQL Azure en dehors de cette offre gratuite, n’oubliez pas alors d’ajouter des règles au Firewall pour vous permettre d’accéder à la base depuis votre machine ou depuis le réseau de votre entreprise. En effet, du point de vue sécurité, SQL Azure est configuré par défaut pour n’être attaqué que depuis les machines de Windows Azure. Vous pouvez donc ajouter une règle avec une plage spécifique d’adresses IP pouvant accéder également à la base. Pour verrouiller à nouveau l’ensemble, vous pouvez d’ailleurs très bien ensuite enlever cette règle une fois la maintenance terminée et que tout fonctionne bien en production.

Très bien. La première étape va être de transférer le schéma ainsi que les données vers notre base SQL Azure. Pour cela, nous allons utiliser un outil magique appelé SQL Azure Migration Wizard que vous pouvez télécharger ici : https://sqlazuremw.codeplex.com/ . Ce dernier va analyser votre base locale (tables, vues, procédure stockées, etc.) et vous faire un rapport avant de transférer l’ensemble vers la version Cloud de SQL Server : SQL Azure.

La 1ère étape consiste donc à ajouter la base de données BookClub.mdf que nous utilisons depuis le début au sein de votre instance locale de SQL. Ensuite, il n’y a plus qu’à suivre ces étapes assez évidentes.

1 – Lancez l’outil et choisissez de faire une analyse et une migration d’une base de données :

2 – Connectez vous à votre instance SQL (ici mon instance locale SQL Express) :

3 – Choisissez la base que vous souhaitez vaporiser dans le cloud (ici BOOKCLUB) :

4 – Faites “Suivant” jusqu’à cet écran et dîtes “Oui” :

5 – Vous devriez alors avoir ce type de résultat :

C’est là où vous verrez s’il y a des petits trucs qui coincent pour migrer vos données vers SQL Azure. Les 2 environnements sont en effet proches mais il y a quand même parfois quelques subtilités à résoudre avant de pouvoir faire la migration. Dans notre cas, notre base de données BookClub ne pose aucun problème.

6 – Faites “Suivant” pour donner les détails de votre instance SQL Azure :

Les informations à rentrer doivent l’être selon le format suivant :

Server name: nomdevotreserveurSQLAzure.database.windows.net
User name: userid@nomdevotreserveurSQLAzure

N’oubliez pas non plus d’indiquer le nom de la base de données à impacter de l’autre côté.

7 – Vous arriverez alors sur cette fenêtre vous demandant de confirmer l’exécution du script de migration :

8 – Si tout se passe bien, voici le type de fenêtre qui vous obtiendrez :

Et voilà ! Vos données sont dans le cloud ! Simple, n’est ce pas ?

Administration des bases SQL Azure

Il y a 3 façons de se connecter à l’instance SQL Azure et vous ne devriez pas être dépaysé si vous avez l’habitude de travailler avec SQL Server.

Visual Studio 2010

Si vous êtes développeur, vous pouvez utiliser le “Server Explorer” de Visual Studio 2010 puis ajoutez une nouvelle connexion vers une base :

Puis entrez les informations telles que nous les avons déjà vues avec l’outil de migration :

Vous verrez alors apparaitre les tables, vues & co comme d’habitude dans Visual Studio :

SQL Server Management Studio 2008 R2

Si vous avez plus une âme de DBA ou des besoins différents de ceux proposés par Visual Studio, vous pouvez utiliser la console d’administration de SQL Server : SQL Server Management Studio 2008 R2. En effet, à partir de la version 2008 R2, vous pouvez vous connecter sans souci sur une base SQL Azure.

Rentrez les informations sur le nom du serveur, le login et mot de passe ici :

Et n’oubliez pas de préciser de vous connecter directement sur une base particulière ici :

Uniquement si vous utilisez la version gratuite pendant 24h car vous n’avez alors pas accès la base master. Vous verrez alors bien apparaitre la base SQL Azure comme les autres :

Et vous pouvez alors effectuer vos requêtes habituelles :

Microsoft Database Manager for SQL Azure

Pour finir, il y a une 3ème manière d’accéder à nos bases SQL Azure en utilisant une application Silverlight nommée Microsoft Database Manager for SQL Azure disponible en ligne ici : https://manage-db3.sql.azure.com/ lancée lorsque vous cliquez sur le bouton “Manage” de la console d’administration Azure :

Cette application ressemble à cela :

Et vous pouvez même exécuter quelques requêtes à l’intérieur :

Note : c’est donc la 3ème application Silverlight que nous voyons depuis le début : 1 pour gérer votre compte gratuit 24h, 1 pour le portail d’administration “officiel” de Windows Azure et celle-ci pour gérer votre base de données SQL Azure. Qui a donc encore des doutes sur l’investissement de Microsoft sur Silverlight ?

Si vous désirez en savoir un peu plus sur le sujet, je vous invite à lire la documentation MSDN : Guidelines for Connecting to SQL Azure Database

Utilisation de la base SQL Azure dans l’application RIA Services

Bon, maintenant que nous avons nos données dans le nuage, il faudrait peut-être demander à notre application de s’y connecter. Bah, c’est franchement l’enfance de l’art ! Il suffit de se rendre dans le fichier web.config et de changer la chaine de connexion initiale :

 <add name="BookClubEntities" 
 connectionString="metadata=res://*/Models.BookClubModel.csdl|res://*/Models.BookClubModel.ssdl|
                   res://*/Models.BookClubModel.msl;provider=System.Data.SqlClient;
                   provider connection string=&quot;Data Source=.\SQLEXPRESS;AttachDbFilename=|
                   DataDirectory|\BookClub.mdf;Integrated Security=True;User Instance=True;
                   MultipleActiveResultSets=True&quot;" 
providerName="System.Data.EntityClient" />

Par celle-ci (à changer bien sûr en fonction de votre propre serveur SQL Azure) :

 <add name="BookClubEntities" 
 connectionString="metadata=res://*/Models.BookClubModel.csdl|res://*/Models.BookClubModel.ssdl|
                   res://*/Models.BookClubModel.msl;provider=System.Data.SqlClient;
                   provider connection string=&quot;Server=tcp:hytws52d6b.database.windows.net;
                   Database=DB1548;User ID=usr1ht74;Password=ryv@Je24;
                   Trusted_Connection=False;Encrypt=True;&quot;" 
providerName="System.Data.EntityClient" />

Et le tour est joué ! C’est fini pour les données. Nous n’avons rien touché au reste de la logique de notre application. Notre modèle Entity Framework se branche désormais sur notre base SQL Azure et l’ensemble est totalement transparent pour le reste de notre application et de nos clients Silverlight 4, Windows Phone 7, WPF et HTML5.

Connecter les Membership Providers d’ASP.NET vers SQL Azure

Il nous reste une dépendance vers une base de données locale : l’authentification ASP.NET par formulaire (FBA) reposant sur la base cachée ASPNETDB.MDF. Il va donc falloir recréer son pendant dans notre base SQL Azure et changer le fichier web.config pour lui demander d’aller se connecter vers Azure pour l’authentification, la gestion des profiles, etc. au lieu d’utiliser la base locale.

Pour créer la version Azure de la structure contenue dans ASPNETDB, il existe un article de notre base de connaissances : KB2006191 Updated ASP.net scripts for use with Microsoft SQL Azure donnant les étapes à suivre.

Il faut tout d’abord récupérer les scripts ici : Updated ASP.NET scripts for use with SQL Azure puis les exécuter sur la base SQL Azure cible avec SQL Server Management Studio 2008 R2 par exemple. 2 choix s’offrent ensuite à vous : soit vous créez une base ASPNETDB sur votre serveur SQL Azure soit vous insérez les tables et toute la logique nécessaire dans la même base servant à vos données. Je conseille plutôt de séparer les rôles mais comme nous n’avons pas le choix avec l’offre gratuite, nous allons utiliser la même base.

Connectez-vous donc sur la base qui vous est donnée au début puis exécutez ces scripts dans l’ordre : InstallCommon.sql, InstallMembership.sql, InstallPersonalization.sql, InstallProfile.sql, InstallRoles.sql puis InstallWebEventSqlProvider.sql. Si vous créez l’ensemble dans une base séparée, exécutez InstallAzure.sql sur la base master pour créer la base aspnetdb puis connectez-y vous pour exécuter les scripts précédents.

Si vous faites alors un “Refresh” à la fin de l’exécution de tous ces scripts, vous devriez bien voir l’ensemble des tables aspnet_*.

Maintenant, il va falloir indiquer le changement dans le fichier web.config . Tout d’abord, rendez-vous dans la partie <connectionStrings> et ajoutez cela au tout début :

 <remove name="LocalSqlServer"/>
<add name="aspnetdbEntities" 
 connectionString="Server=tcp:hytws52d6b.database.windows.net;
                   Database=DB1548;User ID=usr1ht74;Password=ryv@Je24;
                   Trusted_Connection=False;Encrypt=True;" />

Vous utiliserez donc ici la même chaine de connexion que pour le modèle Entity Framework. Ensuite, il faut déclarer notre nouveau membership provider. Pour cela, rendez-vous juste en-dessous de </profile> et ajoutez ce bloc :

 <membership defaultProvider="aspnetdbEntities">
  <providers>
    <remove name="AspNetSqlMembershipProvider" />
    <add name="aspnetdbEntities"
          type="System.Web.Security.SqlMembershipProvider, System.Web, 
                Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
          connectionStringName="aspnetdbEntities"
          enablePasswordRetrieval="false"
          enablePasswordReset="true"
          requiresQuestionAndAnswer="true"
          applicationName="BookClub"
          requiresUniqueEmail="false"
          passwordFormat="Hashed"
          maxInvalidPasswordAttempts="5"
          minRequiredPasswordLength="7"
          minRequiredNonalphanumericCharacters="1"
          passwordAttemptWindow="10"
          passwordStrengthRegularExpression=""/>
  </providers>
</membership>

Ensuite, il faut également changer le role manager. Pour cela, remplacez ce bloc :

 <roleManager enabled="true" />

Par celui :

 <roleManager enabled="true" defaultProvider="aspnetdbEntities">
  <providers>
    <clear/>
    <add name="aspnetdbEntities" type="System.Web.Security.SqlRoleProvider" 
         connectionStringName="aspnetdbEntities" applicationName="BookClub"/>
  </providers>
</roleManager>

Pour finir, il faut également changer le profile manager. Pour cela, remplacez ce bloc :

 <profile>
  <properties>
    <add name="FriendlyName" />
    <add name="PictureURL"/>
  </properties>
</profile>

Par celui :

 <profile defaultProvider="aspnetdbEntities">
  <providers>
    <clear/>
    <add name="aspnetdbEntities" type="System.Web.Profile.SqlProfileProvider" 
         connectionStringName="aspnetdbEntities" applicationName="BookClub"/>
  </providers>
  <properties>        
    <add name="FriendlyName" />
    <add name="PictureURL"/>
  </properties>
</profile>

Et nous en avons terminé. Vous pouvez désormais utiliser l’application RIA Services sans aucune dépendance sur une base de données locale. Toute la logique vers nos bases de données est désormais branchée vers SQL Azure dans le cloud.

Transférer l’exécution dans un WebRole Windows Azure

Jusqu’à présent, nous avons uniquement déporté notre base de données dans les nuages. Regardons maintenant comme héberger notre solution dans Windows Azure.

Avant toute chose, il vous faut avoir installé le SDK et les outils Windows Azure pour Visual Studio ici : https://go.microsoft.com/fwlink/?LinkID=206204

Note : il semblerait que notre offre gratuite française ne fonctionne pour l’instant qu’avec le SDK 1.2 de Windows Azure. Si vous testez avec le SDK 1.3 (le plus récent à ce jour), vous aurez un problème lors de la phase finale de déploiement dans le portail gratuit. Donc si vous souhaitez tester l’offre gratuite, téléchargez et installez la version 1.2 du SDK et des outils pour Visual Studio.

Une fois les outils Azure installés, ré-ouvrez notre solution BookShelf en tant qu’administrateur puis suivez ces étapes.

1 – Ajoutez un nouveau projet de type “Windows Azure Project” et nommez le “BookClubCloudService”

2 – Sur l’assistant suivant, n’ajoutez rien et faites “OK”. Au sein du nouveau projet ajouté, faites bouton droit sur le répertoire “Roles”, puis demandez à ajouter un Web Role actuellement présent dans la solution :

Et choisissez le projet hébergeant notre solution RIA Services : BookShelf.Web.

3 – Double-cliquez sur le nouveau rôle ajouté pour entrer dans le panneau de configuration de votre instance Windows Azure. Choisissez le nombre d’instances à faire tourner ainsi que la taille (ici par exemple 1 petite instance de type “Small”) :

Si vous avez installé le SDK 1.3 (pour tester sur le portail officiel Windows Azure), cliquez ensuite sur les “…” pour entrer les informations sur votre stockage Azure :

Si vous avez installé le SDK 1.2 (pour le portail gratuit), rendez-vous dans le fichier ServiceConfiguration.cscfg et changez le ConfigurationSettings avec celui-ci :

 <Setting name="DiagnosticsConnectionString" 
         value="DefaultEndpointsProtocol=https;AccountName=1st74;
         AccountKey=i4VdSeuQolbT2VOy8U9W7WjXYh0U63Rf8pq0AKdpo1s8SaZu3AY1A9xZhSCy89WWxVE9+cXKWyruLxB09RSxgQ==" />

de manière à pointer sur le stockage Azure même pour les informations de diagnostique.

4 – Avant d’envisager le déploiement, il nous reste une petit chose à faire. WCF RIA Services repose sur le .NET Framework 4.0 bien présent dans les machines virtuelles de Windows Azure. Cependant, le framework WCF RIA Services n’y est pas installé par défaut. Il faut donc embarquer les DLLs associées dans le package de déploiement. Pour cela, faites bouton droit sur une assembly et vérifiez bien que la propriété “Copy Local” est à “True” pour toutes les DLLs externes et non natives au .NET Framework 4.0.

Dans notre cas, voici la liste des DLLs à modifier :

-
System.ServiceModel.DomainServices.EntityFramework
-
System.ServiceModel.DomainServices.Hosting
-
System.ServiceModel.DomainServices.Hosting.OData
-
System.ServiceModel.DomainServices.Server
- Microsoft.ServiceModel.DomainServices.Hosting

5 – Vous êtes désormais prêt à déployer votre application dans Azure. Pour cela, faites bouton droit sur le projet Azure “BookClubCloudService” puis “Publish” puis retenez l’option “Create Service Package Only”.

Note : depuis la version 1.2 du SDK de Windows Azure, on peut désormais déployer directement depuis Visual Studio 2010 vers les instances Windows Azure en pré-production ou en production. Pour cela, il faut générer un certificat par Visual Studio et le faire utiliser par le portail Azure. Vous trouverez la procédure à suivre ici : Using Visual Studio to Deploy Applications. Cela ne prends que quelques minutes mais vous en fera ensuite gagner de nombreuses !

Une fois le package de déploiement créé, un explorateur de fichiers sera ouvert au bon endroit.

Retournez sur le portail d’administration du test gratuit d’Azure et cliquez sur “Déployer votre application”. On vous demande alors 2 choses : le package et le fichier de configuration que vous trouverez dans l’explorateur de fichiers qui vient de s’ouvrir.

Une fois les 2 fichiers sélectionnés, cliquez sur “Déployer”. Vous verrez alors les étapes suivantes s’enchainer :

- Upload du package (téléchargement des 2 fichiers de votre machine vers Windows Azure)

- Déploiement en cours

Vous arriverez alors à cet écran affichant d’abord “InProgress” ensuite “Initializing” puis “Busy” avant d’arriver à “Ready”.

Et voilà, vous avez suivi toutes les étapes pour déployer une solution complète WCF RIA Services dans Windows Azure et SQL Azure.

Gestion des multi-instances pour l’écriture des images de profiles

Si vous déployez cette application sur 1 seule instance, vous aurez peut-être l’impression que tout roule. Cependant, il nous reste une ultime étape pour correctement supporter l’architecture de Windows Azure.

En effet, lorsque l’on génère une image via la webcam, on l’envoie ensuite sur la couche serveur ASP.NET qui l’écrit directement sur le disque sous le répertoire \UserPictures. Cela pose problème dans une architecture multi-instances. Imaginons que nous ayons 2 instances en production. Si l’utilisateur arrive d’abord que la 1ère instance, se créé un compte via l’application Silverlight, l’image fournie sera enregistrée localement à cette 1ère instance. Si l’utilisateur arrive ensuite plus tard sur la 2ème instance puis se relogue, son image ne sera pas retrouvée puisqu’elle n’a pas été dupliquée sur l’ensemble des instances par magie.

J’en avais déjà parlé il y a quelque temps ici : Quels sont les impacts d’Azure sur le développement ?

Il faut alors déporter l’opération d’écriture vers un stockage centralisé, celui de Windows Azure. Il faut donc changer cette partie du code que j’avais décrite ici : Tutorial Silverlight 4: ajout d’une image dans le profile d’authentification utilisé par WCF RIA Services

La solution se trouve globalement dans le training kit de Windows Azure ici : Exercise 2: Working with Blobs

Voici les étapes :

1 – Rendez-vous dans les propriétés de notre Web Role Azure et ajoutez 2 nouvelles chaines de configuration en cliquant sur “Add Setting”. Nommez la 1ère “ContainerName” de type “string” avec la valeur “userpictures”.

Nommez la 2ème “DataConnectionString” de type “Connection String” puis cliquez sur les “…” pour entrer les informations de votre stockage Azure

En indiquant bien un accès en HTTP et non en SSL.

2 – Pour manipuler le stockage Azure et mieux préparer notre Web Role, ajoutez une référence aux 3 DLLs suivante :

- Microsoft.WindowsAzure.Diagnostics

- Microsoft.WindowsAzure.ServiceRuntime

- Microsoft.WindowsAzure.StorageClient.dll

Surement présentes ici : “C:\Program Files\Windows Azure SDK\v1.2\ref”

3 – Ajoutez le fichier WebRole.cs suivant à la racine de notre projet Web :

 using System.Linq;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.Diagnostics;
using Microsoft.WindowsAzure.ServiceRuntime;

namespace BookShelf
{
    public class WebRole : RoleEntryPoint
    {
        public override bool OnStart()
        {
            DiagnosticMonitor.Start("DiagnosticsConnectionString");

            // For information on handling configuration changes
            // see the MSDN topic at https://go.microsoft.com/fwlink/?LinkId=166357.
            RoleEnvironment.Changing += RoleEnvironmentChanging;

            // This code sets up a handler to update CloudStorageAccount instances when their corresponding
            // configuration settings change in the service configuration file.
            CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
            {
                // Provide the configSetter with the initial value
                configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

                RoleEnvironment.Changed += (s, arg) =>
                {
                    if (arg.Changes.OfType<RoleEnvironmentConfigurationSettingChange>()
                        .Any((change) => (change.ConfigurationSettingName == configName)))
                    {
                        // The corresponding configuration setting has changed, propagate the value
                        if (!configSetter(RoleEnvironment.GetConfigurationSettingValue(configName)))
                        {
                            // In this case, the change to the storage account credentials in the
                            // service configuration is significant enough that the role needs to be
                            // recycled in order to use the latest settings. (for example, the 
                            // endpoint has changed)
                            RoleEnvironment.RequestRecycle();
                        }
                    }
                };
            });

            return base.OnStart();
        }

        private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)
        {
            // If a configuration setting is changing
            if (e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange))
            {
                // Set e.Cancel to true to restart this role instance
                e.Cancel = true;
            }
        }
    }
}

4 – Ajoutez le code suivant dans la classe UserRegistration.cs :

 private void EnsureContainerExists()
{
    var container = GetContainer();
    container.CreateIfNotExist();

    var permissions = container.GetPermissions();
    permissions.PublicAccess = BlobContainerPublicAccessType.Container;
    container.SetPermissions(permissions);
}

private CloudBlobContainer GetContainer()
{
    // Get a handle on account, create a blob storage client and get container proxy
    var account = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
    var client = account.CreateCloudBlobClient();

    return client.GetContainerReference(RoleEnvironment.GetConfigurationSettingValue("ContainerName"));
}

private Uri SaveImage(string name, string contentType, byte[] data)
{
    // Create a blob in container and upload image bytes to it
    var blob = this.GetContainer().GetBlobReference(name);
    blob.Properties.ContentType = contentType;
    blob.UploadByteArray(data);
    return blob.Uri;
}

Et modifiez cette partie de la la méthode GetPictureUrl() :

 string path = HttpContext.Current.Server.MapPath("~/UserPictures");
string filePath = path + "/" + userName + ".jpg";
FileStream pictureStream = new FileStream(filePath, FileMode.Create);

pictureStream.Write(imageToSave, 0, imageToSave.Length);
pictureStream.Close();

pictureUrl = ConstructUri("UserPictures/" + userName + ".jpg");

Par celle-ci :

 pictureUrl = SaveImage(userName + ".jpg", "image/jpeg", imageToSave);

Nous avons donc fait tout ce boulot pour remplacer ce code à base de FileStream qui allait écrire directement sur le stockage d’une instance.

Pour finir, faites un appel à la méthode EnsureContainerExists() dans la méthode CreateUser() afin de vous assurer que le container précisé dans le fichier de configuration a bien été créé avant de tenter de l’utiliser pour y transférer nos photos de profiles.

Voilà ! Nous écrivons donc bien désormais les photos dans un stockage centralisé et indépendant de chacune des instances. Nous avons donc mis au point une architecture qui pourra bénéficier de l’augmentation du nombre d’instances sans problème. Vous pouvez tester à nouveau l’ensemble des clients Silverlight, Windows Phone 7, WPF et HTML5. Ils afficheront bien la photo en provenance du stockage Azure. Ce fut totalement transparent pour eux.

Voici le code source correspondant à la globalité de ces 5 articles :

Et cela conclue donc cette série. Merci de l’avoir suivi et bonnes fêtes de fin d’année !

David