When creating websites and applications it is one thing to make your application work in your development environment but it is another thing to make it work in the many integration environments that it will live in. An example, of this is a website that is developed locally, integration tested on a development box, tested in a QA environment, reviewed by a client in a staging environment, and pushed live to a production environment. 

All of these configurations require different database connection strings, email server addresses, and local file system locations for uploaded files. On top of these dynamic environment settings includes a Version Control system that most all of us use in our everyday life. I am sure everyone has accidentally checked in a web.config file that has a development connection string and it has caused problems in production. Secondly, it is a pain to manage these files in multiple environments by having to edit them on each server. Newer version of .NET have released the concept of the web.config.debug and web.config.release versions to mitigate this problem a bit but it really does not solve the problem for more than two environments.

Lastly, with the ability to write applications for the Windows Azure platform we want our applications to be easily tested locally and deployed to the cloud seamlessly. I want to be able to test my application locally on perhaps a local SQL database, but then when in the Cloud it should be connecting to a SQL Azure datasource and utilizing blob storage instead of file storage.

Cloud Construct has been using the concept of a dynamic configuration file for applications since we started writing web applications and standalone apps as well. The general concept is an XML driven file that contains settings that can be set for multiple environments that use an "endpoint" to resolve at application start the environment the application is running in. For example, in a web application project we will add some code to initialize our static Configuration class. The Configuration class will resolve the environment based on server endpoint and apply its settings to the object's properties. We can then access these properties from any place in our code.

Endpoints are resolved by server name and settings are pulled in the following order: 1. Global Settings 2. Environment Settings 3. Endpoint Settings. This allows global items to be applied to all environments when needed. Then environment specific settings will be applied. Lastly, any machine settings. Here is an example of this file:

config.xml (3.47 kb)

As you can see we have 3 specific environments:

1. Production, a single "Cloud" endpoint which resolves for the wildcard hostnames given in the cloud.

2. Staging, a single server endpoint.

3. Development, my local development machine endpoint and also my machine when it is in the local "Cloud" debugging mode. (It resolves Cloud endpoints over normal endpoints by checking to see if: RoleEnvironment.IsAvailable ? "cloud_endpoint" : "endpoint"

Each of these environments can have multiple endpoints as you can see so that if you have multiple servers in production they can all be resolved to that environment and possibly have their own settings on that machine. This file can be checked in easily to version control without causing problems in other environments accidentally and also limits all settings to a single file. Also I can take my applications and develop them in a way that in the future if clients want to expand to the cloud they can easily do so by just adding a cloud endpoint with its settings. For example, the EmailServer that uses SendGrid in the cloud or a local one when in staging:

if (CloudConstructConfig.Environment.IsInCloud)
{
   System.Net.NetworkCredential credentials = 

    new System.Net.NetworkCredential(CloudConstructConfig.EmailUsername, 

   CloudConstructConfig.EmailPassword);

   smtpClient.Credentials = credentials;
}

Above we are simply adding an extra credential when we are in the cloud to send emails. Otherwise the code is the same!

Sooo I am sure you want to know how do I get this code and integrate it right? Well here is the library: 

CloudConstructWebConfigurator_V1.0.zip (305.98 kb)

In order to integrate it into your application you can do the following:

1. Add a reference to CloudConstructWebConfigurator.dll in your project. (You can also add a reference to log4net dll as well for logging integration if you already are using it.)

2. Add a static class to your project that holds all of the settings configured in your XML file. This is the object you reference in code for your settings. (See the ClassLibrary1 project in the example integration zip below.)

3. Wire up your code in your global.asax.cs file to run on application startup and instantiate your static class.

4. Copy the Config directory into the App_Data directory.

Here is the link to the zip file of the example project utilizing the dynamic configuration library:

WebApplication1.zip (157.22 kb)

Important files to look at are the global.asax.cs, ClassLibrary1.CloudConstructConfig, and config.xml which drives the settings.

NOTE: It may be necessary to also add a reference to Microsoft.WindowsAzure.ServiceRuntime.dll if it does not exist on your system. It is provided with the zip file.

LOGGING INFORMATION:

If you utilize log4net you will get some great startup logging information:

2011-10-01 09:55:08,995 INFO  - *********************************

2011-10-01 09:55:09,005 INFO  -  Starting My WebApp

2011-10-01 09:55:09,005 INFO  - *********************************

2011-10-01 09:55:09,163 INFO  - Found host name to be: ARRA-CLOUD-PC.

2011-10-01 09:55:09,164 INFO  - Found 5 required items in the configuration file.

2011-10-01 09:55:09,164 INFO  - Found a global item list in the configuration file.

2011-10-01 09:55:09,167 INFO  - Processed Global file item: ContactEmailTemplate

2011-10-01 09:55:09,167 INFO  - Processed Global configuration item: EmailClientFooter

2011-10-01 09:55:09,168 INFO  - Processed Global flag item: DoCacheProfiles

2011-10-01 09:55:09,349 INFO  - Recognized environment as development, executing in normal context

2011-10-01 09:55:09,349 INFO  - Processed Environment database item: PrimaryDB

2011-10-01 09:55:09,349 INFO  - Processed Environment configuration item: EmailServer

2011-10-01 09:55:09,349 INFO  - Updated to Environment flag item: DoCacheProfiles

2011-10-01 09:55:09,349 INFO  - Matched host as ARRA-CLOUD-PC

2011-10-01 09:55:09,350 INFO  - Loaded 5 out of 5 required items.

2011-10-01 09:55:09,350 INFO  - No errors found when validating all configuration items.

2011-10-01 09:55:09,351 INFO  - Completed loading configuration file.

“The path is too long after being fully qualified.  Make sure the full path is less than 260 characters and the directory name is less than 248 characters.” was an error I kept getting after I added some new files to my Azure Web Role solution a few weeks ago. I was working on integrating a new design into the Boston Azure Group's website which runs on the Azure platform. The web role would not initialize in the development fabric and there was no diagnostic information at all to work from. I “googled” around for a bit and found some entries describing the path being too long, which was an error I received earlier but then it went away.

After pulling down fresh code and trying to deploy again to the dev App Fabric the problem persisted. I found a blog entry describing to change the environment variable _CSRUN_STATE_DIRECTORY to directory closer to the root because the path was too long during deployment. I tried this but it did not work. I gave up and then contact Bill Wilder who leads the Boston Azure group and he steered me towards another article describing to do the same thing but it specifically said to set a system environment variable and not a local environment variable. I find this strange but it must be because the deployment runs under a system account. IT WORKED!! Thanks Bill!

Here is the link to the article and some steps to fix this issue if it happens to you.

I attended a discussion tonight on Windows Azure and ASP.NET MVC with Azure. All around it was a great learning experience for someone who is so accustomed to building applications using ASP.NET and IIS. The main point I learned was that MVC is an alternate route to take when building websites rather than a replacement for ASP.NET form style development. MVC had some cool features like: 

• Ability to easily display the same data models using different views.
• Strongly typed objects being posted to a page that can easily be accessed.
• Enhanced security on literals being posted and displayed on a page.
• Built in validation including client side validation being synced with server side.
• SEO optimization built into URL's.