Practical Development

Understanding Application Domains

Chris Clayton1 — Tue, 21 May 2013 16:57:00 GMT

When talking to long time .NET developers about application domains (AppDomains) they often understand the high level concepts but not necessarily how or why they would use them. My goal of this article is to help clarify some of the scenarios where AppDomains offer value and describe how to go about using them. In order to provide this information to readers of various levels of knowledge and interest I will flag certain areas as “In Memory”. By reading these sections they will provide you a greater understanding of what is happening behind the scenes for those of us that love detail but you will still understand the what, why and how if you skip these.

So what is an AppDomain? Simply put an AppDomain is a unit of isolation in the .NET CLI used to control the scope of execution and resource ownership.

When we look at threads it is important to understand that several threads can belong to a single AppDomain. This however does not mean that a thread is confined to that one AppDomain, rather it can only execute within a single AppDomain at any given time.

So why is this important? Suppose your “full trust” application needs to use an assembly that was dynamically generated, received from a less credible source or simply put has a significant level of risk associated with its execution? Would you not prefer to run it with a reduced set of “permissions”? Through the use of AppDomains you have the ability to do just that, execute the majority of your code in full trust while isolating the questionable assembly to another partially trusted AppDomain. In fact you can select from a set of well-known permissions or customize them as appropriate. Sometimes you will hear this approach referred to as sandboxing.

From another vantage point you will note that .NET draws a large number of framework elements and assemblies into the executing code as well as holding static and rooted objects until the AppDomain is unloaded. By executing these assemblies that consume large amounts of memory in another AppDomain you can release the memory when you are done with them by unloading the specific AppDomain without impacting the rest of your application. Obviously if you have objects in memory that you are holding with security sensitive contents the ability to clean them up sooner is often a great advantage.

What if my application has a requirement for a high degree of auditing? AppDomains expose some additional events that provide the ability to log the occurrence of or react to First Chance and Second Chance exceptions.

In short, I tend to look at introducing secondary AppDomains into my application when security, auditing or memory consumption concerns exist.

So this is great right? Why wouldn’t I always use AppDomains, in fact why does the .NET framework not automatically put the AppDomain structure around all of my calls to external resources? Well like all good things there is a down side. Simply put the creation and unloading of an AppDomain has a performance cost and is not something you want to do constantly. To control the performance impact it is often better to create the AppDomain, run the iterations of your code in that AppDomain and when appropriate unload the AppDomain.

Anyone that has knowledge of Win32 development or operating system principals may be saying “wait a minute, isn’t the process the unit resource ownership? Well this is correct from an operating system point of view, but the operating system has no knowledge of the Common Language Runtime (CLR), in fact it is just another COM server to it. When the CLR is initialized it will create the Default AppDomain (named the same as the entry point assembly) used to hold all of the resources and scope code execution to that unless the code explicitly makes use of secondary AppDomains.

Considerations when making use of AppDomains for security are:

Set the application base to an appropriate directory, typically not the same as the host AppDomain. The AppDomain’s application base is the directory that will be used as the root when resolving assembly references. Due to this use there may be scenarios where permissions are implied based on its location (ex. Internet, intranet etc.)
You have the ability to pass in a list of strong named assemblies that can be loaded by the AppDomain as full trust. Consider using this list verses putting them in the GAC. Placing an assembly in the GAC allows all AppDomains to execute it as “Full Trust”.
Grant the minimum permissions possible that still allow the assembly to execute.
If there is a set of standard permissions that match your requirements of your executing assembly leverage them instead of defining your own (ex. SecurityManager.GetStandardSandbox).
Variations in Type resolution can be setup in different AppDomains by implementing the TypeResolve event handler. This event is fired when the CLR cannot determine the assembly that contains the specified Type. Using this event handler you can return the Assembly from the location of your choice.

Considerations when making use of AppDomains for Memory Usage:

Multiple AppDomains in the same process that leverage the same DLLs (assemblies) will map to the same code space in the processes memory. This often eases the concern of some developers about base image footprints.
If the assembly being loaded into the AppDomain contains many or large static objects or properties it may inflate the size of your process when you create it and or impact performance. The reason for this ties back to the fact that static elements are associated with the AppDomain not the process and multiple AppDomains with the same assembly will hold multiple static versions of static objects.

Considerations when making use of AppDomains for Auditing:

There are times when an application will terminate unexpectedly as a result of an unhandled exception. This type of exception is known as an Unhandled Exception and can occur due to code defects and environmental changes. In building an application that must strictly audit all system events and activities it may be desirable to log what has happened to cause the termination. Through the implementation of the UnhandledException event handler you are notified prior to the application terminating in this situation. In the event handler you can audit and or take corrective action such as storing state or firing out additional diagnostics structures.
Implementation of the ProcessExit event handler will provide the consumer with up to two seconds to take the appropriate actions including state persistence and logging when the process is requested to shut down.

Now that we understand the why and when of AppDomains let’s look at them in a little more detail. In my first example we will assume that I have decided to leverage an existing DLL that one of my colleagues built for another system. I have been made painfully aware that it has a built in caching algorithm which seems to consume a lot of memory. In my particular scenario I need to call a single method in the library many times in a row over the period of 15 minutes to support my batch processing. After the batch processing is complete I do not need it again until the next evening. So let’s look at a simulation of this scenario.

The library that I am using is comprised of two classes:

The cached object holds the state of the transaction etc. The payload size of the state information is large for demonstration reasons but in a typical scenario would be smaller with higher object volumes.

namespace DemoLibrary
{
using System;

    internal sealed class MyCachedObject
    {
        private static Random generator = new Random();
        private byte[] processedData;

        public MyCachedObject()
        {
            processedData = newbyte[generator.Next(25, 70) * 1024];
        }

        public int Execute(int id)
        {
            return processedData.Length;
        }
    }
}

There is a central class called the Processor that manages the cached objects, holding existing instances to maximize reuse and reduce both start-up and processing time. This is a simple cache handled by the id of the object. In the output message it will return the application domain name.

namespace DemoLibrary
{
using System;
using System.Collections.Generic;

    public class Processor
    {
        private static readonly Dictionary<int, MyCachedObject> myCache = new Dictionary<int, MyCachedObject>();

        public string ProcessRequest(int id)
        {
            if (!myCache.ContainsKey(id))
            {
                myCache.Add(id, newMyCachedObject());
            }

int cacheSize = myCache[id].Execute(id);

return string.Format("This is a response message from id {0} with a cache size of {1} in the AppDomain named: {2}", id, cacheSize, AppDomain.CurrentDomain.FriendlyName);

}

For future examples the library above will not change, only the console application. When referring to the library it implies the two classes outlined above.

To simulate the application that is consuming the memory I will use a console application that waits after the processing is complete so I can inspect the memory.

namespace AppDomainDemo
{
    using System;
    using System.Diagnostics;
    using DemoLibrary;

    class Program
    {
        staticvoid Main(string[] args)
        {
            ProcessRequestBatch();

// Only added to force a collection for demonstration purposes, please do not do this in production
// inducing a GC is typically not good a good practice

GC.Collect();

     Console.WriteLine("Completed the batch press enter to continue");
            Console.ReadLine();
        }

