Building in Parallel Across Multiple Build Agents in TFS2012 for Metro Apps

By jay at March 30, 2013 12:50 Tags: , , , , , , ,

TL;DR: Using an upgraded (and fixed) Parallel Build Process Template allows to use multiple TFS2012 build agents simultaneously, which can be more than welcome when building metro apps that target all three supported platforms. A build that took 11 minutes can go down to 3.5 minutes.

Download the Parallel Build Process Template for TFS2012 here.


CI is a wonderful feature, especially when associated with Gated Checkins.

You’re certain that what’s in your source control is in line with your build definition and constraints, and that there is always a binary that respects a minimum set of rules. This does not ensure that your app is bug free, but still, that’s a minimum.


Build time matters

The downside of this validation is that there cannot be multiple builds running at the same time. This can become a bottleneck when multiple developers checkin within the duration of a single build run.

This means that the longer your build gets, the longer a developer might wait for its task completion because of a long build queue, and increase its task switching cost. If a build fails, the developer needs to unshelve its changes, make the necessary adjustments, then check-in again.

Below 4 minutes of build time, this stays in the acceptable range where the developer’s task context may not be lost if the build fails.


ReaderWriterLockSlim on Windows Phone 8 and the seemingly random MethodAccessException

By jay at January 13, 2013 15:02 Tags: , ,

TL;DR: Don't use the ReaderWriterLockSlim class on Windows Phone 8 RTM, it has a bug that appears only under contention.

Windows Phone 8’s move to the NT kernel has had a lot of advantages for the developer, such as the move to the same .NET CLR as the Desktop Windows, but also the ability to have multi-core based environment.

More specifically, there is one access synchronization – the ReaderWriterLockSlim – which makes a lot of sense in real multi-core environment.

I’ve been using this class to synchronize access to a dictionary abstraction for performance reasons and also for legacy reasons, since that the Concurrent Collections are available. Note that we do have a new tool in the toolbox, the BCL Immutable Collections, that are becoming my new preferred way for creating collections.


Toying around with F# Queries, Rx, Portables Libraries, Windows [Phone] 8 and the Zip operator

By jay at January 02, 2013 22:42 Tags: , , ,

Agreed, that’s a lot of keywords. Yet, they fit one another in a very interesting way.

I find more and more that F#, particularly regarding the way my development trends are going, is getting more and more of a fit regarding the immutability and flexibility needs.

Given that, I thought I’d give a try at running some F# Query Expressions using custom Rx operators, on Windows Phone 8, using Portable Libraries.


Reading the content of the Xap/Appx and IsoStore in Windows [Phone] 8

By jay at December 20, 2012 09:57 Tags: , , ,

In Windows Phone 8, things got better of the front of reading the file system. It’s actually gotten closer to the Windows 8 with the inclusion of WinRT, and it now possible to read the content of files that were pretty hard (or impossible) to access directly before.


Reading the app package content files

There are some times when you need to access the content of the xap directly, and in Windows Phone 7, you were pretty limited to the use of the IsolatedStorage, but really did not have access to the content of the Xap, except for some location such as images or XmlDocument and the SQL CE engine using the appdata:/ scheme.

Things have changed in Windows Phone 8, and here’s how to read the WMAppManifest.xml file by yourself :


Implementing an asynchronous settings service, Part 2 : Writing a setting

By jay at October 08, 2012 20:12 Tags: , , , , ,

tl;dr: This article is the second of a series talking about the implementation of an async user Settings Service, using the C# async keyword. This part talks about writing new settings values, asynchronously and the challenges associated with it.


In this continuing implementation of a Settings Service series, I'll continue with the addition new features to the service.

Part one talked about reading the settings asynchronously, and this time, we'll talk about writing user settings new values.


Writing to the Settings Service

Now let's say that the user has selected a new temperature unit in a weather app, writing a new value to the settings service takes a few more lines, More...

Implementing an asynchronous settings service, Part 1 : Going Async

By jay at October 07, 2012 21:32 Tags: , , , , ,

TL;DR: This article is part of a series about implementing asynchronous services contract, and starts by an the creation of basic functionality for a User Settings storage service using C# 5.0 async features. In the next episode, we'll talk about writing a user setting and consuming settings change notifications.


