Monthly Archives: February 2014

Remotely Debugging Web Jobs on Windows Azure Websites

Yesterday I posted up some thoughts about how to streamline deployment of .NET-based Web Jobs along with your web-application. Continuing on with Web Jobs I thought it might be interesting to figure out how to debug them once they are deployed. With Windows Azure it is now possible to remotely debug a web application via Visual Studio when it is running in Windows Azure Websites.

Using the same mechanism it is also possible to attach to a running Web Job process which can help you dig into problems in Web Job execution during development (I wouldn’t recommend attaching a debugger on a production site). Unfortunately the process is a little kludgey right now so I’m not sure how effective this would be as a “normal-case” debugging scenario, but it’ll work in a pinch.

Before your start, to help you with the timing issue you might like to insert a Thread.Sleep(…) into your job just to give you enough time to attach to the process. Once you’ve got that updated Web Job code deployed start the debugger by attaching to the Windows Azure Website via the Attach Debugger menu option in Server Explorer.


Visual Studio will then spin away loading symbols etc. Once that is done go into the Windows Azure management console and start the web-job. At this point you need to work fast (depending on the value of the Thread.Sleep(…) that you put in.

Go into the “Debug | Attach to Process” menu item and select the web-site you are debugging from the Qualifier drop down (this is the remote debugging session that is currently supporting your web-app debugging). What you should see is your web-job executable in the list of available processes.



Once the debugger is attached any breakpoints that you have set within the web-job code will be hit and you can step through line by line.



Bingo! So now you know how to debug Web Jobs remotely via Visual Studio. I’d really like to see this process streamlined a bit so that when you attach a debugger to the web-site it automagically will hit breakpoints in the web-jobs that are part of the overall deployment.


Deploying .NET-based Web Jobs to Windows Azure

I was very excited when I learnt about the new Web Jobs preview feature on Windows Azure Websites. The ability to run separate background processing jobs alongside a web application is one of the critical features of any complex web application.

Amit Apple has a really good article covering the various deployment options for Web Jobs which I would recommend reading. If you are deploying a Node.js (or other script-based) application the convention based deployment model works very well but you might be wondering how you can streamline the deployment of a compiled binary along with your web application.

Managing Web Job Files

Let’s say that you have a .NET solution consisting of an ASP.NET web app and a simple console application. What we want to do is execute the console application as a Web Job, pretty straight forward.


In order to deploy a .NET-based Web Job you need to first compile your .NET code and then drop the executable or its dependencies into the App_Data/jobs directory structure. You could manually compile the files and then copy them into the directory but you are likely going to want to do this 100s of times as you build out the jobs, so you need something a little bit more productive.

One approach that you can take is to edit the *.csproj file for the web job console application itself. If you right mouse click on the console app and select Unload Project, then again to edit the file you can scroll down the bottom and update the AfterBuild build target as in the SimpleWebJob.csproj example below (contents removed to keep the file brief).


In the sample above I’m pushing the executable into the executable into the appropriate folder in the ASP.NET project. A more complete example might include copying configuration files and dependencies as well. You also need to make sure that you include the files that are being copied in the ASP.NET project itself so that they can get pushed up to the server.

Even though the web app isn’t directly referencing the console application, the console app is actually a dependency of a web-app, so you might want to do is right click on the web app project and select Build Dependencies | Project Dependencies to explicitly specify that SimpleWebApp (in my example) depends on SimpleWebJob.


Once this is done you should be able to just publish your project from Visual Studio and the web jobs should automatically be created.

Room for Improvement

The Web Job feature is still in preview so I think it is fair to expect some further evolution in what you can do with Web Jobs. As a .NET developer I hope that the deployment process can be streamlined somewhat for .NET-based executables. Another thing that I would like to see is the ability to deploy a *.webjob file along with everything else in the directory which is used to provide additional metadata about the web job (such as being specific about what file is the entry point along with scheduling data).

Overall though I think it is a welcome improvement to Windows Azure Websites!

Death of the Start Screen Exagerated

It seems like the online media is foaming at the mouth about Windows 8.1 Update 1 supposedly making the move to boot by default to the desktop. The first article I came across was by Steven J. Vaughan-Nichols over at Computerworld followed by an article at Mary Jo Foley over at ZDNet (who gives the topic a much more balanced treatment).

Where Mary Jo Foley stops at reporting the news, Steven’s opinion piece is vitriolic which is typical of his previous articles. I mentioned to one of my co-workers the other day that I was disappointed in the state of tech journalism these days. Alas, there is only so much news to go around which means that content ends up being rehashed – so the only way to stand out is to write an opinion piece, the more bitter the better.

With that out-of-the-way, I have to acknowledge that where there is smoke, there is fire. So what about the rumour that Windows 8.1 Update 1 will boot straight to the desktop. If the rumour is true it is worth stepping back and thinking practically how this might work.

When Microsoft introduced Windows 8.x, the Start Screen didn’t replace the desktop. Rather the Start Screen replaced the Start Menu. The Desktop was always there in the background, it was just as if immediately after login that the Start button had been pressed and a full screen start menu was being displayed.

I suspect that Microsoft might ideally want to just boot to the desktop by default for devices that don’t have a touch first experience (desktop PCs and laptops) leaving touch first devices to boot to the Windows 8-style Start Screen. This would give users balance the best possible experience on their particular devices form-factor.

Some of the press has pointed out that if you boot to the desktop, then how will users know to launch metro-style apps? Well, remember that the Start Screen did not replace the Desktop, it replaced the Start Menu. So when a user presses the start button on the desktop (or on their keyboard) the Start Screen would still be displayed. If this continues to be the case then metro apps would still be discoverable in a desktop environment.

As Mary Jo Foley pointed out, leaked screenshots of the Windows 8.1 Update 1 UX reveal that users will be able pin metro-apps to the start menu. This means that users could quickly switch between legacy desktop apps and modern apps. I suspect that Microsoft has more plans for blending the metro and desktop environments.

I speculate that in a future release (not necessarily Windows 8.1 Update 1) we’ll see metro apps being able to run in floating windows on the desktop along with API support to make apps intelligently respond to this environmental change. Windows Runtime (or WinRT) is the underlying platform for modern metro applications, but that doesn’t mean that you can’t produce a UI in it that is more optimal for a mouse/keyboard user.

The second change we MIGHT see is a Start Menu / Start Screen hybrid. So far the best concept of how this might work I have seen is this start menu/screen transition video which was posted recently (and received great reviews).

What this video hints at is that the theme for phone, tablet and PC operating systems moving forward is convergence. Microsoft has pretty much confirmed this to be the case for Windows and Windows Phone, but I suspect this will also happen with OSX/iOS. Google is an interesting case because they have two quite different approaches to apps in Android and Chrome OS.

For Windows the key ingredient to convergence is Windows Runtime. Not only does Windows Runtime expose the UI building capabilities, but it also surfaces other OS features, file system, networking, sensors etc. WinRT modernizes key aspects of the existing Windows API (in Win32) in a way that is suitable for desktop, tablet and phone.

In summary, I don’t think that booting to the desktop on desktop-style devices spells the end for either metro, or the Windows 8-style start screen. Rather I think it’s just a continued fine-tuning of the user experience to support as broader range as users as possible. Indeed this kind of UX spread is a necessary feature of a single operating system running on a multitude of devices.