     private static void ProcessRequestBatch()
        {
            Stopwatch watch = new Stopwatch();
            Processor demoProcessor = new Processor();

watch.Start();

            for (int index = 0; index < 10000; index++)
            {
                int id = index % 5000;

Console.WriteLine(demoProcessor.ProcessRequest(id));
}

watch.Stop();

            Console.WriteLine("The processing took {0} ms to complete.", watch.ElapsedMilliseconds);
        }
    }
}

Now that we have setup the simulation and the code has been explained we will look at the results and memory footprint to understand what is happening behind the scenes.

Reviewing the console output we can see that the job took 2156ms to complete all of the iterations. Also note that all of the responses came from the AppDomainDemo.exe, this is the default AppDomain associated with my application which is named AppDomainDemo.exe. Typically this is referred to as the default AppDomain.

By reviewing the Task Manager we can see that the process has increased in memory consumption and is holding onto 240.4MB of memory. A significant portion of this memory consumption can be attributed to the cached objects (we only know this because we know the code at this point) even though the instance of the Processor has dropped out of scope.

So why is it holding this memory, the library dropped out of scope did it not? We are not using it anymore, are we? In order to answer this we will turn to WinDBG (http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx). The contents of the WinDBG logs have been shorted and you will notice ‘…’ in places where I have removed unnecessary information.

In Memory

Review the statistics of the heap so we can understand what objects are consuming space:

0:003> !DumpHeap -stat

Statistics:

MT Count TotalSize Class Name

000007ff491113d8 1 24 System.Int64

...

000007ff490ff0a8 11 50748 System.Int32[]

000007feea935070 5000 120000 DemoLibrary.MyCachedObject

000007ff490ff108 7088 170112 System.Int32

000007ff490e0630 3569 234560 System.Object[]

000007feea936168 2 299280 System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[DemoLibrary.MyCachedObject, DemoLibrary]][]

000007ff490fd5e0 3551 866340 System.Char[]

000007ff490fc358 14348 1326108 System.String

00000010a61ab330 5059 3818824 Free

000007ff491004d0 5003 241150729 System.Byte[]

Total 43727 objects

Now that we noticed our object DemoLibrary.MyCachedObject is consuming a lot of space (120MB) with a count of 5000 instances we can look at why this is. We will dump out the heap entries for these objects and see each individual object’s address.

0:003> !DumpHeap -type DemoLibrary.MyCachedObject

Address MT Size

00000010a83c3130 000007feea935110 80

...

00000010b6d68958 000007feea935070 24

00000010b6d77c70 000007feea935070 24

00000010b6d84f88 000007feea935070 24

00000010b83c9638 000007feea936168 97200

00000010b83e11e8 000007feea936168 202080

Statistics:

MT Count TotalSize Class Name

000007feea935110 1 80 System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[DemoLibrary.MyCachedObject, DemoLibrary]]

000007feea935070 5000 120000 DemoLibrary.MyCachedObject

000007feea936168 2 299280 System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[DemoLibrary.MyCachedObject, DemoLibrary]][]

Total 5003 objects

We can now select one of these addresses and look at what AppDomain they are associated with.

0:003> !FindAppDomain 0x00000010b83e11e8

AppDomain: 00000010a61c2700

Name: AppDomainDemo.exe

ID: 1

Now that we know that our objects are directly associated with the AppDomain named AppDomainDemo.exe (Id 1) let’s see what other AppDomains are in the current process.

0:003> !DumpDomain

--------------------------------------

Domain 1: 00000010a61c2700

LowFrequencyHeap: 00000010a61c2eb8

HighFrequencyHeap: 00000010a61c2f40

StubHeap: 00000010a61c2fc8

Stage: OPEN

SecurityDescriptor: 00000010a61c4850

Name: AppDomainDemo.exe

Assembly: 00000010a61af170 [C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll]

…

What we can see from this is that there is only one AppDomain at the moment (beyond the shared) and will now inspect the object to see where its roots are.

0:003> !GCRoot 0x00000010b83e11e8

HandleTable:

00000010a61717d8 (pinned handle)

-> 00000010b83c5658 System.Object[]

-> 00000010a83c3130 System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[DemoLibrary.MyCachedObject, DemoLibrary]]

-> 00000010b83e11e8 System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[DemoLibrary.MyCachedObject, DemoLibrary]][]

Found 1 unique roots (run '!GCRoot -all' to see all roots).

From this we can see that the object is rooted by a static dictionary object. This maps to our understanding of the source code. For a final check we will review the modules and see that DemoLibrary and AppDomainDemo are both still loaded even though it is no longer being used by our code.

0:003> lm

start end module name

00000010`a5cc0000 00000010`a5cc6000 AppDomainDemo (deferred)

00000010`a63f0000 00000010`a63f6000 DemoLibrary (deferred)

000007ff`47bc0000 000007ff`47cee000 clrjit (deferred)

...

000007ff`56b80000 000007ff`56d3e000 ntdll (private pdb symbols) c:\windbg\privatesymbols\ntdll.pdb\FFC2810A1E6F4EC49B4E4A0257637EC62\ntdll.pdb

Unloaded modules:

000007ff`56420000 000007ff`565d0000 combase.dll

Back to the Basics

So what can we do to change this behavior? When I am done my batch and want to continue running in my application I do not need these objects around for the next 24 hours? Well to free up this memory we can use AppDomains. Here is the same application modified slightly, without changing the library that will free the memory when we are done with it. We will create an AppDomain using the same security evidence as the default AppDomain, execute our code in that domain and then unload it.

Here is one way we can adjust the console application to solve this problem, without a need to change the library:

namespace AppDomainDemo
{
    using System;
    using System.Diagnostics;
    using DemoLibrary;

    class Program
    {
        staticvoid Main(string[] args)
        {
            ProcessRequestBatch();

            // Only added to force a collection for demonstration purposes, please do not do this in production
            // inducing a GC is typically not good a good practice
            GC.Collect();

            Console.WriteLine("Completed the batch press enter to continue");
            Console.ReadLine();
        }

     private static void ProcessRequestBatch()
        {
            Stopwatch watch = new Stopwatch();

            watch.Start();

            AppDomain domain = AppDomain.CreateDomain("ProcessingDomain");
            ProcessingWrapper demoProcessor = (ProcessingWrapper)domain.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, typeof(ProcessingWrapper).FullName);

demoProcessor.ProcessRequestBatch();
AppDomain.Unload(domain);

watch.Stop();

            Console.WriteLine("The processing took {0} ms to complete.", watch.ElapsedMilliseconds);
        }
    }

    public sealed class ProcessingWrapper : MarshalByRefObject
    {
        publicvoid ProcessRequestBatch()
        {
            Processor demoProcessor = newProcessor();

            for (int index = 0; index < 10000; index++)
            {
                int id = index % 5000;

                Console.WriteLine(demoProcessor.ProcessRequest(id));
            }
        }
    }
}

In order to make it so we can execute an assembly in a separate AppDomain we need to inherit from the MarshalByRefObject base class. I am attempting to make as few changes to the core library as possible so I have decided to move my loop into a separate class named ProcessingWrapper that inherits from it. The code within this MarhsalByRefObject is virtually identical to the code that as calling it before, without the instrumentation seeing it is more relevant in the default AppDomain.

In order to call the assembly in a separate AppDomain we must first create one with the appropriate permissions. I am not doing this for security reasons so I will use the same permissions and application root in the processing AppDomain as the default. In order to instantiate the type in the new AppDomain we call the CreateInstanceAndUnwrap, after which it is business as usual until I perform the final unload when my processing is done.

So now that we have seen the modifications how does that impact our application?

As you can see from the console this iteration took 2057ms and was executed from the ProcessingDomain AppDomain. If we were to have created an AppDomain with every call to the Processor we would have seen a significant performance impact here.

In the task manager we can see that the memory has dropped back down to 10.4 MB as the AppDomain was released. The memory may still be high after the AppDomain releases until the next garbage collection and this is why we introduced the GC.Collect().

Now that we have seen the memory gets released, what does it actually look like? I reran the application and attached a WinDBG to it partway through the run to get the best snapshot of memory mid processing and will then look at it after the run as we did before.

In Memory

0:007> !DumpHeap -stat

Statistics:

MT Count TotalSize Class Name

000007f900ad4be0 1 24 System.Threading.TimerHolder

…

000007f900abf108 3387 81288 System.Int32

000007f8a2864e20 5000 120000 DemoLibrary.MyCachedObject

000007f900aa0630 1765 159728 System.Object[]

000007f8a2865718 2 299280 System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[DemoLibrary.MyCachedObject, DemoLibrary]][]

000007f900abd5e0 1709 412384 System.Char[]

000007f900abc358 7032 636788 System.String

0000002f5f40b0e0 5155 3792654 Free

000007f900ac04d0 5005 240021562 System.Byte[]

Total 29505 objects

When we look at the heap statistics output above we notice that our cached object is on the heap at this point just as before.

0:007> !DumpHeap -type DemoLibrary.MyCachedObject

Address MT Size

0000002f618a1e18 000007f8a2864ec0 80

…

0000002f7013c9b0 000007f8a2864e20 24

0000002f701454c0 000007f8a2864e20 24

0000002f7189f838 000007f8a2865718 97200

0000002f718b73e8 000007f8a2865718 202080

Statistics:

MT Count TotalSize Class Name

000007f8a2864ec0 1 80 System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[DemoLibrary.MyCachedObject, DemoLibrary]]

000007f8a2864e20 5000 120000 DemoLibrary.MyCachedObject

000007f8a2865718 2 299280 System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[DemoLibrary.MyCachedObject, DemoLibrary]][]

