Hosting Roles Under .NET Full Trust
One of the great things about Windows Azure is that it handles the deployment, monitoring, and management of your service so that you have more time to focus on the business logic. Until recently, realizing these benefits meant your code had to run under Windows Azure partial trust, a code access security (CAS) level which locks down certain .NET functionality.
Windows Azure now offers the option of running the code in your Web and worker roles under full trust. This unlocks a number of compelling scenarios such as:
- Invoking non-.NET Code: Many developers have existing investments in native code or may choose to use native code for some specialized tasks. .NET full trust makes it possible to use native code via spawning processes or Platform Invoke (P/Invoke).
- Using .NET Libraries that Require Full Trust: Certain .NET libraries, including libraries in the .NET Services SDK, require full trust and can now be used in Windows Azure.
- Inter-process Communication via Named Pipes: If you application spawns processes, you can communicate among them via named pipes.
Note: While .NET full trust lifts CAS limitations, Windows Azure applications run with restricted “User” privileges in the cloud. Accordingly, certain operations such as modifying the registry and writing to the system directory are not possible at this time (even though they may succeed in your local development environment).
How to Get Started
To enable full trust, simply add the enableNativeCodeExecution attribute to your role in the Service Definition file and set the attribute value to true:
<>xml version="1.0" encoding="utf-8"?>
ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
WebRole name="WebRole" enableNativeCodeExecution="true">
InputEndpoint name="HttpIn" protocol="http" port="80" />