To be fair when comparing Rx to C# 5.0 Async...

By Admin at August 03, 2011 20:45 Tags: , , , , ,

After reading the 900th morning brew, one article by mike taulty about comparing Rx, TPL and async caught my attention.

Mike tries to explain the history, differences and similarities between all these frameworks, and kudos, that's not an easy thing to do.

Asynchrony, (and I'm not talking parallelism), is a complex topic that fools even the best of us.


Comparing Rx and Async

Rx and Async and much more similar in that regard, because going off to an other thread is not mandatory, and most operators use either the CurrentThread (timebase priority queue) scheduler or the Immediate (passive wait) scheduler.

This means that the code you are writing is doing some cooperative multi-threading, or fibers-like processing. Everything happens on the same thread, except that work is optionally being queued up, and that thread works as long as there's work left to do, then waits for outstanding operations. These oustanding operations can be I/O completion port bound, like Stream.BeginRead/EndRead.

But back to the comparison, mike is trying to do buffer reading of content from a web response stream, and doing so using the Async CTP's ReadAsync and WriteAsync eases a lot the writing of that kind of code. (Also, the Rx example does not work correctly, but I'll talk about that later in this post.)

These two functions are not tied to the complexity of the BeginRead/EndRead, and behave very much like an IObservable would. Call ReadAsync, you get a Task and wait on it.

Let's jump to the end result and we can get this with Rx based composed operators, using methods symilar to the ReadAsync and GetResponseAsync :

string url = "";

var webRequest = WebRequest.Create(url);

          .SelectMany(wr => wr.GetResponseStream().ToBytes())
            b => Console.WriteLine(Encoding.Default.GetString(b))

That way, it is a lot easier to read. ToResponse maps to GetResponseAsync and ToBytes maps to ReadAsync.

I'll concede the complexity of the SelectMany operator that is related to the fact that IObservable deals with sequences (the duality with IEnumerable). What we would need is more like a IObservableValue that returns only one value. At that point, an appropriate operator would be something like SelectOne, but that's an other topic I'll discuss soon.


The ToResponse operator

This one is easy, and is pretty much an encapsulation of the code provided in Mike's Rx example :

public static IObservable ToResponse(this WebRequest request)
    var asyncGetResponse = Observable.FromAsyncPattern(
                            request.BeginGetResponse, request.EndGetResponse);

    return Observable.Defer(asyncGetResponse);

The use of defer allows the execution of the actual call to GetResponse when someone is subscribing to the deffered observable.


The ToBytes operator

That one is a bit tricker :

public static IObservable ToBytes(this Stream stream)
            observer =>
                byte[] buffer = new byte[24];

                var obsReadFactory = Observable.Defer(() => stream.AsReader()(buffer, 0, buffer.Length));

                return Observable
                         .Select(i => buffer.Take(i).ToArray())

                         // Subscribe on the thread pool, otherwise the repeat operator will operate during the 
                         // call to subscribe, preventing the whole expression to complete properly

                             _ =>
                                 if (_.Length > 0)

and needs a bit of explaining.

The ToBytes extension is creating a Observable that will be able to control finely the OnNext/OnCompleted events, especially because of the loopy nature of the BeginRead API. Loopy means that in a synchronous mode, you needs to call Read through a loop until you get all you need. The BeginRead/EndRead still expose this loopy nature, but in an asynchronous way.

With Rx, that loop can be introduced with the use of Repeat, the same way a while(true) would do.

The Select operator is pretty straightforward, even if it may not be as fast as a Buffer.BlockCopy, it's pretty conscise.

The SubscribeOn is the tricky part of this method, and is very important for the OnCompleted events to get through. If this operator is not present, the call to the ToBytes method blocks in the Subscribe of the SelectMany operator in the final example. This means that events like OnCompleted get buffered and not interpreted, and the repeat operator will continue indefinitely to turns into loops getting nothing, because noone's unsubscribing. This would be CPU consuming, and memory consuming because the observable expression could not get dispose.

Then in the subscribe, we notify the observer that either there's a new buffer, or that we're done because the EndRead method returned 0 (or an exception).


Continuing the comparison

All this to say that the .NET 5.0 (or whatever it will be called) has a Task friendly BCL that makes it easy to write asynchronous code.

I'm definitely not saying that Rx is as easy as Async will be, but, with a minimum of understanding and abstraction, it can be as powerful and even more powerful because of its ability to compose observables.

Now, for the issues in Mike's Rx sample :

  • The TakeWhile operator only completes when the source observable completes, and the source is a Repeat observable, which never ends, meaning that the whole subscription will never get disposed
  • The Observable.Repeat operator runs on the Immediate scheduler, meaning that the OnNext method will be called in the thread context of the original Subscribe, and the expression will not get disposed.