Total 5003 objects

We review a few more details about the instances of my cached object and find one we are interested in looking deeper at.

0:007> !FindAppDomain 0x0000002f701454c0

AppDomain: 0000002f5f470ae0

Name: ProcessingDomain

ID: 2

The object is rooted in ProcessingDomain AppDomain as we had intended.

0:007> !DumpDomain

--------------------------------------

Domain 1: 0000002f5f423520

LowFrequencyHeap: 0000002f5f423cd8

HighFrequencyHeap: 0000002f5f423d60

StubHeap: 0000002f5f423de8

Stage: OPEN

SecurityDescriptor: 0000002f5f4101a0

Name: AppDomainDemo.exe

Assembly: 0000002f5f4147c0 [C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll]

…

--------------------------------------

Domain 2: 0000002f5f470ae0

LowFrequencyHeap: 0000002f5f471298

HighFrequencyHeap: 0000002f5f471320

StubHeap: 0000002f5f4713a8

Stage: OPEN

SecurityDescriptor: 0000002f5f40f700

Name: ProcessingDomain

Assembly: 0000002f5f4147c0 [C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll]

…

Notice from the output above that there are two AppDomains now (excluding the shared which we will not discuss in this article), one is the Default AppDomain and the other is the Processing AppDomain we created in our code. The ProcessingDomain AppDomain is where we executed our library.

0:007> lm

start end module name

0000002f`5eee0000 0000002f`5eee6000 AppDomainDemo (deferred)

0000002f`5f6d0000 0000002f`5f6d6000 DemoLibrary (deferred)

000007f8`f95b0000 000007f8`f96de000 clrjit (deferred)

…

000007f9`0f8d0000 000007f9`0fa8e000 ntdll (private pdb symbols) c:\windbg\privatesymbols\ntdll.pdb\FFC2810A1E6F4EC49B4E4A0257637EC62\ntdll.pdb

Unloaded modules:

000007f9`0ec20000 000007f9`0edd0000 combase.dll

Finally reviewing the modules you will notice that at this point there is no change really other than the code was executed in another AppDomain, the library is still in memory and the process is still consuming the memory from caching.

So now let’s look at the memory after it has finished processing, unloaded the AppDomain and performed a garbage collection. Remember the AppDomains are still using the generational heaps and as such even though the AppDomain may be gone, until the Garbage Collector finds it has no more roots and cleans it up the memory is still being held.

0:006> !DumpHeap -stat

Statistics:

MT Count TotalSize Class Name

000007f900ad13d8 1 24 System.Int64