Most applications require the storage of user settings, such as the login, authentication token, preferences, you name it. All these settings have been stored in many locations over the years, such ini files, AppSettings, IsolatedStorageSettings in Silverlight and more recently in RoamingStorage or LocalStorage in WinRT, etc…

Most of the time, this is pretty much CRUD-like contracts that do not offer much to perform asynchronous reading/writing, easy two-way data-binding and notifications. Some offer change notifications, but most of the time, this is related to roaming settings that have been updated.

Reading settings in a synchronous way is a common performance issue, and most of the time accessing the data can be expensive, which is not good for the user experience. For instance, the Silverlight and Windows Phone IsolatedStorageSettings implementation has a pretty big performance hit during the first access, due to the internal use of Xml Serialization (and its heavy use of reflection). It also requires to be synchronized during persistence, and its persistence takes a lot of time too, suspending simultaneous read or write operations.

In this article, I’m going to discuss an implementation of a service that abstracts the use of application or users settings using the C# async/await keywords.


[WPDev] The hidden cost of IL Jitting

By jay at December 02, 2011 22:35 Tags: , , , , , , ,

We’ve gotten used to it. Method jitting is negligible. Or is it really ?



The compilation from IL to the native architecture assembly language (or JITting) has been part of the CLR from the very beginning. That’s an operation that was added to make the code execute faster, as interpreting the IL was too slow. By default, it’s happening on the fly, when the code path comes to a method that needs to be jitted, and that impacts the code speed when executing the method the first time.

That compilation step is not exactly free. A lot of code analysis and CPU specific optimizations are performed during this step. This is what arguably makes already JITted code run faster than generic compiled code, where the compiler has no knowledge of the target architecture.

This analysis takes a bit of time, but it is taking less and less time to execute, due to CPUs getting faster, or multi-core JITting features like the one found in .NET 4.5.

We’ve come to a point, on desktop and server machines, where the JIT time is negligible, since it’s gotten fast enough not to be noticed, or be an issue, in the most common scenarios.

Still, if there were times when JITing would be an issue, like it used to be around .NET 1.0, NGEN would come to the rescue. This tool (available in a standard .NET installation) pre-compiles the assemblies for the current platform, and creates native images stored on the disk. When an assembly is NGENed, they appear in the debugger’s “module” window named as “”, along with some other fancy decorations.

But while there are some caveats, like the restrictions with cross assembly method inline being ignored. It always comes down to a balance between start-up speed and code execution speed.


JITing on Windows Phone

On the phone though, CPU is very limited, especially on Generation 1 (Nodo) phones. The platform is too, considering is relative young age. At least on surface.

We’ve got used to create quite a bit of code to ease the development, add levels of abstraction for many common concepts, and lately, for asynchrony.

I’ll take the example of Reactive Extensions (Rx) in this article, just to make a point.

If you execute the following code on a Samsung Focus:

    List<timespan> watch = new List<timespan>();

    var objectObservable = Observable.Empty<object>();

    var w = Stopwatch.StartNew();
    Observable.Timeout<object>(objectObservable, TimeSpan.FromSeconds(1));

    w = Stopwatch.StartNew();
    Observable.Timeout<object>(objectObservable, TimeSpan.FromSeconds(1));

    output.Text = string.Join(", ", watch.Select(t => t.TotalMilliseconds.ToString()));

You'll consistently get something similar to this :

    20.60, 1.19

Calling an Rx method like this does almost nothing, it’s basicallt just setup. But 20ms is a long time ! Particularly when done on the UI thread, or any other thread for that matter.

These rough measurements tend to show that the Windows Phone platform (as of Mango at least) is not performing any NGEN like pre-jitting, leaving the app the burden of jitting code on the fly.

Still, not everything can be accounted to JITing, there must be type metadata loading, type constructors that are called.


Generating code with T4

So to sort that out a bit more, let’s use some T4 templates to generate code and isolate the JIT a bit more :

<#@ template language="C#" #>
using System;
using System.Collections.Generic;