The sample actually shows something, but the CPU will stay at 100% until the process ends.


A word on Asynchrony

Asynchrony is a complex topic, very easy to get wrong, even with the best intentions. Parallelism is even more complex (and don't get me started on the lock() keyword).

I'm expecting that People are going to have a hard time grasping it, and I'm worried that Async will make it too easy to make parallelism (not asynchrony this time) mistakes, because it is will be easy to introduce mutating states in the loop, hence hard to reproduce transitory states bugs. Calling "new Thread()" was scary, and for good reasons, but using await will not, but with mostly the same bad consequences.

I'd rather have better support for immutable structures method or class purity and some more functional concepts baked into C#, where the language makes it harder to make mistakes, than trying to bend (or abstract) asynchrony to make it work with the current state of C#.

Then again, I'm not saying Rx is better, it's trying to work around the fact that the BCL and C# 3.0 don't have asynchrony baked in, so the complexity argument still stands.


On the other side, the more developers use Async, the more developers will need async savvy consultants as firemen :)



[WP7] A nasty concurrency bug in the bundled Reactive Extensions

By Admin at April 21, 2011 20:05 Tags: , , , , ,

The Reactive Extensions have been included in Windows Phone 7, which comes out of the box, and that you can include the Microsoft.Phone.Reactive.dll assembly.


This is a good thing, because it participates in the democratization of the Rx framework, and aside from the fact that the namespace is not exactly the same as the desktop version, Microsoft.Phone.Reactive instead of System.Concurrency and System.Linq, there were no major bugs until recently.

A few applications I've worked on that use the Rx framework, a very interesting unhandled exception was popping-up from time to time in my exception tracker. Unlike the double tap issue I found the same way on my Remote Control application, that one was a bit more tricky, see for yourself :