000007f900ac14b0 1 24 System.Collections.Generic.GenericEqualityComparer`1[[System.String, mscorlib]]

000007f900abc588 1 160 System.Exception

000007f900abb7b0 3 192 System.Reflection.MemberFilter

…

000007f900abc0f0 7 768 System.Collections.Hashtable+bucket[]

000007f900ac0f48 3 1608 System.Globalization.CultureData

000007f900abd5e0 9 4004 System.Char[]

000007f900abe648 95 5320 System.RuntimeType

000007f900abc358 237 11906 System.String

000007f900aa0630 41 37312 System.Object[]

Total 549 objects

The first point to note is that when we dump the heap statistics we do not see any of our cached objects. Just to be sure that we did not miss them we will dump all of the objects of the cached object type.

0:006> !DumpHeap -type DemoLibrary.MyCachedObject

Address MT Size

Statistics:

MT Count TotalSize Class Name

Total 0 objects

This confirms that none of our cached objects are on the heap.

0:006> !DumpDomain

--------------------------------------

Domain 1: 0000002f5f423520

LowFrequencyHeap: 0000002f5f423cd8

HighFrequencyHeap: 0000002f5f423d60

StubHeap: 0000002f5f423de8

Stage: OPEN

SecurityDescriptor: 0000002f5f4101a0

Name: AppDomainDemo.exe

At this point we no longer have the second AppDomain, it has been unloaded from memory and the related objects have been cleaned up by the garbage collector.

0:006> lm

start end module name

0000002f`5eee0000 0000002f`5eee6000 AppDomainDemo (deferred)

0000002f`5f6d0000 0000002f`5f6d6000 DemoLibrary (deferred)

000007f8`f95b0000 000007f8`f96de000 clrjit (deferred)

…

000007f9`0f8d0000 000007f9`0fa8e000 ntdll (private pdb symbols) c:\windbg\privatesymbols\ntdll.pdb\FFC2810A1E6F4EC49B4E4A0257637EC62\ntdll.pdb

Unloaded modules:

000007f9`0ec20000 000007f9`0edd0000 combase.dll

You may be saying right about now, wait, hold on, I would have thought that the DemoLibrary would be an unloaded module seeing the AppDomain is gone? What is going on? Well the way I built the code has the console application still with a reference to the DemoLibrary and any related static variables to the use of that library from the AppDomainDemo will still be rooted and therefore the module is not unloaded. This means that the data portion of memory associated with the ProcessingDomain AppDomains use is released though.

Back to the Basics

So let’s change things up here and consider the scenario where we want to make use of that same library but don’t fully trust it. Sometimes when we take assemblies from other sources they could modify registry or other core system settings etc. without us knowing if the assembly that is making use of them is full trust. To protect against that we will start with our previously modified console and use the AppDomain as a security sandbox instead.

The only piece that we need to change is the ProcessRequestBatch method where we create the AppDomain. We will run in the AppDomain first with all of the code explicitly set to run it in the “Trusted” zone, then with the change of a single line of code we will reduce the permissions. In fact when we reduce the permissions it will fail because it will try to load our console application assembly which it does not have rights to do, even though it is copied into the same application directory.

        private static void ProcessRequestBatch()
        {
            conststring DirectoryName = @"C:\Test";

Stopwatch watch = newStopwatch();
watch.Start();

            // Create the permission set found in the Trusted zone
            Evidence domainEvidence = newEvidence();
            domainEvidence.AddHostEvidence(newZone(SecurityZone.Trusted));
            PermissionSet permissions = SecurityManager.GetStandardSandbox(domainEvidence);

            // Create the directory to be used as the sandbox and copy the soon to be untrusted assembly to it
            if (!Directory.Exists(DirectoryName)) Directory.CreateDirectory(DirectoryName);
            string untrustedAssemblyPath = Assembly.GetAssembly(typeof(Processor)).Location;
            File.Copy(untrustedAssemblyPath, Path.Combine(DirectoryName, Path.GetFileName(untrustedAssemblyPath)), true);

             // Copy the one dependency assembly
            string trustedAssembly = Assembly.GetExecutingAssembly().Location;
            File.Copy(trustedAssembly, Path.Combine(DirectoryName, Path.GetFileName(trustedAssembly)), true);

// Create the AppDomain configuration object
AppDomainSetup domainSetup = newAppDomainSetup() { ApplicationBase = DirectoryName };

            // Create the AppDomain with the full trust permissions in the sandbox defined
            AppDomain domain = AppDomain.CreateDomain("ProcessingDomain", domainEvidence, domainSetup, permissions, null);
            ProcessingWrapper demoProcessor = (ProcessingWrapper)domain.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, typeof(ProcessingWrapper).FullName);
            demoProcessor.ProcessRequestBatch();
            AppDomain.Unload(domain);

            watch.Stop();

Console.WriteLine("The processing took {0} ms to complete.", watch.ElapsedMilliseconds);
}

The first thing we do above is setup the evidence that will be used to tell the CLR what permissions we want to grant the assembly. In this case we are giving the assembly “Trusted” so it will be able to launch our console application and other assemblies. As mentioned previously for consistency I have leveraged the SecurityManager’s default permission set for the “Trusted” zone rather than creating my own.

The sandbox directory is created and the required assemblies are copied to it. Remember the application base should be changed for security reasons and it becomes the root for type resolution within the AppDomain.

The final steps are to create the AppDomain setup information object and pass the information into the AppDomain.Create function call. You will notice the final parameter is a null, this parameter can be used to pass a list of strong named assemblies that the AppDomain allows code executing in it to invoke.

As we can see by the console output everything has run successfully in the “Trusted zone. So what happens when we change the security zone to untrusted? Will everything still run ok? Let’s try it.

        private static void ProcessRequestBatch()
        {
            const string DirectoryName = @"C:\Test";

Stopwatch watch = new Stopwatch();
watch.Start();

            // Create the permission set found in the untrusted zone
            Evidence domainEvidence = new Evidence();
            domainEvidence.AddHostEvidence(newZone(SecurityZone.Untrusted));
            PermissionSet permissions = SecurityManager.GetStandardSandbox(domainEvidence);

            // Create the directory to be used as the sandbox and copy the untrusted assembly to it
            if (!Directory.Exists(DirectoryName)) Directory.CreateDirectory(DirectoryName);
            string untrustedAssemblyPath = Assembly.GetAssembly(typeof(Processor)).Location;
            File.Copy(untrustedAssemblyPath, Path.Combine(DirectoryName, Path.GetFileName(untrustedAssemblyPath)), true);

            // Copy the one trusted assembly that we will allow "full trust"
            string trustedAssembly = Assembly.GetExecutingAssembly().Location;
            File.Copy(trustedAssembly, Path.Combine(DirectoryName, Path.GetFileName(trustedAssembly)), true);

// Create the AppDomain configuration object
AppDomainSetup domainSetup = newAppDomainSetup() { ApplicationBase = DirectoryName };

            // Create the AppDomain with the untrusted permissions in the sandbox defined
            AppDomain domain = AppDomain.CreateDomain("ProcessingDomain", domainEvidence, domainSetup, permissions, null);
            ProcessingWrapper demoProcessor = (ProcessingWrapper)domain.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, typeof(ProcessingWrapper).FullName);
            demoProcessor.ProcessRequestBatch();

AppDomain.Unload(domain);
watch.Stop();

Console.WriteLine("The processing took {0} ms to complete.", watch.ElapsedMilliseconds);
}

You will notice that the only piece of code that changed is highlighted in yellow. Now let’s see what happens when we run this.

You will notice at the top of the console it was a permission’s check that failed. So this is a simple example of how to setup permissions in a secondary AppDomain. So what next? Well the last thing to cover is how the AppDomain can help you in auditing.

In order to demonstrate logging of exceptions I have made a change to the library used to this point. Rather than executing any logic when ProcessRequest is called it immediately raises an ApplicationException. This has been done for demonstration purposes.

namespace DemoLibrary
{
using System;
using System.Collections.Generic;

    public class Processor
    {
        private static readonly Dictionary<int, MyCachedObject> myCache = newDictionary<int, MyCachedObject>();

        publicstring ProcessRequest(int id)
        {
            thrownewApplicationException("Oops an error occurred.");
        }
    }
}

In order to log the exceptions when they occur within the application domain we have added four event handlers, two to the ProcessingDomain and two to the Default AppDomains.

        private static void ProcessRequestBatch()
        {
            Stopwatch watch = newStopwatch();
            watch.Start();

            AppDomain domain = AppDomain.CreateDomain("ProcessingDomain");
            domain.FirstChanceException += (sender, args) => Console.WriteLine("First chance exception happened and the processing domain recorded it.");
            domain.UnhandledException += (sender, args) => Console.WriteLine("Unhandled exception happened and the processing domain recorded it.");

AppDomain.CurrentDomain.FirstChanceException += (sender, args) => Console.WriteLine("First chance exception happened and the default domain recorded it.");
AppDomain.CurrentDomain.UnhandledException += (sender, args) => Console.WriteLine("Unhandled exception happened and the default domain recorded it.");

ProcessingWrapper demoProcessor = (ProcessingWrapper)domain.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, typeof(ProcessingWrapper).FullName);

demoProcessor.ProcessRequestBatch();
AppDomain.Unload(domain);

watch.Stop();

Console.WriteLine("The processing took {0} ms to complete.", watch.ElapsedMilliseconds);
}

It is very important that we view these as “event handlers” and not “exception handlers”, the exceptions that are raised will continue to bubble up whether it is first or second chance. We have two types of exceptions to be notified of being first chance and unhandled. Every exception that is raised starts as a first chance and if no exception handlers catch them are elevated to a second chance or unhandled exception. Unhandled exceptions will cause the process to terminate.

It can be very interesting to use for auditing, especially the unhandled (second chance) exceptions as they are terminal. First chance exceptions need to be audited with caution as they are raised even if the exception is handled. In the scenario that an application or library uses exception handling as for flow of control this can quickly drive the application to its knees.

So let’s run the code above and see the output.

If you notice in the console output above we see that the first chance exception is raised in the ProcessingDomain AppDomain first then when not handled there it bubbles up to the Default AppDomain. Finally note that the unhandled (second chance) exception is generated from the Default AppDomain. Unhandled exceptions will not be raised in the secondary AppDomains as the last AppDomain to have an opportunity to handle an exception is the Default AppDomain.

I hope this has assisted you in your understanding of Application Domains, what they are as well as how and why to use them.

Windows Azure Start-up Tasks Part 2

Chris Clayton1 — Thu, 17 May 2012 14:46:00 GMT

In the previous post “Windows Azure Startup Tasks Part 1” we learned about the basics of start-up tasks and how they can enable you to realize solutions that may otherwise have been outside of the scope of PaaS. This powerful feature offers some additional functionality that we will cover in this post.

Towards the end of this post we will discuss some of the lessons I have learned when working with Start-up tasks easing your adoption of them.

Environment Variables
While the start-up tasks are executing they have access to environment variables that define various characteristics of the instance. The predefined variables are:

@AccountUsername: the remote desktop account user name
@AccountEncryptedPassword: the remote desktop account’s encrypted password
@AccountExpiration: the remote desktop account’s expiration date
@ConnectionString: the default diagnostics connection string
DiagnosticStore: the local directory where diagnostic information is stored
RdRoleId: the internal identifier azure uses to represent the current role
RdRoleRoot: the root path of the drive that contains the application code
RoleDeploymentId: the identifier that represents the current deployment
RoleInstanceId: the identifier that represents the current instance
RoleName: the name of the role that the currently executing instance is based on
RoleRoot: the volume identifier for the drive that contains the application code
WaRoleType: a string that indicates the type of role the currently executing instance is based on (ex. Web Role)

In some cases you may have a need to set an environment variable to be used in your start-up tasks. This can be done by adding a bit more XML. To add a new environment variable for the startup.cmd script to use named TaskName I simply add it to the service definition file as you see below.

In order to get access to more specific instance and environment details you can leverage XPATH queries against Worker Role Schema (http://msdn.microsoft.com/en-us/library/windowsazure/gg557552.aspx) or the Web Role Schema (http://msdn.microsoft.com/en-us/library/windowsazure/gg557553.aspx). In the following example an XPATH is used to determine if the task is running in the emulator.

XPATH based environment variables that are typically of interest include

/RoleEnvironment/Deployment/@emulated

Indicates whether the script is running in an emulated environment

/RoleEnvironment/Deployment/@id

The deployment id of the current instance

/RoleEnvironment/CurrentInstance/@id

The id of the current instance

/RoleEnvironment/CurrentInstance/@updateDomain

The number of the current instances update domain

/RoleEnvironment/CurrentInstance/@faultDomain

The fault domain the current instance is part of

/RoleEnvironment/CurrentInstance/@roleName

The name of the current role

/RoleEnvironment/CurrentInstance/ConfigurationSettings/ConfigurationSetting[@name='Setting1']/@value

Gets the value of a RoleEnvironment setting

/RoleEnvironment/CurrentInstance/LocalResources/LocalResource[@name='LocalStore1']/@path

Gets the root directory of the specified local storage entry

/RoleEnvironment/CurrentInstance/LocalResources/LocalResource[@name='LocalStore1']/@sizeInMB

The size in MB of the local storage entry

/RoleEnvironment/CurrentInstance/Endpoints/Endpoint[@name='Endpoint1']/@protocol

Gets the protocol of the specified endpoint

/RoleEnvironment/CurrentInstance/Endpoints/Endpoint[@name='Endpoint1']/@port

Gets the port of the specified endpoint

/RoleEnvironment/CurrentInstance/Endpoints/Endpoint[@name='Endpoint1']/@address

Gets the IP Address of the specified endpoint

This was not a complete list of environment variables. To find out more you can review the links above where you will see other exposed data such as the Virtual Machine size or web site names.

Lessons Learned
The following few points summarize lessons I have learned over time.

If you create your cmd, batch or ps1 files in Visual Studio be sure to use the advanced save options to select “Save with Encoding”. You can access this using the “Save” button’s drop down menu. The encoding type you want to select is “Unicode (UTF-8 without signature) – Codepage 65001” or it may not execute properly as a start-up task
When running the web platform installer command line tool it executes some packages using a 32 bit profile which will require changes to the executing user’s appdata directory as seen in a later post
Be sure that your install never presents a dialog requiring user interaction, when unexpected this can cause your instance to fail to start
Building your scripts on a virtual machine running Windows 2008 or 2008 R2 enterprise (depending on the matching Operating System Family) is very helpful. Start the clean instance and launch cmd.exe. If you can run your entire script without any user interaction you should be in good shape.
If you have a start-up task that is failing and you cannot figure out why it is helpful to make it a background task, giving you the option of using remote desktop to see what is happening on the box.
Log everything you can. In batch files you can leverage output redirection such as “dir >> log.txt 2 >> error.txt” or in PowerShell you can leverage the Add-Content cmdlet such as ‘Add-Content "$debugFileName" "`nHere is my logged text"’
Only elevate the tasks you need to. Executing processes that require elevation as a start-up task allows you to continue running your core codebase as limited. Do not overlook the opportunity to move things to start-up for this reason.

