Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Scope
This article has the goal to show how to create a development and production environment for a .Net Backend from Azure Mobile Services.
Introduction
From the MSDN Documentation,
Microsoft Azure Mobile Services is an Azure service offering designed to make it easy to create highly-functional mobile apps using Azure. Mobile Services brings together a set of Azure services that enable backend capabilities for your apps. Mobile Services provides the following backend capabilities in Azure to support your apps:
- Client libraries support mobile app development on various devices, including Windows 8, Windows Phone 8, iPhone, and iPad.
- Simple provisioning and management of tables for storing app data.
- Integration with notification services to deliver push notifications to your app.
- Integration with well-known identity providers for authentication.
- Precise control for authorizing access to tables.
- Supports scripts to inject business logic into data access operations.
- Integration with other cloud services.
- Supports the ability to scale a mobile service instance.
- Service monitoring and logging.
Azure Mobile Services is great for mobile application development with client libraries for both Apple and Microsoft mobile platforms.
There are various scenarios where one requires multiple environments for an Azure Mobile Service.
These include:
- Breaking changes between published versions of an app.
- Different configurations for test and production.
Different environments are necessary in order to have different configurations for a given Azure Mobile Service. Azure Mobile Services allows testing in localhost, but do not provide a way to have different environments.
Description
To create a development and production environment for a .Net Backend - Azure Mobile Services is required to create a Dev and Prod Backend and then is possible to create the Dev and Prod profiles based on transform files.
Let’s see it in more detail.
Creating the Azure Mobile Services
In Azure Portal, create two .Net Backend - Azure Mobile Service, let’s call it as following
- For the development environment:
- MyAMSDev – the Azure Mobile Service name
- MyAMSDev_db – the database name
- For the production environment:
- MyAMSProd – the Azure Mobile Service name
- MyAMSProd_db – the database name
In Azure Portal, the result will be http://s23.postimg.org/xky0bul4r/ams1.png
And
http://s23.postimg.org/61jprqut7/ams2.png
Is possible to use the same database, but it is necessary to use different schemas and if different databases are provided is easier to manage each environment (update or even delete). A Backend that uses Entity Framework migrations will recreate the service from the scraps and with it any time it can be deleted, deployed and recreated.
To read more about the steps required to create an Azure Mobile Service, read the following article
How to create the MyMenuApp Azure Mobile Service.
Creating a Transform File
In Visual Studio, select the solution and open the context menu as following
http://s23.postimg.org/hka0cmcmz/ams3.png
After it, click in Configuration Manager as following
http://s23.postimg.org/8hgxruni3/ams4.png
And then create a new configuration as following
http://s23.postimg.org/r8iv20i2j/ams5.png
http://s23.postimg.org/ybvbvdcvv/ams6.png
In this case, a Dev configuration is defined based on Debug configuration and to the Prod configuration should be used the Release configuration as following
http://s23.postimg.org/z57xnziwr/ams7.png
At this moment, is possible to define Debug, Dev, Prod and Release configuration
http://s23.postimg.org/xfyufx37f/ams8.png
For each configuration is possible to define the conditional compilation. For example, in Dev is possible to have
http://s23.postimg.org/9stae28hn/ams9.png
In reality, it means, we can do
#if Dev
// for example can fill the database with fake data
#else
// in another environment different from Dev
#endif
To have advantages of this configuration using the Web.Config, let’s add the config transform as following
http://s23.postimg.org/qzuh3kk1n/ams10.png
Which the result will be
http://s23.postimg.org/ggpw0nrzv/ams11.png
Now is possible
- To set in the Web.Config, the connection string to the local database, used by the localhost
<connectionStrings>
<add name="MS_TableConnectionString1" connectionString="Data Source=LT114925;Initial Catalog=MyAMSLocal;Integrated Security=True;MultipleActiveResultSets=true" providerName="System.Data.SqlClient" />
</connectionStrings>
- To set in the Web.Dev.Config, the connection string to the MyAMSDev_db database, used by the Dev environment (or even the localhost!)
<connectionStrings>
<add name="MS_TableConnectionString1"
connectionString="<connection string from MyAMSDev_db>"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
- To set in the Web.Prod.Config, the connection string to the MyAMSProd_db database, used by the Prod environment
<connectionStrings>
<add name="MS_TableConnectionString1"
connectionString="<connection string from MyAMSProd_db>"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
And in each deploy, the respective configs will be used.
Let’s publish the service to the Azure.
Select the project and using the context menu click in Publish, as following
http://s23.postimg.org/t88nkwr5n/ams12.png
Then connect to Azure Mobile Service, using the Azure Account, and select the MyAMSDev as following
http://s23.postimg.org/r7dimc5mj/ams13.png
In Settings, set the configuration and the file publish options (only!)
http://s23.postimg.org/kw8b5x4e3/ams14.png
And then publish it!
Do the same process to Prod, as following
http://s23.postimg.org/d4w6l3pmj/ams15.png
And then publish it!
Is possible to see the Web Publish Activity that shows the publish process
http://s20.postimg.org/vhisyflct/ams16.jpg
At this moment, both environments are deployed and running and are not required to define or change each environment in the future, only is needed to have attended each one is set before deploy.
Notes
-
- In this case, was using the MS_TableConnectionString1 name for defining the connection string and the default value MS_TableConnectionString, defined in Azure Portal, will be ignored.
A developer can to set different connect string or even change the name, but needs to be defined with the same name in all environments.
- With the Visual Studio 2013 – update 4 is possible to change the database in Settings separator but in this case, it will be ignored!
For more information about the transform file, read the following article
How to: Transform Web.config When Deploying a Web Application Project
Conclusion
In conclusion, creating different environments for a .Net Backend – Azure Mobile Service is an easy task that is a plus in the development, which allow testing new features before it goes to production and it allows to make sure the tests done in localhost will keep working in the Azure Mobile Service without to affect the production environment.