public class Dummy
   public static void Test()
      List<int> list = new List<int>();

      <#for (int i = 0; i < 100; i++) { #>
	  list.Add(<#= i.ToString() #>);
      <#} #>


For different values of iterations, here's what gets out, when timing the call to the method :

Calls First call Subsequent calls
100 1.6ms > 0.03ms
1000 15.7ms > 0.09ms
5000 72.8ms > 2 ms
10000 148ms > 2ms


While this type of code is not exactly a good real-life scenario, this shows a bit the cost the IL jitting step. These are very simple method calls, no branching instructions, no virtual calls, … in short, nothing complex.

But with real code, the IL is a bit more intricate, and there’s got to be more logic involved in the JIT when generating the native code.


Wrapping up

Unfortunately, there’s not much that can be done here, except by reducing the amount of actual lines of IL that are generated. But that can be a though job, particularly when customers are expecting a lot from applications.

One could suggest to push as much code as  possible on a background thread, even code that seemingly does nothing particularly expensive. But that cannot always be performed on an other thread, particularly if that code depends on UI elements.

Finally, pre-jitting assemblies when installing the applications could be an interesting optimization for the Windows Phone platform, and I’m wondering why this has not made its way to the platform yet…

[wpdev] Tips and tricks about updating live tiles in Mango

By jay at September 29, 2011 19:10 Tags: , , , ,

Cet article est aussi disponible en francais.

In the last published applications I've worked on, like Foursquare, Flickr or TuneIn (and more are coming), all of them have live tiles, in both the Pull and locally generated tiles forms. But there are a few things to know to have a great experience with it, and you'll find it out by reading this article.

This is a very powerful feature, letting the user choose how to customize its own very personal experience, with no-one forcing the user into having a tile he does not want. This is the very same reasoning behind the absence of API to add items in Windows 7 task bar.


Live Tiles in Pull mode

In the foursquare app there is the main tile, updated via the "pull" model, every hour or so (and the "or so" has a very strong meaning).

That tile that displays the Leaderboard is built in an Azure cloud service using a WPF offscreen rendering, based on the requests of the tile Pull Engine. This tile was built this way because of the limited capabilities of NoDo, where background agents were not available to render it locally on the device.

With Windows Phone Nodo, many users were complaining about the main tile not updating, and quite frankly, this has been a mystery up to the end. It seems like tiles would update on some devices, but not on others, but would only update if the battery power was more 50%.

Also, these tiles seemed to not update if the device is in standby, but only when the user sees the home screen, and when the suggested refresh delay has expired. I say "seem" because it seems like the rules behind this tile update were either not clear, or broken in some way.

This has changed with mango though. The Pull tiles are not updating almost all the time, but the 50% battery rule still seems to apply.

Also there's the rule of the 80KB file size JPEG, that if you go over, your tile won't be displayed.


Programmatic Live Tiles

In Foursquare, the user may choose to pin a secondary "Tile" a specific place to its main screen for easy access.

Updating these tiles can be acheived with the ShellTile API, and with that you can set four thing:

  • A title for the front and back
  • An image URL on the front and back
  • A four lines text on the back
  • A number on the front
  • (and you forget about the animated tiles like the people hub)


While all these features are interesting, only one of them is actually very useful: Images URL.

All the other properties are not stylable, they only follow the system's colors, and do not fit very well with user generated content. In the case of Foursquare, Flickr and TuneIn, the displayed images is user provided content, and having a white on white text is not very useful.

On the subject of image URLs, setting an external URL sets the image of the tile, but as long as the device does not reboot. If the device is rebooted, the tile looses its content. A pretty strange behavior, if you ask me.


Using the new isostore uri schema

Fortunately, it is now possible to store the image locally in a special folder in the isolated storage named  /Shared/ShellContent, and use the new URI prefix "isostore", like this "isostore:/Shared/ShellContent/MyTile.jpg".

This means that you can download the image to display to the isolated storage, and use it from there.

But there's a big problem with using this technique : You do not control the size of the downloaded image. So if it is bigger than 80KB, you're stuck with the accent color background.

On a side note, I'd be curious to know the story behind this isostore prefix, because there are only two places that can use it, SQL CE Databases and Live Tiles. This prefix cannot be used as a Source property for Image controls, even though it would be very useful. But I digress.


Generating Live Tiles

Hopefully, it's very much possible to generate a complete tile's content, using the WriteableBitmap.Render method. This method allows the offscreen rendering of any UIElement, then save it using the SaveJpeg extension method to persist it.

The tiles for Foursquare, Flickr and TuneIn are generated this way, using a user control that a real designer person created. This gives great looking tiles, and the layout and style can be updated depending on the dynamic content.

Here are a few things to generate tiles :

  • The "new" (kinda) Silverlight 4 ViewBox control is very handy to resize text to fit the 173x173 layout,
  • You can use an Image control in your render source, but you need to wait for the BitmapImage (not the Image) to raise the ImageLoaded event, (The Reactive Extensions can be very handy for that)
  • You'll also need to set the CreateOptions to None on your BitmapImage to make sure the image is downloaded immediately,
  • If you download images, make sure you have a local fallback image underneath, just in case the remote image cannot be downloaded,
  • Before rendering the content, make sure to call Measure and Arrange methods to force the layout to the 173x173 size required by the tiles.
  • You may need to call Measure and Arrange multiple times, because for some obscure reason, the control to be  rendered may not honor these commands. Check for the ActualHeight and ActualWidth properties values to see if they are correct.
  • Make sure to render your tile before pinning it to the home screen ! The app is basically halted when you call the pin command, and the user may not come back to your app for you to finish the image rendering.
  • Don't take too long to render your tile though, if you wait too much, the user experience if pretty bad. That can definitely be a challenge when downloading content to be displayed on the tile.

But then, you may only refresh your tiles when the application is running, unless you use the new Background Agents mango feature.


Updating the tiles with Background Agents

Background agents are Microsoft's way of letting third party apps run code in the background, but with some big restrictions, like memory (4MB), schedule (30 minutes) or duration limits (15 Seconds) for Periodic Tasks.

Here are a few tricks about background agents :

  • Periodic Agents run at a 30 minutes interval, and that is not configurable. So be gentle, you may want to add logic to avoid doing work too often, like not refreshing tiles during the night, and actually update the tile every 3 to 6 hours.
  • Don't wait too much to generate the tile, 15 seconds is very short. And your task may get killed by the OS before that.
  • Don't rely solely on the agent to run to update your tiles, the user may disable your agent using the Settings / Applications / Background Agent page. And the OS may prevent it from running, if it needs to.
  • Abuse of the ScheduledActionService.LaunchForTest, to test your background agent,
  • A background agent runs your code in a different process than your application, meaning that both your app and the agent can run at the same time. Watch out for shared resources, like a SQL CE database or an isolated storage file.
  • If your are updating your tiles in both your application and your background agent, you may need to add some IPC using an old fashion named-Mutex (ahh, the good old days) and synchronize access to your resources.
  • Avoid referencing too many assemblies in your background agent, there are a lot of Unsupported API that may make your app fail certification. You can validate your app using the Marketplace Test Kit automated tests.

About the first point, while I understand the power consumption concerns on running below 30 minutes, I still don't get why that interval cannot be set higher, to avoid that very same power consumption issue. There also must be a story behind this...

Then about the last point, during the Beta Phase of the Mango SDK, the StandardTileData class was considered an unsupported API, making the automatic background update of tiles impossible. Hopefully, this changed since the RC of the SDK and it is now possible to update tiles from background agents.


That's it for now. Have fun with the tiles ! 

[wp7dev] Images and cache control in Windows Phone 7.1 (Mango)

By jay at August 20, 2011 16:39 Tags: , , ,

TLDR: Windows Phone 7.1 Mango's Image control now respects HTTP/1.1 server cache directives, and particularly the max-age, meaning better performing apps. And it is doing it better than you could ever do :)

Image loading is one of the weakest parts of third party apps on Windows Phone 7.0 (NoDo).

The Flickr app in WP7 is a good demonstration of this. The app is basically stalling during the loading of images, and there are (obviously) a lot of images loaded by this app. (The Mango release will make this app really awesome and responsive, I can tell you :))

