So I’ve been working on a proof of concept this past week, and one of the biggest issues I’ve had has been trying to see what has been going on with my “container” when I deploy my app to Windows Azure. It’s not that the logs aren’t good enough, but sometimes I need to try interactive commands to see the state of the environment or test something out.
First, let’s recap a little Windows Azure 101; when you deploy your application, we spin up a VM and deploy your app into that VM. That VM has some policies set, which restrict what you’re able to do compared to your local machine or dev server.
So how do you see what your VM is doing? Well, since we don’t really provide any option to TS (remote admin) into your VM instances, I had to come up with a slightly different approach. The first step was to flick on a little known setting, but very powerful one:
Enabling Native Code Execution turns off the partial trust policy in Windows Azure, allowing you to run a bunch of functions that you were previously able to run in the old Nov CTP 2008 days.
My next task was to code up a little page that would allow me to run commands in the VM environment, kind of like a remote console, so I could see what was happening when I was trying to run my app.
The main bit of code is quite simple, and uses the System.Diagnostics.Process to create a new command window to run my commands, and capture the output back into my ASP.NET page. Here is the code to create the command process and get the return data:
So I have a simple page now, where I can enter commands, and see what is returned when run within the VM:
Oh the things one finds out about their VM! For example, I can run commands like:
This type of insight is really important, for example, in my task, I was trying to start a new process (Apache Tomcat), but couldn’t get a response from the default address that Tomcat binds to (http://127.0.0.1:8080), and couldn’t work out why it worked on my local dev fabric and not in the cloud. I then ran NETSTAT and saw that the 8080 port was already bound to a virtual address, hence why it wouldn’t work for me.
Anyway, there is a wealth of information that can help you as a developer, when trying to debug/troubleshoot an issue, that can only be gleaned from the live environment, so tuck in!