Windows Azure

Windows Azure

The Windows Azure Platform has a rich diagnostics infrastructure to enable logging and performance monitoring in the cloud.

When you run a cloud app locally in the DevFabric you can view diagnostics trace output in the console window that is part of the DevFabric UI. For example, say I have the line

System.Diagnostics.Trace.TraceInformation("Old Trace called at {0}.", DateTime.Now);

That line gives a result like this in the DevFabric UI:

Screenshot of DevFabric UI

If you can’t see the DevFabric UI, you can enable it here after starting your cloud app from Visual Studio:

image 

Using the DevFabric UI is the most basic form of viewing Trace output. Looking at each individual console window doesn’t really scale well if you have many instances and, furthermore, the console window of an instance is not available in the cloud. For this, there is a special TraceListener derived class: Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener. It sends the trace output to a Windows Azure diagnostics monitor process that is able to store the messages in Windows Azure Storage. Here is a look at a trace message using the Azure Storage Explorer:

Screenshot of Azure Storage Explorer

This trace listener is enabled through web.config:

  <system.diagnostics>
    <sources>
      <source name="Diag">
        <listeners>
          <add name="AzureDiagnostics" />
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
          name="AzureDiagnostics" />
    </sharedListeners>
    <trace>
      <listeners>
        <add name="AzureDiagnostics" />
      </listeners>
    </trace>
  </system.diagnostics>

You can also see a message “TraceSource called at …”. This message was output using a TraceSource instance:

private static readonly TraceSource ts = new System.Diagnostics.TraceSource("Diag", SourceLevels.All);

protected void TraceMeButton_Click(object sender, EventArgs e)
{
    ts.TraceEvent(TraceEventType.Information, 2, "TraceSource called at {0}.", DateTime.Now);
    System.Diagnostics.Trace.TraceInformation("Old Trace called at {0}.", DateTime.Now);
}

However, note that a similar message “TraceSource called at …” didn’t show up in the DevFabric UI. You might wonder what is going on. And you might wonder why I want to use a TraceSource instead of Trace? Because this MSDN article states:

One of the new features in the .NET Framework version 2.0 is an enhanced tracing system. The basic premise is unchanged: tracing messages are sent through switches to listeners, which report the data to an associated output medium. A primary difference for version 2.0 is that traces can be initiated through instances of the TraceSource class. TraceSource is intended to function as an enhanced tracing system and can be used in place of the static methods of the older Trace and Debug tracing classes. The familiar Trace and Debug classes still exist, but the recommended practice is to use the TraceSource class for tracing.

Also check out this blog post.

The reason you don’t see the message for the TraceSource in the DevFabric UI is that the DevFabric magically adds a special TraceListener for the “old fashioned” Trace class, but not for your TraceSource instance. I put together a cloud app solution (Visual Studio 2010) that shows this through a simple web role. This web role has the configuration you see above in its web.config file. If you run this simple web role in the DevFabric you’ll see:

Screenshot of sample web role app

Note that Trace has a Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.DevelopmentFabricTraceListener instance registered, while the TraceSource hasn’t. To remedy this, I’ve created a small class that adds a DevFabricTraceListener to a TraceSource if it is registered for Trace:

public static class TraceSourceFixer
{
    private const string DevFabricTraceListenerFullName = "Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.DevelopmentFabricTraceListener";

    public static void AddDevFabricTraceListener(TraceSource traceSource)
    {
        var alreadyInTraceSource = GetDevFabricTraceListeners(traceSource.Listeners);

        if (alreadyInTraceSource.Count() > 0)
            return;

        var alreadyInTrace = GetDevFabricTraceListeners(Trace.Listeners);

        var devFabricTraceListener = alreadyInTrace.FirstOrDefault();
        if (devFabricTraceListener != null)
        {
            traceSource.Listeners.Add(devFabricTraceListener);
        }
    }

    private static IEnumerable<TraceListener> GetDevFabricTraceListeners(TraceListenerCollection listeners)
    {
        var result = from TraceListener listener in listeners.Cast<TraceListener>()
                where IsDevFabricTraceListener(listener)
                select listener;

        return result;
    }

    private static bool IsDevFabricTraceListener(TraceListener listener)
    {
        return (listener.GetType().FullName == DevFabricTraceListenerFullName);
    }
}

This helper class gets called when you press the Register DevFabric Listener button. If you click the Trace Me button after that, you’ll see two trace messages show up in the DevFabric UI:

Screenshot of DevFabric UI detail

You can download my solution DiagnosticsService.zip to try it yourself.

.NET Frameworkin Windows Azure 

As you will probably know, Visual Studio 2010 and .NET Framework 4 will RTM on April 12, 2010 and will be available for download on MSDN Subscriptions Downloads the same day.

The Windows Azure team is committed to making .NET Framework 4 available in Windows Azure within 90 days of the RTM date.

A lesser known fact is that the latest available Windows Azure build already has a .NET 4 version installed, namely the RC bits. Although this version cannot be used to run applications on (because .NET 4 is not yet exposed in the Windows Azure dev tools), you can use this build to test if the presence of .NET 4 has impact on existing .NET 3.5 apps running on Windows Azure.

Read the official announcement here.

[Updated 2010-04-25: The lightweight view for MSDN has been fixed, so the content of this post is no longer relavant]
[Updated 2010-04-07: Updated one screenshot, because the lightweight view has changed]