There are two main reasons for this, being the image loading happening on the UI Thread and partial cache persistence.


Hacking around image loading in NoDo

So if you look around to mitigate those two issues, you'll find a few things like the LowProfileImageLoader from a Microsoftee. This removes a lot of burden from the UI thread by not using the WebClient, and queueing requests to avoid having too many dowloads at the same time.

But like I've discussed before, this is still not the perfect solution because HttpWebRequest still goes on to the UI thread, and when there are many images loaded the UI becomes easily sluggish.

For the image cache part, Silverlight will cache BitmapImage instances based on the Url, will persist them across application runs but will ignore the HTTP/1.1 max-age directive. This means that each time you run the application, the app will try to refresh the image again. It may not be downloaded again, but it still is checked. This may delay a lot the display of the image, because of the wait for the server to check if the image has changed.

If you still want to do some sort of caching without asking the server every time, then you need to handle the storage of downloaded streams and use BitmapSource.SetSource, and perform some in-memory caching of BitmapSource instances to still use the Silverlight cache even if you can't provide an Url. And all this has to be performed on the UI thread. It really does not help.

These are many roadblocks that hurt badly the perceived performance of the application.


Images in Mango

If you try to the same in Mango, doing the background download and caching by yourself, you end up making the matters worse.

Mango has changed everything on that front, and the Product Team has addressed these issues in a very nice way. Loading images is now seamless, you can download as many as you want and UI will not lag a bit.

