Hi everyone,
For those of you who are working with Windows Azure and looking for flexibility in their different environments, here are a couple of points I have been using during my projects to help being flexible and fast.
Web.config transformations:
Since Visual Studio 2010, one can use XML transformations on web.config, to help getting different file versions when you build your app in Debug or in Release.
Here is a small example on how to do it for the SessionState:
In file Web.Debug.config:
<sessionState xdt:Transform="Replace" mode="InProc" />
In file 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;" />
You can then do the same for the DB connection you use to you SQL Azure back end when using Entity Framework.
The problem here is that transformations only apply to “built” config files (stored in bin or debug folders), so this doesn’t apply when debbuging locally your Web project!!
To do this, leave DEV related entries in the Web.config directly, so that transformations will only apply when building the Azure packages in Release using the Web.Release.config:
In file 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" />
In file Web.Release.config (to transform it when building package):
<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:
You certainly know already DEBUG and RELEASE constants (used with “#if DEBUG” in code).
You can also build you own, to address specific purposes; you can eevn build your own build configurations to include these conditional symbols or not.
Here is a sample of a Project properties set to use conditional symbols:
In that case I created a “NOAUTH” symbol to bypass user having to log in the application for debug purposes.
Verifying if you are REALLY in Azure:
In certain cases (e.g. layout modifications) , you are not forced to run your whole project using the DevFabric.
To avoid this you can just run the WebApp project, but of course you won’t be able to leverage anything from Azure APIs like Storage.
You can then do it using Dummy Data to return through your layers to test more rapidly your application and keep on having it to work without Azure.
A small sample here:
if (RoleEnvironment.IsAvailable)
{
return AzureBlobMaganer.GetDataItems();
}
else
{
return new List<DataItem>() {new DataItem() {Label = "Test", Value = 12}};
}
Config Items in Roles:
The last point here is to play a bit with Azure connections; which on will we connect to: DevFavric or Azure ?
Here is a sample of an Azure project configuration:
The simple solution here is:
#if DEBUG
var account = CloudStorageAccount.FromConfigurationSetting("StorageDev");
#else
var account = CloudStorageAccount.FromConfigurationSetting("Storage");
#endif
A clever way would be to encapsulate this in a method to return the right storage account, or even a static property set to different variables depending on constant definition:
#if DEBUG
public const string CloudAccountName = "StorageDev";
#else
public const string CloudAccountName = "Storage";
#endif
Thanks for reading, and don’t hesitate to give me feedback!
