Pour ceux qui comme moi travaillent avec Windows Azure et aiment garder la flexibilité de leur environnement de développement, staging et production, voici ma façon de travailler pour me simplifier la vie:
Web.config transformations:
Depuis Visual Studio 2010, l’on peut utiliser des transformations XML du fichier web.config, afin d’obtenir des versions différentes de la solution Web que l’on soit en Debug ou en Release.
Exemple simple de gestion du SessionState:
Dans le fichier Web.Debug.config:
<sessionState xdt:Transform="Replace" mode="InProc" />
Dans le fichier Web.Release.config:
<sessionState xdt:Transform="Replace"
mode="SQLServer" allowCustomSqlDatabase="true"
sqlConnectionString="Server=tcp:mysqlserver.database.windows.net;Database=MyDB;User ID=admin;Password=password;Trusted_Connection=False;Encrypt=True; MultipleActiveResultSets=True;" />
On peut aussi faire la même chose avec la connection à la base de données utiliser par Entity Framework:
Dans ce cas juste un petit changement; le fichier Web.Debug.config ne contiendra pas la connection SQL, mais ce sera le fichier principal Web.config.
En effet, les transformations ne s’appliquent que lors de la publication du projet. Il vaut mieux garder ces valeurs dans le Web.config pour pouvoir débugger en local !! 
Dans le fichier Web.config:
<add name="RMOPEntities" connectionString="metadata=res://*/Data.RMOP.csdl|res://*/Data.RMOP.ssdl|res://*/Data.RMOP.msl;provider=System.Data.SqlClient;provider connection string="data source=ariel.ctp-int.com\galatea;initial catalog=RMOP;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
Dans le fichier Web.Release.config (pour transformer l’entrée pour le package Azure à déployer):
<add name="RMOPEntities"
connectionString="metadata=res://*/Data.RMOP.csdl|res://*/Data.RMOP.ssdl|res://*/Data.RMOP.msl;provider=System.Data.SqlClient;provider connection string="data source=wyopqjbi6s.database.windows.net;initial catalog=RMOP;;User ID=ctpadmin;Password=pass@word1;multipleactiveresultsets=True;App=EntityFramework""
providerName="System.Data.EntityClient" />
Conditional Symbols utilisé à la compilation:
vous connaissez surement la notation « #if DEBUG » pour ne compiler une portion de code que si le symbole « DEBUG » est défimi sur le projet.
Vous pouvez aussi créer vos propres symboles puis les utiliser dans votre code.
Exemple de définition ci-dessous dans votre projet:
Dans ce cas, j’utilise ce symbole pour pouvoir bypasser la section de long pour tester mon application.
Vérifier si vous êtes VRAIMENT sur Azure:
Dans certains cas, on n’a pas forcément besoin d’exécuter la totalité du projet, même dans la DevFabric.
Pour éviter cela, on peut alors débugger son application en tant que Web App standard et retourner des « Dummy Data » pour tester son application plus rapidement.
Un exemple simple ici:
if (RoleEnvironment.IsAvailable)
{
return AzureBlobMaganer.GetDataItems();
}
else
{
return new List<DataItem>() {new DataItem() {Label = "Test", Value = 12}};
}
Config Items in Roles:
Le dernier point ici est d’utiliser le contexte dans lequel est l’application pour pouvoir récupérer la connexion au Azure Storage qui correspond : DevFavric ou Azure ?
Voici un exemple des entrées dans un fichier de Service Configuration:
La solution la plus Simple est:
#if DEBUG
var account = CloudStorageAccount.FromConfigurationSetting("StorageDev");
#else
var account = CloudStorageAccount.FromConfigurationSetting("Storage");
#endif
Une solution plus élégante serait d’encapsuler cela dans une mèthode pour récupérer le Sorage Account correspondant.
Merci de votre lecture, et n’hésitez pas à me laisser un commentaire
