When Windows Azure was initially released all of the program code executed inside a .NET sandbox, with no possibility of escape. This ruled out not only any non-.NET DLLs, but also any non-.NET environments. You couldn’t write Python or Ruby or Java code.
As part of the MIX release in March 2008, all of this changed. Windows Azure now exposes an option to enable users to run any code on the platform, with .NET now being only one option among many. Obviously, this opens up a wealth of possibilities, many of them explored in this chapter.
You might be wondering why you have to do anything special to run native code at all. After all, .NET has good support for interoperating with native code—from P/Invoke to COM Interop. However, those mechanisms don’t work out of the box on Windows Azure because of the sandbox in which your code runs.
All user code in Windows Azure runs on the Windows Azure hypervisor. Also, any code that runs in Windows Azure runs under the context of a “standard user” (as opposed to a “user with administrative privileges”).
This distinction is important, because this is something that cannot be opted out of, regardless of whether you’re running native or managed code. Actions that require administrative-level privileges on the machine (such as installing drivers, or changing system binaries or protected parts of the registry) will fail.
You should always ensure ...