Helpful Things to Know
So that pretty much covers the basics. I am hoping everyone is comfortable with the information we have covered to this point because we are not going to dive into some more detailed scenarios and samples.

For this next section I will point out some things you can do in batch and PowerShell scripts that you may find useful.

Batch Files

You can use “%~dp0” to represent the directory the script is running in. It is helpful sometimes to change directory to the folder immediately ensuring you know where you are located for building relative paths. Placing the “cd %~dp0” command at the top of you batch file takes care of this.
When debugging install scripts you can use “start /w cmd.exe” to open a command window in the context of the executing user. When using this in conjunction with a background task you may be able to get additional details as to why it is failing. Please be sure not to use this in the final production release, this is for script debugging only.
There are often points in a script that you wish you had a sleep command but you don’t. Leveraging the choice command you can get the same behavior “choice /d y /t 5 > nul” says to display a list of choices for 5 seconds and at the end of 5 seconds default to choice “y”.
When running PowerShell scripts from the batch file remember that by default the execution policies will require you to have a signed script. Most people do not sign their start-up scripts so in PowerShell v2 you can use If you need to run an unsigned PowerShell V2 script even though they are restricted you can execute “powershell -ExecutionPolicy Unrestricted .\Startup.ps1” to launch it.

If you want to change this setting on the machine for all PowerShell scripts in PowerShell v2 you can execute
“powershell Set-ExecutionPolicy Unrestricted”
In PowerShell v1 you have to edit the registry
“reg add HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell /v ExecutionPolicy /d Unrestricted /f”
Please remember that any time you do this you need to weigh out the security considerations of your decision.

Remember that you can simulate a function call in a batch file using code blocks wrapped in

:myFunctionBlockName
my commands to execute using %~1 for the first parameter
goto:eof
To call the above command you would use
call: myFunctionBlockName parameter1
Before your code blocks place
goto:eof
to ensure it does not start executing the blocks without being called

PowerShell

You can load .NET assemblies which allows you to script the download of blobs etc. without building a custom exe
‘add-type -Path "$roleRoot\base\Microsoft.WindowsAzure.ServiceRuntime.dll" | Out-Null’
You can check if the last command failed to executed using “if(!$?)”. This can be really handy to know for taking corrective actions in your script. An example of where you could use this is checking whether a library loaded and if not loading it from another location.

Hopefully the lessons learned above will help guide you through the successful creation of start-up tasks. Watch for the next post “Widnows Azure Startup-up Tasks Part3” where I will show some common tasks that I perform in my scripts that may help you in the future.

Windows Azure Start-up Tasks Part 1

Chris Clayton1 — Thu, 17 May 2012 13:48:00 GMT

I find myself several times a week having conversations with people around the ability to install and configure additional software on Windows Azure™ Web and Worker roles. This key piece of functionality provides a mechanism for you to setup the environment the way you require and still gain the benefits of Platform as a Service.

I am writing this as a series of posts starting with the basics eventually leading to samples of how to deal with specific scenarios.

The Basics
Installation of software and features can be done through start-up tasks which run before the OnStart() method is called. You create a list of tasks that will be executed in the order provided. The role will not become available until all of the tasks in the list have been launched. There are several types of start-up tasks that you have to choose from depending on the behavior you desire such as blocking or non-blocking.

Simple tasks are the most commonly used. This task type will execute the specified command and wait for it to return before launching the next task in the list. This is great when you have an ordered set of installs etc. that must occur before the instance becomes available.
Background tasks are used to start processes that are not required to be complete before the instance becomes available. When the command is launched it will execute in the background and the next task in the list will be processed.
Foreground tasks are the same as background tasks with the one caveat, the instance cannot be stopped while the foreground task is running. The interesting behavior with this is that although you cannot stop the instance that has a running foreground task you can remove it. So if you had 3 instances running and decided to drop the instance count to 2 the instance with the running foreground task could be shutdown.

The OnStart() method will be executed once all of the tasks in the list have been launched and all simple tasks have completed.

In order to configure these tasks you need to open your ServiceDefinition.csdef file and find the element representing the role you want to add them to.

Based on the XML definition above we will be working with the Worker Role named StDemo. Add a child element named Start-up that will contain the task list. Create a child element named task for each start-up tasks you wish to launch.

In the image above you can see that we have created 2 start-up tasks, the first one defining the following elements:

commandLine: is the command to be executed, format this as you would when executing it from the command line. In this case it will execute the file in the current directory named startup.cmd.
executionContext: indicates whether to run the code as the standard or elevated user in the event it requires administrative permissions. In this case we are running it as an administrator (elevated).
taskType: indicates the type of start-task it is. In this case it is a simple task meaning it will block until it returns only running the second task when and if it completes.

Including the Files
Looking at the first task you will notice it is running a file named Startup.cmd but we have not added it to the deployment package yet. I have run into encoding issues with cmd files created in Visual Studio so rather that playing with encoding I simply create the file in notepad first. To add the file to Visual Studio 2010 perform the following steps:

In Solution Explorer open the project that represents the worker role. In the case of this demo it is StDemo.
Right click on the project and select add -> Existing Item
Browse to the file you want to add remembering that you may want to change the file filter to show in our case files with a “cmd” file extension.
Select the file you just added in the solution explorer and navigate to the properties window.
Change the “Build Action” to “Content”
Change the “Copy to Output Directory” to “Copy always”

The changes performed will make Visual Studio add it to the package when it is created. Remember that when using the Worker Role or Web Role in Hosted Core mode these files will be put into the %RoleRoot%\approot folder on the instance. If this is a Web Role in full IIS mode (sites are defined) it will be added to the %RoleRoot%\Sitex where x is replaced by the site number (0 based). This can be important to understand when building your script files.

When using start-up tasks knowing the Operating System family can be important (ex. Windows 2008 or Windows 2008 R2). If you want to change the family you can do it in the configuration file. Remember if you are changing it to do it in both the local and cloud or may have some frustrations determining why your script runs in the development environment but not in the cloud. The following image shows where to change the Operating System family in your configuration file.

An osFamily of 1 is Windows Server 2008 while 2 is Windows Server 2008 R2. If you choose Windows Server 2008 R2 you can leverage PowerShell 2 by default which is very nice to build start-up tasks in.

As you can see by leveraging start-up tasks some of the scenarios where PaaS does not seem to fit become attainable. This is a great yet often overlooked feature that every Windows Azure™ Developer should become familiar with.

I hope you found this post helpful and read more on this in my next post “Windows Azure Start-up Tasks Part 2”.

Windows Azure™ and X509 Certificates

Chris Clayton1 — Wed, 21 Mar 2012 14:33:00 GMT

Quite often I meet with new Windows Azure™ developers around how to setup X509 certificates for their development environment. Setting up the certificates for your first time can be a bit confusing so I decided to create this how to post. The remainder of this post will specifically target development environments that leverage a self-signed certificate for Windows Azure™ management APIs, RDP and SSL.

The first step is to create the appropriate self-signed certificates, one for each of the activities listed above. We will use makecert.exe distributed as part of the in the Windows 7 SDK. The following commands will create the required certificates and insert them into the current user’s personal store.

makecert.exe -r -pe -a sha1 -n "CN=My Azure Management Certificate"
-ss My -sr CurrentUser -len 2048 -sky exchange -sp "Microsoft Enhanced RSA
and AES Cryptographic Provider" -sy 24