If you observe the loading of images in mango, you'll quickly see that cached images are displayed almost instantly, primarily because of the cache engine respecting server cache directives. This means that an image will not be checked for a refresh nor downloaded again if the cache duration has not expired.

All this means that you pretty much don't need to do anything to display images in Mango, unless you need to bypass server caching directives.

This is good news :)

Also, Silverlight seems to be doing some work off the UI thread the "user code" (us, mere mortals) cannot do because it needs to be on the UI thread, meaning that you have to let Silverlight do its magic to load images the fastest and seamless way possible.


Image caching in Mango

By looking closer to the way Mango does caching, I've noticed a few things :

  • Images seem to be downloaded once per application run, meaning that server cache directives are ignored until a restart of the application (Fast-resume does not seem to count as a restart),
  • Images that need to be refreshed are checked for modifications on the server, and if an HTTP 302 is sent back, the cached image stays.
  • ETag is supported, the If-None-Match header is sent when the max-age has been reached.
  • If-Modified-Since is also sent when the max-age time span has been reached,
  • When using BitmapCreateOptions.IgnoreImageCache
    • Server cache directives do not seem to be bypassed, the cache is not refreshed until max-age has been reached
    • If Cache-Control max-age and Expires headers are not specified the cache does not seem to be ever refreshed
    • If Expires is specified but not max-age, then the server is called to check for a newer version with If-Modified-Since

These are very good news, since most web server implementation support and respect the HTTP/1.1 Cache-Control directives, meaning that images will be displayed and refreshed properly by default.

[WP7] HttpWebRequest and the Flickr app "Black Screen" issue

By jay at April 22, 2011 14:54 Tags: , , , , ,

TL;DR: While trying to fix the "Black Screen" issue of the Windows Phone 7 flickr app 1.3, I found out that HttpWebRequest is internally making a synchronous call to the UI Thread, making a network call negatively impact the UI. The entire building of an asynchronous web query is performed on the UI thread, and you can't do anything about it.

Edit: This post was formerly named "About the UI Thread performance and HttpWebRequest", but was in fact about Yahoo's Flickr application and was enhanced accordingly.

When programming on Windows Phone 7, you'll hear often that to improve the perceived performance, you'll need to get off of the UI Thread (i.e. the dispatcher) to perform non UI related operations. By good perceived performance, I mean having the UI respond immediately, not stall when some background processing is done.

To acheive this, you'll need to use the common asynchrony techniques like queueing in the ThreadPool, create a new thread, or use the Begin/End pattern.

All of this is very true, and one very good example of bad UI Thread use is the processing of the body of a web request, particularly when using the WebClient where the raised events are in the context of the dispatcher. From a beginner's perspective, not having to care about changing contexts when developing a simple app that updates the UI, provides a particularly good and simple experience.

But that has the annoying effect of degrading the perceived performance of the application, because many parts of the application tend to run on the UI thread.


HttpWebRequest to the rescue ?

You'll find that the HttpWebRequest is a better choice in that regard. It uses the Begin/End pattern and the execution of the AsyncCallback is performed in the context of ThreadPool. This performs the execution of the code in that callback in a way that does not impact the perceived performance of the application.

Using the Reactive Extensions, this can be written like this :

var request = WebRequest.Create("");