Exception : System.NullReferenceException: NullReferenceException
at Microsoft.Phone.Reactive.CurrentThreadScheduler.Trampoline.Run()
at Microsoft.Phone.Reactive.CurrentThreadScheduler.EnsureTrampoline(Action action)
at Microsoft.Phone.Reactive.AnonymousObservable`1.Subscribe(IObserver`1 observer)
at Microsoft.Phone.Reactive.ObservableExtensions.Subscribe[TSource](IObservable`1 source, Action`1 onNext, Action`1 onError, Action onCompleted)
at Microsoft.Phone.Reactive.ObservableExtensions.Subscribe[TSource](IObservable`1 source, Action`1 onNext)

This exception popped-up out of nowhere, without anything from the caller that would make that "Trampoline" method fail. No actual parameter passed to the Subscribe method was null, I made sure of that by using a precondition for calling Subscribe.


Well, it turns out that it's actually a bug that is related to the use of the infamous not-supported-but-silent ThreadStaticAttribute, for which I've had to work around to make umbrella work properly on Windows Phone 7.

The lack of a Thread Local Storage creates a concurrency issue around a priority queue that is kept by the CurrentThreadScheduler to perform delayed operations. The system wide queue was accessed by multiple threads at the same time, creating random NullReferenceExceptions.

This means that any call to the Subscribe method may have failed if an other call to that same method was being made at the same time.


In short, do not use the bundled version of Rx in Windows Phone 7 (as of NoDo), but prefer using the latest release from the DevLabs, which does not have this nasty bug.

Revisited with the Reactive Extensions: DataBinding and Updates from multiple Threads

By Admin at July 26, 2010 18:42 Tags: , , ,

Cet article est disponible en francais.

Recently, I wrote an article about WinForms, DataBinding and Updates from multiple threads, where I showed how to externalize the execution of event handler code on the UI thread.

I used a technique based on Action<Action> that takes advantage of closures, and the fact that an action will carry its context down to the point where it is executed. All this with no strings attached.

This concept of externalization can be revisited with the Reactive Extensions, and the IScheduler interface.


The Original Sample

But let's get right to the original code sample :

    public MyController(Action<Action> synchronousInvoker)
        _synchronousInvoker = synchronousInvoker;

This code is the constructor of the controller for my form, and the synchronous invoker action will take something like this :

    _controller = new MyController(a => Invoke(a));

And the invoker lambda is used like this :

        () => PropertyChanged(this, new PropertyChangedEventArgs("Status"))

Where Invoke is actually Control.Invoke(), used to execute code on the UI Thread where updates to the UI controls can be safely executed.

While the Action<Action> trick is working just fine in acheiving the isolation of concerns, it is not very obvious just by looking at the constructor signature what you are supposed to pass to it.


Using the IScheduler interface

To be able to abstract the location used to execute the content of Reactive operators, the Rx team introduced the concept of Scheduler, with a bunch of default scheduler implementations.

It basically exposes an abstracted way for users of the IScheduler instance to schedule the execution of a method in the specific way defined by the scheduler. In our case, we want to execute our handler code on the WinForms message pump, and "there's a scheduler for that".

The sample can be easily updated to use the IScheduler instead of the Action<Action> delegate, and make use of the IScheduler.Schedule() method.

    public MyController(ISheduler scheduler)
        _scheduler = scheduler;

And replace the call by :

        () => PropertyChanged(this, new PropertyChangedEventArgs("Status"))

Not a very complex modification, but it is far more readable.

And we can use the provided scheduler for the Winforms, the yet undocumented System.Concurrency.ControlScheduler which is not in the Scheduler class because it cannot be created statically and requires a Control instance :

    _controller = new MyController(new ControlScheduler(this));

where this is an instance of a control.

This is much better, and for the unit testing of the Controller, you can easily use the System.Concurrency.CurrentThreadScheduler, because you don't need to switch threads in this context.


What about the Reactive Extensions and Silverlight for Windows Phone 7 ?

In a very strange move, the WP7 team moved the IScheduler class from System.Concurrency to the very specific Microsoft.Phone.Reactive namespace.

I do not quite understand the change of namespace, and it makes code that used to compile easily on both platforms not compatible.

Maybe they considered the Reactive Extensions implementation for Windows Phone too different from the desktop implementation... But the compact framework was built around that assertion, and most of the common code stays in the same namespaces.

If someone has an explanation for that strange refactoring, I'm listening :)

[WP7Dev] Beware of the [ThreadStatic] attribute on Silverlight for Windows Phone 7

By Admin at June 19, 2010 21:36 Tags: , , , , , , ,

Cet article est disponible en francais.

In other words, it is not supported !

And the worst in all this is that you don’t even get warned that it’s not supported... The code compiles, but the attribute has no effect at all ! Granted that you can read the msdn article about the differences between silverlight on Windows and Windows Phone, but well, you may still miss it. Maybe a custom code analysis rule could prevent this.

Still, you want to use ThreadStatic because you probably need it, somehow. But since it is not supported, you could try the Thread.GetNamedDataSlot, mind you.

Well, too bad. It’s not supported either.

That leaves us implementing or own TLS implementation, by hand...


Updating Umbrella for Silverlight on Windows Phone

I’m a big fan of Umbrella, and the first time I had to use Dictionary<>.TryGetValue and its magically aweful out parameter in my attempt to rewrite my Remote Control app for Windows Phone 7, I decided to port Umbrella to it. So I could use GetValueOrDefault without rewriting it, again.

I managed to get almost all the desktop unit tests to pass, except for those who emit code, use web features, use xml and binary serializers, call private methods using reflection, and so on.

There are a few parts where the code needed to be updated, because TypeDescriptor class is not available on WP7, you have to crash and burn to see if a value is convertible from one type to the other. But that’s not too bad, it works as expected.


Umbrella’s ThreadLocalSource

Umbrella has this nice ThreadLocalSource class that wraps the TLS behavior, and you can easily create a static variable of that type instead of the ThreadStatic static variable.

The Umbrella quick start samples make that kind of use for it :

    ISource<int> threadLocal = new ThreadLocalSource<int>(1);

    int valueOnOtherThread = 0;

    Thread thread = new Thread(() => valueOnOtherThread = threadLocal.Value);

    Assert.Equal(1, threadLocal.Value);
    Assert.Equal(0, valueOnOtherThread);

The main thread set the value to 1, and the other thread tries to get the same value from the other thread and it should be different (the default value of an int, which is 0).


Updating the ThreadLocalSource to avoid the use of ThreadStatic

The TLS in .NET is basically a dictionary of string/object pairs that is attached to each running threads. So, to mimic this, we just need to make a list of all threads that want to store something for themselves and wrap it nicely.

We can create a variable of this type :

    private static Tuple<WeakReference, IDictionary<string, T>>[] _tls;

That variable is intentionally an array to try to make use of memory spacial locality, and since on that platform we won’t get a lot of threads, this should be fine when we got through the array to find one. This approach is trying to be lockless, by using a retry mechanism to update the array. The WeakReference is used to avoid keeping a reference to the thread after it has been terminated.

So, to update the array, we can do as follows :

    private static IDictionary<string, T> GetValuesForThread(Thread thread)
        // Find the TLS for the specified thread
        var query = from entry in _tls

                    // Only get threads that are still alive
                    let t = entry.T.Target as Thread

                    // Get the requested thread
                    where t != null && t == thread
                    select entry.U;

        var localStorage = query.FirstOrDefault();

        if (localStorage == null)
            bool success = false;

            // The storage for the new Thread
            localStorage = new Dictionary<string, T>();

                // store the original array so we can check later if there has not
                // been anyone that has updated the array at the same time we did
                var originalTls = _tls;

                var newTls = new List<Tuple<WeakReference, IDictionary<string, T>>>();

                // Add the slots for which threads references are still alive
                newTls.AddRange(_tls.Where(t => t.T.IsAlive));

                var newSlot = new Tuple<WeakReference, IDictionary<string, T>>()
                    T = new WeakReference(thread),
                    U = localStorage


                // If no other thread has changed the array, replace it.
                success = Interlocked.CompareExchange(ref _tls, newTls.ToArray(), originalTls) != _tls;

        return localStorage;

Instead of the array, another dictionary could be created but I’m not sure of the actual performance improvement that would provide, particularly for very small arrays.

Using a lockless approach like this one will most likely limit the contention around the use of that TLS-like class. There may be, from time to time, computations that are performed multiple times in case of race conditions on the update of the _tls array, but that is completely acceptable. Additionally, livelocks are also out of the picture on that kind of preemptive systems.

I think developing on that platform is going to be fully of little workarounds like this one... This is going to be fun !

[VS2010] How to disable the Power Tools Ctrl+Click Go to Definition

By Admin at June 13, 2010 17:17 Tags: ,

Last week, Microsoft released the Visual Studio 2010 Productivity Power Tool Extensions, which includes a lot of features that probably should have made it to the VS2010 RTM, but somehow did not.


A must install, really. Just for the fixed Add Reference dialog that includes a search filter. A big time saver.


But there’s also an other feature, the Ctrl+Click Go to Definition that allows to go to the definition with a single left click (the F12 key in the default keyboard bindings).


If you’re like me, you may be lazy enough to let the text editor select complete words and you’re probably using Ctrl + left lick to select words so you don’t have to aim too much with the mouse pointer. That particular Power Tools feature conflicts directly with it and you end up constantly going to the definition of types when you want to select text... And that’s pretty annoying.


There does not seem to be a way to disable that feature from the IDE, so you may well disable it the hard way :

  • Go to C:\Users\USER_NAME\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\Microsoft\Visual Studio 2010 Pro Power Tools\10.0.10602.2200
  • Remove or rename the GoToDefProPack.dll file.
  • Enjoy your complete word selection again !

Have fun :)

Thoughts on Migrating from WSS 3.0 to SharePoint Foundation 2010

By Admin at June 03, 2010 21:31 Tags: ,

Cet article est disponible en francais.

I upgraded recently a WSS 3.0 Farm to Sharepoint Foundation 2010, I tought I’d share some of notes and pitfalls I found during the upgrade.

My setup is built around two Windows Server 2008 R2 64 Bits VMs hosted on Hyper-V Server R2, one VM for the frontend, one for the Database (SQL Server 2008 SP1 64 Bits) and the Search Server Express.


Hyper-V Assisted Upgrade

Having the setup built on Hyper-V saved me a great deal of time, primarily by the use of snapshots taken at the same time on both machines. This helped a lot to be able to experiment directly on the production system during an expected downtime for the users.

The snapshots allow a trial and error process that lead to a somehow “perfect” environment where mistakes can be reversed pretty easily. Ugrading using this snapshot technique is however pratical only with enough disk space and a reasonable content database size depending on the physical hardware.



Here are the steps I followed to perform the upgrade :

  • Made clones of both machines in a VM library, just to be safe in case the Hyper-V messed up the VMs because of the snapshots (you never know)
  • Upgraded WSS 3.0 with latest Cumulative Updates (KB978396)
  • Downloaded Sharepoint Foundation and Search Server Express packages
  • Installed the prerequisites of Sharepoint Foundation on both VMs (not Search Servers prerequisistes, which do not install properly, and are seemingly the same as the SPF package)
  • Installed SQL Server 2008 SP1 Cumulative Updates KB970315 and KB976761 (in this order)

That’s the easy part, where updates do not impact the running farm.

I took a snapshot of both VMs at this point.


Upgrading SharePoint and Search Server

You may want to read information on this on technet, which is very extensive.

Now, the Sharepoint upgrade :

  • Put a site lock in place (just in case a user might try to update stuff he’d probably lose)
    • stsadm -o setsitelock -url http://site -lock readonly
  • Detached the content databases using : (See later for the explanation of this step)  :
    • stsadm.exe -o deletecontentdb -url http://site –databasename WSS_Content
  • Backup the content DB so they can be upgraded on an freshly installed SPF2010 setup.
  • Executed the Search Server Express setup on both machines, without configuring it
  • Upgraded Sharepoint Foundation setup, without configuring it
  • On the frontend VM (so the admin site can track the update jobs), ran the Sharepoint Configuration wizard to perform the upgrade. I selected the Visual Upgrade so the site collections templates would use the new visual style (Ribbon powered !)
  • After the configuration ended on the frontend machine, ran the same wizard on the database VM.
  • Let the jobs run and finish properly.
  • On a temporary empty SPF 2010 setup on a spare VM, mounted the backed up content DB and ran this powershell command :
    • Mount-SPContentDatabase -Name WSS_Content -DatabaseServer -WebApplication http://site –Updateuserexperience
    • You may require to install the templates used on your production environment to perform the upgrade properly.
  • After the content db upgrade ended, detached the content database using the admin site (beware of the dependencies between content DBs if you have more than one)
  • Backuped up the content DB.
  • On the production Farm, dropped and recreated the appropriate Web Application without any site collection. I did this step to make sure the AppPools and sites were configured properly.
  • Restored and attached the content DB on the production server using the SPF admin site.

Now, I did perform the “Attach/detach” procedure because it can be performed in parallel on multiple farms if the content databases are huge, and on my production setup, the in-place upgrade did not work properly. The images libraries where not upgraded properly (images where not displayed), and the default pages did not render properly for some obscure reason.


A few additional gotchas

  • I had a few other issues with the search SSP, where I needed to remove completely the Search SSP and recreate it to avoid this error :
    • CoreResultsWebPart::OnInit: Exception initializing: System.NullReferenceException
  • The search SSP needs uses of the Security Token Service Application, which by default does use the “Extended Security” setting, which needs to be turned off in IIS.
  • Since I use Search Server Express, Content Databases must not select the search provider named “Sharepoint Foundation Search Server” for the search to work properly.


Upgraded Wikis

You’ll find the the wiki editor has been greatly enhanced, and you’ll find it even more powerful when you select the “Convert to XHTML” option in the html menu of the ribbon. The original pages were using the very loose HTML 4.0, which does not seem to work very well.

Other than that, everything else works very fine in this area.


Upgraded Discussion Boards

I had a few discussion boards that had issues with the view of individual conversations using the threaded view. The conversation were defaulted to the default “subject” view, which is not applicable to view single threads. To fix this, make a new “subject” view and delete the previous one the normal behavior will come back.


Happy SharePointing ! Now I can go back to my Immutability and F# stuff :)

Remote Control for PowerPoint 1.0 !

By Admin at April 10, 2010 17:36 Tags: ,

After an intense (and long) process of certification of my remote control application on the Windows Phone MarketPlace, the app has been accepted !

You can find the app on the MarketPlace, and it is simply called "Remote Control" for PowerPoint. The application has been published in the US English market for now, and if you're not in the US, just choose the US English in the "World View" at the bottom.

The published app is only a sort of test run for me, and only has the capability to control PowerPoint. I'll be adding more controllable applications in the future, depending on the market reception of the app.

As I previous said in this blog, here are the new features and enhancement of this new version :

  • Improved performance
  • Support for High DPI and VGA devices
  • Windows 7 support
  • 64 Bits compatibility
  • Support for Wifi, which is more marketing abuse, and is actually TCP support
  • Support for touch screen devices, those who do not have enough hardware keys

The US English market is the only available market, for now. Other markets are still waiting to be approved, and will be :

  • Canada, UK, India, Australia for English
  • France and Canada for the French localized version

The french part certification is somewhat obscure for me, and I expecting certification surprises...

I'll also add Portugese and Spanish version in a near future.

If you were waiting for this new version, visit and please let me know what you think !

[VS2010] “Object reference not set to an instance of an object” when opening a file

By admin at October 23, 2009 20:19 Tags:

If you’re trying out Visual Studio 2010, and you try to open source code file with the “Solution Explorer”, you might encounter a nice exception like this one :

Microsoft Visual Studio
Object reference not set to an instance of an object.

That could not be more vague..

After a small debugger analysis, it seems like VS2010 does not support TrueType fonts, but does not prevent their selection in the font selection dialog.

I was using “Proggy Opti Small” with VS2008, which is not TrueType... So to be able to open you source files, use a font like Consolas, and restart VS2010.

A bug report exists on Connect.

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.