makecert.exe -r -pe -a
sha1 -n "CN=My Azure RDP Certificate" -ss My -sr CurrentUser -len
2048 -sky exchange -sp "Microsoft Enhanced RSA and AES Cryptographic
Provider" -sy 24

makecert.exe -r -pe -a
sha1 -n "CN=My Azure SSL Certificate" -ss My -sr CurrentUser -len
2048 -sky exchange -sp "Microsoft Enhanced RSA and AES Cryptographic
Provider" -sy 24

In order to use these certificates in our Windows Azure™ subscription and deployments we will need to upload them from a file. The management certificate requires a .CER format without the private key while the SSL and RDP certificates will be in the .PFX format with the private key. In order to get these certificates into Windows Azure™ we will first export them from the current user’s personal certificate store.

Open the certificate manager by running certmgr.msc.

In the left hand tree view select the Personal / Certificates node. It may take a moment depending on the number of certificates that you have in the store but the three certificates should be displayed. The name of each certificate can be found by looking in the “Issued By” column.

Select the certificate with an “Issued By” value of “My Azure Management Certificate”. On the Action menu select All Tasks / Export to launch the certificate export wizard.

Click the “Next” button to move to the first screen of the export process.

For the management certificate we will not export private keys.

The DER encoded binary X.509 (.CER) format will be used seeing there is no private key to be exported.

Enter or browse to the file where this certificate will be located ensuring it has a .CER extension. Please remember that certificates are used for security and must be stored and treated with the appropriate care.

Click the “Finish” button to complete the export.

We will now export SSL and RDP certificates based on the following wizard sequence. Remember that these certificates will require the private key. Select the desired certificate in the Certificate Manager interface and initiate the export process as we did above. On the first screen of the wizard click the “Next” button.

For these certificates we will export the private key.

Use the PKCS #12 (.PFX) format.

Enter a password for the certificates that you will remember for a future imports and uploads.

Enter or browse to the path where the certificate file will be stored ensuring it ends with a PFX extension.

Click the “Finish” button to complete the export.

Remember to complete this export sequence for the remaining certificate.

Once all of the certificates have been exported it is time to start the import. The first certificate we will import is the management certificate, this certificate is used for accessing the management API’s and deploying your solution.

Open your web browser and navigate to the Windows Azure™ developer portal http://windows.azure.com. Enter your credentials when prompted. Once the screen fully populates click on the “Hosted Services, Storage Accounts & CDN” toolbar item in the bottom left corner.

Select the “Management Certificates” option in the upper portion of the tool bar. It is possible to have more than 1 management certificate if desired.

Select the subscription that you want to add the management certificate to in the content pane and then click the “Add Certificate” toolbar item.

When prompted to provide the certificate, first check to make sure the subscription you want to add the certificate to is selected in the “Choose a subscription” drop down list. Browse to the CER file of the management certificate that we exported previously.

Your certificate for deploying applications and accessing the Windows Azure™ management API is now fully configured in Windows Azure.

For the next portion we will add the Remote Desktop (RDP) and Secure Socket Layer (SSL) certificates to the appropriate hosted service. Where the management certificate is tied to your account at the subscription level these certificates will be attached at the Hosted Service level. In the event that you remove your deployments these will still remain for use when you eventually redeploy, but if you remove the entire hosted service they will disappear. Also remember that these same certificates will be exposed to both the production and the staging slots.

Select the “Hosted Services” toolbar item in the upper left menu. If you have not already created the hosted service you want to add these certificates to create it now, you can create it without a deployment if you would like.

Select the Certificates folder located under the hosted service that you would like to add them to. Once selected click the “Add Certificate” button from the upper toolbar.

When prompted to upload the certificate browse to the PFX file we exported previously and enter the password of the exported certificate file.

The certificate is now uploaded and fully configured inside of your hosted service follow the same procedure to upload the remaining certificate. Once the certificates are uploaded you should see them displayed under the Certificates folder in your hosted service.

Now that the certificates are uploaded successfully into our Windows Azure™ subscription and hosted service we will look at how to use them to deploy directly from Visual Studio 2010. The assumption of the post at this point is that you have already configured your development environment with the appropriate SDKs and tools.

Open the solution that you would like to publish to Windows Azure™ and select the cloud project.

Right click on the cloud project and select the “Publish…” option from the context menu.

From the “Choose your subscription” drop down list select the <Manage…> option and click the “Next” button.

When presented with the list of Windows Azure™ settings click the “New” button.

Select the management certificate we previously uploaded and enter the subscription id. The subscription id can be found in the developer portal. Enter a friendly name for these credentials so you will remember the subscription they are for in the future.

The list of settings will be displayed again and you should see the newly created one. Highlight your new credentials and click the “Close” button.

If the new credentials are not already selected in the “Choose your subscription” dropdown list select them now and click the “Next” button.

On the settings screen you can choose the hosted service you previously created as well as the slot of interest, staging or development. Seeing we are enabling RDP in this post check the box beside Enable Remote Desktop for all roles then click the “Settings…” hyperlink located to the right of it.

In the RDP settings ensure that all of the options are showing, this may require you pressing the “More Options” button to expose the certificate selection. Select the RDP certificate that we previously uploaded to the hosted service. Enter a user name and password to use for Remote Desktop access and click the “OK” button.

Clicking the “Publish” button will complete the publishing process.

Now we have shown how to use the certificates for publishing a solution, exposing the instances via Remote Desktop, the final thing to show is how to setup SSL in a Web Role.

In the Cloud Project expand the “Roles” folder to expose the web role that will be exposed with SSL. Right click on the Web Role and select “Properties” from the context menu.

Selecting the Certificates tab will expose the Remote Desktop certificate that was previously setup. Click the “Add Certificate” button on the toolbar.

Enter a user friendly name for the SSL Certificate you want to use and select it from the list ensuring to set the store location and store name appropriately. In some cases I have found that the certificate I created does not show up in this list, if not it usually will work after you export it again and import it back into your LocalMachine/My store instead of the CurrentUser/My store.

Save the properties page and click the Endpoints tab.

On the Web Role’s endpoint change it to https if it is not already and set the port to 443 (assuming you want the standard port). Selecting the recently configured SSL certificate from the “SSL Certificate Name” drop down will complete the SSL configuration.

Azure Storage and its Various Abstractions

Chris Clayton1 — Mon, 19 Mar 2012 14:57:00 GMT

As you can probably agree, very few applications, short of “Hello World”, do not have some form of storage. The use of storage can range from core repositories to scratch disks, but regardless of the use it typically plays a critical part in the overall architecture of the application. With the importance of storage in mind Windows Azure provides you with a lot of options ranging from strongly typed relational through to transient unstructured. For the purposes of this post we will focus on local storage for transient unstructured data.

If you have worked in or read on Windows Azure compute you will hear the common principle of “do not store things locally and remain stateless”. This is a key part of being horizontally scalable, ensuring that the consumer can move between instances in the same role without ever having an expectation that state or data already exists on the instance. This principle holds true but remember there are specific pieces of data that can be reconstructed when required, that data is the target of local storage. Some examples of this transient data include temporary files, folders and caches.

Local Storage is a directory on the instance that is created for you and you can access as you would any other directory or file. To setup a Local Storage directory you leverage the property sheets in the Cloud Project’s Local Storage tab. Defining the storage is as simple as adding a name that is meaningful to your application, the size in MB that you require and whether you want the storage to always be cleared out when the instance recycles. I personally default to selecting the “Clean on role recycle” option so I return to a known state each time. In the event that you have a large cache etc. that you would have to rebuild on recycle you may opt to leverage some form of time stamp or hash to ensure it is all up to date, rather than incurring the reconstruction cost.

When the role is deployed the provisioning process will ensure that a directory is available for each of the various entries in the Local Storage tab and set the ACL’s appropriately.

As you can see in the code sample above to get the local path we request it from the RoleEnvironment object that is found in the Microsoft.WindowsAzure.ServiceRuntime namespace. Once you retrieve the directory you access it the same way you would access your local file system.

In fact the storage is nothing more than a directory created on your local instance as you see above.

When selecting the size of the Local Storage you must remember to select a Virtual Machine that has enough local storage capacity.

Roles and Instances

Chris Clayton1 — Mon, 07 Nov 2011 13:04:00 GMT

Overview

In order to ensure the benefits of this post are maximized I will level set by defining what roles and instances are as well as how they relate to each other.