MSDN has recently switched the default online view mode to “lightweight view”. Although this dramatically improves loading times for the online docs, this currently breaks parts of the Windows Azure Documentation. For example, when you view http://msdn.microsoft.com/en-us/library/ee393295(v=MSDN.10).aspx in lightweight mode, the namespaces are not hyperlinks and the menu is broken:

image

To fix this, you have to click on the “Preferences” link in the upper right corner of the page:

image

 

Choose “Classic” on the page that appears:

image

Click OK, and you’ll get back to a view that actually works:

image

 

We are working on getting the “lightweight view” fixed with this part of the Azure documentation.

WinAzure_h_rgb

I don’t write much for public consumption these days, i.e., this blog has gone really quiet 😉 Most of my work is for clients that don’t like it if I blog about that.

But I did write an article about cloud computing and Windows Azure for the Dutch TechNet Magazine with my colleague Dennis Mulder. It wasn’t until today that I had an actual hardcopy in my hands.

The article titled “Microsofts Cloud Computing Platform” (written in Dutch) is available as a PDF. For the entire content of the Februari 2010 issue of the magazine check this page.

I ran into an issue with a Windows Azure project created from scratch in Visual Studio 2010 Beta 1 with the May CTP of the Windows Azure Tools.Azure_Logo

When trying to create tables in the local development storage, I got the error “Invalid image format”. This issue occurred both from VS (using the Create Test Storage Tables option) and when running DevTableGen.exe manually from a command prompt. It didn’t occur when doing the same in VS2008.

DevTableGen.exe is a tool from the Windows Azure SDK. This tools loads an assembly, reflects over it and then tries to create tables in the local development storage.

After some head scratching I figured out the cause: in Dev10 the default target platform for executables was changed from AnyCPU to x86. In Beta 1 a bug snuck in, so that x86 is also the default for class libraries (DLLs). This will be changed back to AnyCPU in Beta 2. This blog post from Rick Byers has a lot of detail on why the default has changed.

DevTableGen.exe is an AnyCPU executable, so it will run as a 64-bit process on an 64-bit version of Windows. As such it cannot load assemblies marked as 32-bit only when run on 64-bit Windows. The solution was to change the assembly to AnyCPU.

This issue would have been prevented if DevTableGen.exe was marked as 32-bit only. That way it would always run in a 32-bit process and could load x86 and AnyCPU assemblies. According to the blog post linked to above, it is now considered best practice to explicitly mark an executable as x86 or x64. For most applications x86 is the best option.

I’ve suggested this change to the product team.

Update: I've been informed that DevTableGen.exe will not be changed. This is because this issue is temporary and will go away when VS2010 Beta 2 is released. Also the web role and worker role processes in Windows Azure are 64-bit, so trying to load x86 assemblies will fail anyway. So if you use Beta 1 make sure you explicitly change the platform for any assemblies you create for the cloud to AnyCPU.

1 Comment

Ever since the internal unveiling of Windows Azure as project “Red Dog” at our internal TechReady conference in July 2008, I’ve been very interested in this Software+Services platform.

Technical strategist Steve Marx from the Windows Azure team recently released a cool sample app called The CIA Pickup. He put up a demonstration video and a nice architecture drawing of this app up on his blog.

TheCiaPickup_Logo

Using the app you can pretend to be a CIA agent and hand out a phone number and your agent id to someone. When this person calls this number, they are greeted by an automated message that says they are connected to the CIA automated phone system and are requested to enter your agent id. After they have entered your id, you will receive their caller id via e-mail.

Seeing that 90% of the IT population seems to be male of which probably 95% is straight, I can see why the app is slightly biased in helping men picking up phone numbers of women. But if you don’t like this, you can always pick up the source and change the text. Which I did. Not to change the text, but to make some improvements so that I could run the app in my own Windows Azure playground in the cloud.

For example, the SMTP port of my e-mail service is not the standard port 25. I made this port configurable and in the process I found out that the app has to be deployed with full trust in order to be able to use the non standard port. I added logging to trouble shoot issues like this and made some security improvements.

I contributed these improvements back to Steve and he has gracefully credited me in his second blog post.

The CIA Pickup app is a great example of the power of combining different off-the-shelf services like SMTP providers, telephony service Twilio, Azure Table and Queue Storage, Windows Live ID Authentication with custom code, C# and ASP.NET MVC, running in the cloud. You can literally have this up-and-running within a couple of hours, including the creation of all necessary accounts.

So go try it out! You don’t need to deploy the app yourself to do this. You can use Steve’s deployment for this. Although it uses the US phone number +1 (866) 961-1673, it works when dialing from the Netherlands. If you want to get in touch, use my agent id 86674 😉

If you watched the first keynote of PDC08, either at PDC or through the live stream, you have seen the first public unveiling of Windows Azure. In short, it’s our OS for the cloud.

servicesPlatform

A CTP of the Windows Azure SDK should be available shortly. In the mean time, you can get busy with the “Oslo” SDK that has been released already. Downloadable from the new “Oslo” Developer Center on MSDN.

Of course as a Microsoft employee I am biased about this new, but oh so familiar, platform. So don’t take my opinion, but that of Robert W. Anderson. He writes about Windows Azure:

It is the openness of this platform, the ability of developers to mix and match the different components, and to do it between the cloud and in-premises solutions that makes this such a winner.

This last point is an important one.  Microsoft is in a unique position to help enterprise IT bridge to the cloud.  While I don’t think Amazon and Google will cede that market to Microsoft, their current offerings aren’t a natural fit.

Taking this all together — not forgetting Microsoft’s leading developer productivity story — it looks like a home run to me.