var queryBuilder = Observable.FromAsyncPattern(
                                (h, o) => request.BeginGetResponse(h, o),
                                ar => request.EndGetResponse(ar));

                /* Perform the expensive work in the context of the AsyncCall back */
                /* from the WebRequest. This will be the ThreadPool. */
                .Select(response => DoSomeExpensiveWork(response))

                /* Go back to the UI Thread to execute the OnNext method on the subscriber */
                .Subscribe(result => DisplayResult(result));

That way, you'll get most of your code to execute out of the UI thread, where that does not impact the perceived performance of the application.


Why would it not be to the rescue then ?

Actually, it will always be (as of Windows Phone NoDo), but there's a catch. And that's a big deal, from a performance perspective.

Consider this code :

 public App()
  /* some application initialization code */

  ManualResetEvent ev = new ManualResetEvent(false);

  d =>
      var r = WebRequest.Create("");
      r.BeginGetResponse((r2) => { }, null);



This code is basically beginning a request on the thread pool, while blocking the UI thread in the App.xaml.cs file. This makes the construction (but not the actual call on the network) of the WebRequest synchronous, and makes the application wait for the request to begin before showing any page to the user.

While this code is definitely not a best practice, there was a code path in the Flickr 1.3 application that was doing something remotely similar, in a more convoluted way. And if you try it for yourself, you'll find that the application hangs in a deadlock during the startup of the application, meaning that our event is never set.


What's happening ?

If you dig a bit, you'll find that the stack trace for a thread in the thread pool is the following :


The BeginGetResponse method is trying to execute something on the UI thread. And in our example, since the UI thread is blocked by the manual reset event, the application hangs in a deadlock between a resource in the dispatcher and our manual reset event.

This is also the case for the EndGetResponse method.

But if you dig even deeper, you'll find in the version of the System.Windows.dll assembly in the WP7 emulator (the one in the SDK is a stub for all public types), that the BeginGetResponse method is doing all the work of actually building the web query on the UI thread !

That is particularly disturbing. I'm still wondering why that network-only code would need to be executed to UI Thread.


What's the impact then ?

The impact is fairly simple : The more web requests you make, the less your UI will be responsive, both for processing the beginning and the end of a web request. Each call to the methods BeginGetResponse and EndGetResponse implicitly goes to the UI thread.

In the case of Remote Control applications like mine that are trying to have remote mouse control, all are affected by the same lagging behavior of the mouse. That's partially because the UI thread is particularly busy processing Manipulation events, this explains a lot about the performance issues of the web requests performed at the same time, even by using HttpWebRequest instead of WebClient. This also explains why until the user stops touching the screen, the web requests will be strongly slowed down.


The Flickr 1.3 "Black Screen" issue

In the Flickr application for which I've been able to work on, a lot of people were reporting a "black screen" issue, where the application stopped working after a few days.

The application was actually trying to update a resource from the application startup in an asynchronous fashion using the HttpWebRequest. Because of a race condition with an other lock in the application and UI Thread that was waiting in the app's initialization, this resulted in an infinite "Black Screen" that could only be bypassed by reinstalling the application.

Interestingly enough, at this point in the application's initialization, in the App's class constructor, the application is not killed after 10 seconds if it is not showing a page to the user. However, if the application stalls in the constructor of the first page, the application is automatically killed by the OS after something like 10 seconds.

Regarding the use of the UI Thread inside the HttpWebRequest code, applications that are network intensive to get a lot of small web resources like images, this is has a negative impact on the performance. The UI thread is constantly interrupted to process network resources query and responses.


Can I do something about it ?

During the analysis of the emulator version of the System.Windows.dll assembly, I noticed that the BeginGetResponse is checking whether the current context is the UI Thread, and does not push the execution on the dispacther.

This means that if you can group the calls to BeginGetResponse calls in the UI thread, you'll spend less time switching between contexts. That's not the panacea, but at the very least you can gain on this side.


What about future versions of Windows Phone ?

On the good news side, Scott Gu annouced at the Mix 11 that the manipulation events will be moved out the the UI thread, making the UI "buttery smooth" to take his words. This will a lot of applications benefit from this change.

Anyway, let's wait for Mango, I'm guessing that will this will change is a very positive way, and allow us to have high performance apps on the Windows Phone platform.

About me

My name is Jerome Laban, I am a Software Architect, C# MVP and .NET enthustiast from Montréal, QC. You will find my blog on this site, where I'm adding my thoughts on current events, or the things I'm working on, such as the Remote Control for Windows Phone.