A role in Windows Azure is really a blueprint that describes what an individual virtual machine will look like. The blueprint includes details such as the size of the virtual machine, ports and protocols that are allowed through the firewall and whether a port is exposed publicly. In order to simplify the definition of these roles many of the elements are defined through a service definition file that adheres to a defined XML schema.

One or more virtual machines that are based on a role can run at the same time. Each of these virtual machines is known as an instance.

When designing a solution that will run on Windows Azure it is a good practice to decompose your application into a set of core services. Each of these services should be considered potential roles, but keep in mind that sometimes two of these services are so closely related in scaling characteristics you may choose to consolidate them.

A role is the smallest unit of compute scale within Windows Azure, allowing you to change the number of instances that are running.

It is important to understand that roles are not durable, meaning that changes made during execution to the local file system or machine will be rolled back if the machine is reimaged. A machine may be reimaged at your discretion or in the case where the Windows Azure Fabric Controller deems it required. The reimaging could be triggered by hardware failures, software updates or other events. There are a few options for storing data such as files that we will cover in later posts.

The instances sit behind a load balancer that leverages a round robin algorithm resulting in the inability to ensure the next query from a consumer will access the same instance it previously did. This means that any operations coming in on the public ports should ideally execute in an atomic operation, only storing session state in mechanisms that are shared between all instances. For interrole communications the load balancer is not used, providing the ability to talk directly to a specified instance.

Role Types

Web Role – this role is based on either Windows 2008 Server or Windows 2008 R2 Server and runs Internet Information Server. This role defaults to exposing a single public HTTP endpoint on port 80, but others can be opened as required. Typical uses of this include running ASP.NET, PHP and CGI applications. This role can have patching of the Operating System set to automatic reducing administrative costs of the solution. This role supports startup tasks allowing for the silent install of applications or environment changes.

Worker Role – this role is based on either Windows 2008 Server or Windows 2008 R2 Server. This is geared towards generalized computing similar in nature to an EXE or Windows Service. By default this role does not expose any endpoints, but can be set to as appropriate. Typical uses include background processing or running third party applications. This role can have patching of the Operating System set to automatic reducing administrative costs of the solution. This role supports startup tasks allowing for the silent install of applications or environment changes.

VM Role – This role is in beta at the time of writing. This role is based on a Windows 2008 R2 Enterprise image built locally and uploaded. This role is still not durable as it could be reimaged as appropriate. This role is geared at scenarios where a required install takes a long period of time, requires user input or is fragile. This role does not have the ability to automatically patch the Operating System leaving updates to be made by the developer through the creation and application of differencing disks. In general I recommend people look at the Worker and Web roles prior to falling back to the VM role.

Scaling

Although the role is the smallest unit of deployment I tend to encourage people to create what is sometimes termed as a “Scale Unit”. The concept is that before deployment you benchmark a specific configuration of instance counts providing a known configuration to capacity scenario.

For Example:

In this scenario you create an expense processing system where your company’s employees will submit expenses through an ASP.NET web site (Web Role) and processing will occur later through a background process (Worker Role). You could initially benchmark the employee count that could be supported with two ASP.NET web sites (Web Role) and a single background process (Worker Role). If this benchmark showed that 2500 employees could be supported on this configuration you could say that your “Unit of Scale” is 2 Web Roles and 1 Worker Role. This means that if I run most of the month with 2500 users but on the last 2 days spike up to 7500 users I can run a single scale unit for most of the month and on the last 2 days bring two additional scale units online. This allows for easier proactive scaling.

Key Concepts Associated with Windows Azure Development

Chris Clayton1 — Mon, 26 Sep 2011 21:23:00 GMT

As a developer first looking at diving into Windows Azure Development it is important that you are familiar with a few concepts.

Windows Azure is for Everyone

When adopting Windows Azure as a development platform people are often concerned about having to learn a new development environment and language. In an effort to embrace the open nature of software development and providing the developer with choice Windows Azure applications can be written in many languages including .NET, PHP and Java. Eclipse and Visual Studio have additional feature for developing on the Windows Azure platform but other IDE’s can also be used including our favourite Notepad.

Developing for Scale

When creating a scalable application you can build it to scale horizontally or vertically. Vertically scaling is when larger machines are put in place to handle increases in load. In general this is typically the easier method of development but has the downside of being more expensive from a hardware point of view with the larger machine costing in proportionately more than their smaller counter parts and being limited to the largest machines available. Horizontally scaling is when additional machines are put in place (ex. a Web Farm) each doing its part to handle the load. Horizontal scaling tends to have a linear cost when using standardized machines but it includes several development challenges. Windows Azure’s design targets horizontal scaling and applications should be architected to take advantage of it.

In an ideal scenario each machine should be able to sit behind a load balancer without session maintained. This means that session specific details should not be stored locally on the machine such as the hard drive instead it should be stored in a centralized location that all of the servers can access.

In most scenarios synchronous or blocking operations directly oppose high scalability and flexibility. Creating loosely coupled architectures that are asynchronous are very important when leveraging Windows Azure and can be accomplished using Azure Queues or other similar structure.

Although there are many other considerations when developing highly scalable applications those are some of the big ones that should always be considered.

Feature Groups

When looking at Windows Azure features they are typically broken down into 3 large buckets.

1) Windows Azure – Highly scalable compute and storage often used to run background processing and application interfaces such as ASP.NET.

2) Microsoft SQL Azure – The relational database of choice on the Windows Azure platform. This will seem very familiar to any DBA that leverages Microsoft SQL Server 2008 R2.

3) Windows Azure AppFabric – Middleware components that can be used to create highly scalable application that can exist across geographic and security boundaries. An example is when the Windows Azure Service Bus is used to reach from Windows Azure data centres and pull information from an on premises accounting system (spanning firewalls etc.).

These are some of the core pieces of information that you should keep in mind whenever dealing with anything related to Windows Azure. Keeping these in mind while reviewing the rest of these blogs will be helpful.

Common Workloads for Azure

Chris Clayton1 — Fri, 15 Jul 2011 10:27:00 GMT

When we start looking at Windows Azure there are several key workloads that come to mind, the ones that are pretty much slam dunks for being a fit.

Workload 1 - On and Off

On and Off typically represents applications or web sites that are needed for a short period of time and later shut off. An example of this would be a marketing campaign that runs a web site for two months every year around Christmas because it is your peak sales time. The cost of acquiring the capacity for this heavy load period and then maintaining throughout the year or recommissioning can often be very high. Azure allows you to minimize both the upfront capital investment and the recurring monthly maintenance expenses. The reason for this is that you pay for what you use in Azure, so if you run it for these two months then decomission it at the end you stop paying for it until the next year when you redeploy. This not only helps reduce cost but potentially offers the business the ability to execute on more campaigns than they would typically due to overall cost.

Workload 2 - Scale Fast

Scale Fast is reflective of applications or sites that are introduced by the business without a good handle on what the adoption rate will be. Typically you would have to build out extra capacity at the beginning beyond the anticipated level to ensure the best customer experience. Using Azure you can start with a couple instances of the application and write code that will automatically deploy additional instances as required based on actual usage. This allows the available capacity to closely follow the real demand for the site, keeping costs down while reducing the burden of capacity planning.

Workload 3 - Predictable Bursting

Predictable Bursting is typically seen in companies that have a seasonal component to them, such as retail with Christmas driving a large quantity of their sales or finance where RRSP season can spike in activity. Azure can be used in this scenario as well to reduce investment in additional hardware and infrastructure required to support the load during these bursts. There are two ways people typically handle this type of capacity "augmentation", either through load transference where they host the application, or some components of the application, in Azure during the burst or as an application extension. Application extensions can be an interesting scenario with the application running on premise during normal load states or periods and when additional capacity is required they introduce additional capacity in Azure, never eliminating the on premise portion. This is sometimes referred to as a hybrid application.

Workload 4 - Unpredictable Bursting

Unpredictable Bursting is the same as Predictable Bursting above except in the sense the burst can come at any time. An example of this is if the government ran a campaign that gave tax breaks on purchasing new appliances appliance retailers may all of a sudden realize a significant load increase on their web sites. This is load can be handled in the same way as the Predictable Bursting scenario, except the identification of the burst scenario would typically be automated to ensure it could react and scale on demand.

The above workloads do not make up a comprehensive list of scenarios where Azure can be leveraged, but it does identify the key four workloads where the value of Azure can be quickly recognized.

Standard Cloud Taxonomies and Windows Azure

Chris Clayton1 — Tue, 07 Jun 2011 14:53:00 GMT

Prior to evaluating a cloud solution it is important to understand the various taxonomies available in the vendor ecosystem today. Without understanding the strengths, weaknesses and targeted mindsets of each taxonomy you may not select the appropriate one to meet your business objectives.

A Cloud Taxonomy is a way of categorizing and comparing cloud solutions based on their degree of control, methods of provisioning and delegation of operations. The three industry accepted taxonomies are known as Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS).

In this discussion we will move from left to right with each step typically increasing in agility, reducing cost while reducing control.

IaaS (Infrastructure as a Service)

This taxonomy is geared towards customers that require the ability to stand up virtual machines in the cloud. This is often the taxonomy that comes to mind when customers first start thinking of cloud. This can be an attractive offering when there is no desire to modify code and the end goal of the transition to the cloud is simply to move an existing legacy application off site with as little work as possible.

Although this IaaS has the lowest bar for entry it typically does not exhibit the maximum value proposition of the cloud.

Common business drivers

Improving IT agility
Moving capital expenditures to operating expenditures
Reducing IT spend to deliver business aligned solutions
Increasing business agility through improved speed of provisioning new environments
Providing capacity that may not be available in the on-premises counterpart

Strengths

Low bar of entry to move applications into the cloud
High degree of control over the applications and guest environment
Faster provisioning than on-premises systems
Capacity that typically exceeds what is available in the on-premises environment
The mindset of standing up virtual machines is familiar to customers that leverage virtualization on-premises
Delegates the responsibility for hardware, physical networking and network storage to a vendor

Weaknesses

Responsibility associated with a large portion of the overall stack remains with the customer
Adherence to operational practices and procedures for the virtualized stack remain with the customer
Patching and maintenance of the guest operating system remains the responsibility of the customer
The middleware and runtimes associated with the platform are the responsibility of the customer
Typically there are fewer framework and application building blocks than found in the Platform as a Service offering
Typically the customer is still responsible for the licensing as it relates to the guest operating system and above
Stepped addition of capacity mimics that of on-premises systems making most applications less capable of tightly coupling the load and capacity, although in some scenarios it may be possible (the step is equivalent to the resources provided by a single server)
Developers are still expected to have knowledge of Operating System management and security instead of focussing on writing software

Opportunities

Migration of applications that are not at high touch points can provide a cost benefit by saving virtual machine provisioning times and costs
Application scenarios that have unpredictable capacity requirements can be handled through hypothesising the required capacity, provisioning the machines and then scaling up or back based on the application usage

PaaS (Platform as a Service)

Platform as a Service provides the customer the ability to host solutions in the cloud. These solutions are decomposed into a set of services which can typically be scaled independently. The ability to scale independently exposes a greater degree of control with smaller steps being created in the alignment of capacity and load. The closer one can run the load and capacity levels usually results in a better Total Cost of Ownership (TCO) for the customer. With this taxonomy the mindset is not focused around standing up virtual machines rather around hosting a solution and its services. Arguably when leveraging a PaaS offering one should not think of it in terms of Virtual Machines instead consider it hosting instances of your solution’s services. Typically this mindset will fit very well with any customer already subscribed to the Service Oriented Architecture design methodology.

Platform as a Service is ideal for migrating applications that are at high touch points (rewrites, upgrades or other milestone that requires changes to code) or have business drivers such as improving a solution’s availability, scalability, capacity or reducing cost. The reason these situations are ideal is that in order to take advantage of many of the platform offerings it may take changes to source code. It is important to make use of these additional feature sets as they often provide a very attractive return on investment, improve customer experience or open up the ability to deliver new business streams. Although these platform features are desirable to implement they are typically not required, often allowing the migration of applications from an on-premises solution to cloud with little or no effort.

Common Business Drivers

Improving IT agility
Moving capital expenditures to operating expenditures
Reducing IT spend to deliver business aligned solutions
Increasing business agility through improved speed of provisioning new environments
Providing capacity that may not be available in the on-premises counterpart
Increasing the speed in which custom solutions can be brought to market
Reducing security related concerns surrounding hosted environments
Reducing IT’s requirement for knowledge of custom solution adoption rates

Strengths

Simplified deployment of custom solutions
Higher degree of control over the customer solutions than in a SaaS environment
Reduced level of IT knowledge required by developers
Less operational burden on the customer
Elastic scaling reduces the requirement for business to exactly gauge uptake of new custom solutions
Smaller segment of the stack remains the responsibility of the customer
Automated patching of the platform helps to improve overall security
Focus on hosting solutions rather than standing up virtual machines allows developers to focus on developing great software
Fast scaling with ability to fully automate scaling
Typically faster provisioning than IaaS
Capacity that typically exceeds what is available in the on-premises environment
Delegates the responsibility for hardware, physical networking, network storage to a vendor and well guest OS

Weaknesses

Migration of applications that will take advantages to full PaaS feature sets often require application modifications
Less control than IaaS with reduced control over the guest Operating System
Targeted at custom applications with support for packaged software

Opportunities

Migration of applications that are at high touch points can provide a better ROI and reduced TCO than the IaaS counterpart
Savings in both time and cost for the provisioning of application platform may improve the time to market of custom applications
Reduces the requirements for the developers to know the operating system, instead they can focus on developing software
Reduces IT required involvement provides the ability for IT to focus on improving existing or introducing new services to align with key business drivers
The ability to scale in line to the demand providing a great platform for micro sites and start-up applications where the adoption and demand level may not be known in advance

Software as a Service (SaaS)

Software as a Service provides customers with the ability to provision a new account or configuration on an existing application hosted by the vendor. These applications are typically multitenant providing the customer with a reduced set of control in exchange for a lower level of maintenance and management.

SaaS is a great offering for customers that host applications on-premises that do not align with their core competencies. An example of a Software as a Service offering would be a hosted enterprise messaging system. Very few companies have enterprise messaging as a core competency, rather it is a business support function and therefore it is often well served to move to the cloud.

Common Business Drivers

Improving IT agility
Removing responsibility for management of systems that are not core business capabilities
Moving capital expenditures to operating expenditures
Reducing IT spend to deliver business aligned solutions
Providing capacity that may not be available in the on-premises counterpart
Reducing IT’s requirement for knowledge of application adoption rates

Strengths

Simplified deployment of applications
Less operational burden on the customer
Elastic scaling reduces the requirement for business to exactly gauge uptake
The vendor manages most aspects of the application, typically leaving the customer with application and subscription management
Automated patching of the platform helps to improve overall security
Typically includes automated scaling
Typically the fastest provisioning model out of the cloud taxonomies
Capacity that typically exceeds what is available in the on-premises environment

Weaknesses

Less control than the other taxonomies
Typically little ability to customize applications

Opportunities

Migration of purchased applications that do not align with the businesses core competencies
Savings in both time and cost for the provisioning of the application
Can improve new account provisioning turnaround
Reduces IT required knowledge and involvement providing them the ability to focus on improving existing or introducing new services to align with key business drivers
The ability to scale in line to the demand

Where is Azure in this?

Azure is falls square in the Platform as a Service offering with many features that are not available on-premises. Azure has been built from the ground up with scalability and cross platform support in mind. This makes the platform great for most developers whether .NET, Java, PHP and more.

There are many additional features exposed by Azure to support a wide variety of scenarios including automatic scaling, hybrid solutions where Azure reaches back on premise through to connectivity between disperse security realms.

As we move through the next posts we will dig deeper into many of these features.

Ramping on the Windows Azure Platform

Chris Clayton1 — Mon, 16 May 2011 14:42:00 GMT

It has been several months since I started my ramp on the Windows Azure Platform and am now ready to write about it. While I worked through the material and guidance it was evolving and growing which often changed my mindset on techniques to handle various scenarios.

In an effort to allow others to learn from my ramping experience I have decided to start writing a series of posts that will help novice Azure developers learn the platform. In this series I will discuss

1) the various taxonomies of cloud and where Azure plays

2) common workloads for Azure

3) key concepts associated with Azure development

4) roles and instances

5) Azure storage and it’s various abstractions

6) SQL Azure

7) Windows Azure Connect

8) Windows Azure AppFabric Cache

9) Windows Azure AppFabric Access Control

10) Windows Azure AppFabric Service Bus

11) Hybrid solutions

The points above are listed in the order I plan on approaching them, but each bullet may equate to several posts.

I am sure that you will find the Windows Azure Platform to be as interesting as I have.