This is a minor update from Rx.NET v2.2.3 which includes two fixes. First is the support for Windows Universal libraries, and the second is ReplaySubject performance enhancements. With the help from the community, we are moving the Reactive Extensions forward and we have plenty more coming soon.

Windows Universal Support

With the release of Windows Phone 8.1, it is now possible to use the Windows Runtime to build apps that can target each form factor in the family of Windows devices. Using the universal Windows app project templates, you can now create one app where your business logic can be surfaced up through a user experience relevant to the device. This unified approach to app development means that your app has the potential to reach not just Windows phones and tablets, but Windows laptops and workstations as well.

Previously, our NuGet packages did not support Universal Windows Apps, but now, thanks to work from Paul Betts, you can now write Universal Apps using the Reactive Extensions.

ReplaySubject Performance Enhancements

During the development of the Reactive Extensions version 2.0+, we have had a focus on performance as noted in Bart de Smet's post on the Reactive Extensions Team Blog. One of the overlooked areas of the performance work we did as Subjects. We had the community step up in this regard to helping performance better on the ReplaySubject. The details are laid out in this very detailed blog post.  Many thanks to Lee Campbell for his hard work for this feature.

Patterns in Using Generic Virtual Methods Issues

Some patterns in using generic virtual methods may cause increases in compilation time and size on disk when used with Microsoft pre-compilation technologies such as NGEN. This bug fix removes those patterns so that Microsoft pre-compilation technologies such as NGEN work better with the Reactive Extensions library. This change was tested and found to have no noticeable performance impact, other than stabilizing compilation times and the size on disk.

Closed Issues

• #4 - Add Windows Universal support
• #3 - Adding ReplaySubject perf improvements

Changelog

• 4be7549 - Updating import.targets for flattening
• d56e5d1 - Add Wpa81 to BuildAll.proj
• 7041c40 - Universal Unit Tests aren't A Thing yet
• b94b695 - Add Configurations for Wpa81
• 03368da - Add a Windows 8.1 + Windows Phone 8.1 Target
• 7ea7fbb - Some patterns in using generic virtual methods may cause increases in compilation time and memory usage
• 0815ac7 - Included multiple disposals to Replay UnitTests
• 98ad574 - Remove comments
• 5449869 - Adding ReplaySubject perf improvements
• 044afd5 - Use background thread for long-running ThreadPoolScheduler

Of course, it cannot be said that there wasn’t change with the Reactive Extensions Team, as Erik Meijer, the founder of the Reactive Extensions, LINQ and many other contributions, left Microsoft so that he could work on Rx on the outside, helping with adoption.  We continue as a team to work closely with him and the community on the future direction of Rx.

Going Open Source

As we announced back in November 2012, in conjunction with MS Open Tech, the Reactive Extensions for .NET, C++ and JavaScript were released as open source under the Apache 2 license on both CodePlex and GitHub.  Since that time, we’ve released a number of other languages which now include:

• .NET (CodePlex | GitHub)
• C++ - WinRT, MSVC and Clang (CodePlex | GitHub)
• JavaScript (CodePlex | GitHub)
• Python 3.x (CodePlex | GitHub)
• Ruby (CodePlex | GitHub)

Some are more complete than others, but we’d love the community’s support with making these libraries better.  Contributing has never been easier to the Rx projects has never been easier.  You can contribute to Rx with examples, documentation, code, tests.  Simply sign the CLA and be a part of Rx!

RxJava

Another great result of our open source work has been the collaboration with such companies as Netflix.  The Netflix engineering team are big fans of the Reactive Extensions, and decided to port the Rx to the JVM in a project called RxJava so that their engineering teams can use Rx on both the client and the server.  It currently supports Java 5+, Clojure, Scala and Groovy.  The Netflix API takes advantage of RxJava, exposing all service methods to return Observable<T>, which allows for flexible composition, and concurrency safety. 

The RxJava project has enabled Netflix developers to leverage server-side concurrency without the typical thread-safety and synchronization concerns. The API service layer implementation has control over concurrency primitives, which enables us to pursue system performance improvements without fear of breaking client code.

Conferences

Late 2012 and through 2013 was a busy year for the Reactive Extensions team for presentations.  In addition, we’ll also be making an appearance at CodeMash in Sandusky, OH.

• CascadiaJS – Don’t Cross the Streams
• Strange Loop – Curing Your Event Processing Blues with Rx (demos)
• QCon San Francisco
• Functional Reactive Programming in JavaScript Tutorial
• CodeMesh
• Reactive Programming in JavaScript Tutorial (with Jafar Husain)
• End to End Reactive Programming at Netflix (with Jafar Husain)
• NDC London
• Democratizing event processing at all scales and platforms with the Reactive Extensions (with Jafar Husain)

The Netflix team has also been quite busy giving presentations not only on RxJava, but also RxJS, which they frequently use as well. These are great presentations that show how a company with scaling needs such as Netflix uses Rx across all platforms and both on the client and server.

• LambdaJam Chicago – Functional Reactive Programming in the Netflix API (Ben Christensen)
• QCon San Francisco
• Reactive JavaScript at Netflix (Jafar Husain)
• Evolution of the Netflix API (Ben Christensen)

Release of Rx v2.2

This year also saw the release of Rx v2.2 for .NET, C++ and JavaScript, which was announced on this blog here and here.  What was great about these releases is that a lot of the material for this release was specifically driven by the community.  So, a big thank you to the community for participating and moving Rx forward! 

Promises for the New Year

This year, 2014, promises to be another great year for the Reactive Extensions team with a focus on many things such as:

• Version 2.3 with ideas around backpressure and other concerns
• Language parity with Python, Ruby and C++ versions
• New languages supported
• And yes, more blogging

Although we don’t blog as much, you can always catch us on Twitter at @ReactiveX!  We publish lots of information about Rx and what we’re up to, so follow us!

Documentation

Perhaps the biggest change of all is the documentation which can be found here.  This complete set of documentation not only includes the complete RxJS API, but also many things to help get you started with RxJS such as:

• Getting Started
• Getting to Know the RxJS libraries
• How To Guides
• Mapping from Other Libraries
• API Documentation

All of this is a work in progress, and we’ve had a tremendous amount of support from the community in helping our documentation and examples.  Have a sample you want to contribute or some documentation on mapping from your favorite library?  Send us a pull request and we’ll work with you to get it included!

Compatibility

RxJS has strived for in the past to support both modern browsers in addition to legacy browsers dating back to IE6.  Like many other projects like jQuery, Lo-Dash among others have started to break with the past, but to also support legacy browsers.  RxJS is no exception to this and as of version 2.2, rx.js will now only work with ES5 compatible browsers.  In order to continue support for legacy browsers, we will ship rx.compat.js which adds polyfills for older browsers.

Batteries Included

Starting with this release, we made a number of changes, moving non-pertinent things out of the core rx.js file, such as the notion of virtual time and asynchronous functions.  This resulted in the creation of two new files, rx.async.js and rx.virtualtime.js.

rx.async.js

A common request for RxJS was to include some bridges to such things as events, callbacks and Promises all in the core library.  We’ve enabled this through the rx.async.js library to enable you to bind to any number of sources.  By default, rx.async.js only works with ES5 compliant browsers, but as we mentioned above, backwards compatibility is important to us, so we’ve also included rx.async.compat.js which normalizes event behavior between browsers.

You can now bind to events using Rx.Observable.fromEvent. 

var block = document.getElementById('block');

// Get all events
var mousemoves = Rx.Observable.fromEvent(block, 'mousemove'),
    mousedowns = Rx.Observable.fromEvent(document, 'mousedown'),
    mouseups = Rx.Observable.fromEvent(block, 'mouseup');

// Create a drag event
var drag = mousdowns.selectMany(mousemoves.takeUntil(mouseups));

Alternatively, there may be cases in which you would like to use existing libraries or patterns to create events.  To that end, we’ve created Rx.Observable.fromEventPattern, which takes two functions, one for subscribe and one for unsubscribe.

In this example, we can wrap jQuery’s on method using Rx.Observable.fromEventPattern.

var $input = $('#input');
var data = { name: 'RxJS' };

var clicks = Rx.Observable.fromEventPattern(
    function add (h) {
        $('input').on('click', data , h);
    },
    function remove (h) {
        $('input').off('click', h); 
    });

clicks.subscribe(function (e) {
    console.log(e.data.name);
});

Promises are a great pattern for dealing single value asynchronous computations.  They can be found in any number of libraries such as Angular, jQuery, Dojo, WinJS, and even libraries dedicated to them such as Q or when.js.  Promises are even making their way into the next version of ECMAScript.  Naturally, we would like a way to bridge natively towards a common standard of the Promises A+ spec in RxJS.

In this example, we can query Wikipedia by wrapping the jQuery ajax method with the Rx.Observable.fromPromise method.

function searchWikipedia (term) {
    var promise = $.ajax({
        url: 'http://en.wikipedia.org/w/api.php',
        dataType: 'jsonp',
        data: {
            action: 'opensearch',
            format: 'json',
            search: encodeURI(term)
        }
    }).promise();

    return Rx.Observable.fromPromise(promise);
}

Callbacks are also a way of life with JavaScript, especially true in Node.js.  In RxJS version 2.2, you have multiple ways of binding to callbacks, first a standard callback, and then secondly a Node.js-style callback in which the error is always the first parameter to the callback function.

In this first example, we can determine whether a file exists by wrapping the fs.exists function, which has a callback which only returns a Boolean as to whether the file exists.  Since it only has a single value and no error, we can use the Rx.Observable.fromCallback method.

var Rx = require('rx');
var fs = require('fs');
var path = require('path');

var fileName = path.join(__dirname, 'file.txt');

// Wrap the function
var exists = Rx.Observable.fromCallback(fs.exists);

// Call the function and then subscribe to get the result
exists(fileName).subscribe(function (result) {
    console.log('File exists? ' + result);
});

That covers one case, but we want to handle cases in which errors are automatically handled for us by RxJS.  We can wrap Node.js error style callbacks easily with the Rx.Observable.fromNodeCallback method.  The next example, we’ll wrap the fs.stat function to get the file statistics. 

var Rx = require('rx');
var fs = require('fs');
var path = require('path');

var file = path.join(__dirname, 'file.txt');

// Wrap stat
var stat = Rx.Observable.fromNodeCallback(fs.stat);

// Run stat, get results and check for errors
var subscription = stat(file).subscribe(
    function (fsStat) {
        console.log('Is file? ' + fsStat.isFile());
    },
    function (err) {
        console.log('Error: ' + err);
    }
);

In addition to this, we also moved Rx.Observable.toAsync and Rx.Observable.start out of core and into rx.async.js.

rx.virtualtime.js

As above, we are very conscious of the size of files that we ship as part of RxJS, so another piece that was removed from core was the notion of virtual time.  Both the VirtualTimeScheduler and HistoricalScheduler were moved to this file.

In order to continue to make your tests work, you will need to add rx.virtualtime.js along with rx.testing.js as shown here.

<script src="rx.js"></script>
<script src="rx.virtualtime.js"></script>
<script src="rx.testing.js"></script>

<script>
test('map should produce values', function () {
    var scheduler = new TestScheduler();

    // Set up sequence to run through  
    var xs = scheduler.createHotObservable(
        Rx.ReactiveTest.onNext(210, 1),
        Rx.ReactiveTest.onNext(220, 2),
        Rx.ReactiveTest.onCompleted(230)
    );

    // Run computation
    var results = scheduler.startWithCreate(function () {
        return xs.map(function (x) { return x * x; });
    });

    // Assert using custom assertions
    assertCollectionEqual(results, [
        Rx.ReactiveTest.onNext(210, 1),
        Rx.ReactiveTest.onNext(220, 4),
        Rx.ReactiveTest.onCompleted(230)
    ]);
});
</script>

This also gives us more flexibility to define more virtual time based schedulers in the future.

Going Lite

A common ask of the team is to create a “bite sized” version of RxJS which contains most of the operators that one would need on a daily basis.  Instead of the a la carte tradition of RxJS, using only the pieces you need, this build has the most commonly used operators from factory methods, standard query operators, time-based operators, binding operators such as multicast, and async operators such as Rx.Observable.fromEvent, Rx.Observable.fromPromise and more in the form of rx.lite.js.  We also have a compatibility version which supports older browsers in rx.lite.compat.js.  The size of the entire library is about 7kb gzipped, which offers a lot of possibilities without much cost.

With this capability, we now have the ability to write our complete autocomplete example without needing any external library other than one to provide us Ajax support.

<script src="jquery.com"></script>
<script src="rx.lite.js"></script>
<script>
// Search Wikipedia using jQuery JSONP
function searchWikipedia (term) {
    var promise = $.ajax({
        url: 'http://en.wikipedia.org/w/api.php',
        dataType: 'jsonp',
        data: {
            action: 'opensearch',
            format: 'json',
            search: encodeURI(term)
        }
    }).promise();
    return Rx.Observable.fromPromise(promise);
}

var $input = $('#input'),
    $results = $('#results');

// Get the data from the text field
var text = Rx.Observable.fromEvent(input, 'keyup')
    .map(function (e) {
        return e.target.value;
    })
    .filter(function (text) {
        return text.length > 2;
    })
    .throttle(500)
    .distinctUntilChanged();

var subscription = text.flatMapLatest(searchWikipedia).subscribe(
    function (results) {
        // Bind results to UI
    },
    function (err) {
        // Handle error
    });
</script>

We’re working on making custom builds so that you can create your own lite version using the operators that you need.  Stay tuned for that.

Breaking Changes

With all of these changes, we had a few breaking changes, for example:

• Rx.Observable.toAsync moved to rx.async.js
• Rx.Observable.start moved to rx.async.js
• Rx.HistoricalScheduler moved to rx.virtualtime.js
• Rx.VirtualTimeScheduler moved to rx.virtualtime.js

In addition, the behavior of Rx.Observable.prototype.scan was also changed as it was in the Reactive Extensions for .NET.  This is to reflect behavior found in other languages such as F#, Haskell and others.  The basic rule is, if you have an empty observable sequence with a seed, then you should yield that seed, else if it is an empty sequence with no seed, it should be an empty sequence.  This breaks from the old behavior which yielded nothing with an empty observable sequence even when it had a seed.

function add(x, y) {
    return x + y;
}

// With seed
Rx.Observable.empty().scan(add, 0)
    .subscribe(console.log.bind(console));
// => 0

// Without seed
Rx.Observable.empty().scan(add)
    .subscribe(console.log.bind(console));
// => Nothing

We will try in the future to keep breaking changes to a minimum as we continue to innovate with the Reactive Extensions.

Get It Now

There are many ways of getting RxJS, including through:

• NPM
• Bower
• Jam
• NuGet
• cdnjs or jsdelivr CDNs
• GitHub or CodePlex

We’re Not Done Yet

Even though we accomplished a lot in this release, we are by no means done.  In fact, we have plenty that we are researching for our next version which could include the following:

• Query expression parsing to create LINQ to IndexedDB, OData, etc
• Backpressure to handle situations when the Observer cannot keep up
• And much more.

As always, we’d like to hear from you as to what’s important with the Reactive Extensions for JavaScript, so let us know through our forum, our blogs, and our CodePlex and GitHub repos.

Conclusion

We were able to accomplish quite a bit with this release of RxJS 2.2, and the future is quite bright with it.  We are working with our partners including Netflix on how we can improve the library, and best of all, make it approachable for just about anybody.  We’d love to hear what you think!

Today Microsoft Open Technologies, Inc. (MS Open Tech), is happy to share the news of recent improvements we have made to Reactive Extensions.

Rx 2.2 is now available via the Rx CodePlex project and includes more support for Windows Phone 8, various bug fixes and contributions from the community.

For more about the release, see the release notes for Rx.NET 2.2 and the MS Open Tech blog post.

We have updated the Reactive Extensions for .NET, primarily to re-enable Windows Phone 8 support.  We ran into a bug with a partner team's tooling and the strong name crypto key we use to sign Rx.  To work around the problem, we had to change the crypto key back from a SHA-2 key to the SHA-1 key we used with Rx previously.  This affected our portable library and other flavors of Rx, so we recommend that you download a new version and recompile everything that depends on Rx. 

Additionally, we have decided to simplify our distribution story for developers.  Rx 2.1 binaries are available only on NuGet.  You can easily get this in Visual Studio by right clicking in your project's References tab and selecting "Manage NuGet packages..." then typing Rx in the search box.  Alternately, you can go to NuGet.org and use their package manager to install Rx on the command line if you desire.  Or you can grab the source from CodePlex and run with it.

Beyond the new strong name key, we've made a few minor additions:

*) Added several SelectMany overloads that provide you with indices, so you know which element in an IObservable or IEnumerable you're dealing with.  The simple overloads look like this:

 IObservable<TResult> SelectMany<TSource, TResult>(
     IObservable<TSource> source, 
     Func<TSource, int, IObservable<TResult>> selector);
 

The more complex ones look like this:

 IObservable<TResult> SelectMany<TSource, TCollection, TResult>(
     IObservable<TSource> source, 
     Func<TSource, int, IObservable<TCollection>> collectionSelector,
     Func<TSource, int, TCollection, int, TResult> resultSelector);

*) Added helper methods for dealing with anonymous types.  If you want to create instances of a generic type using an anonymous type as the type argument, that's not expressible in some languages like C#.  Instead, we can create a static generic method on a non-generic type that serves as a factory method and uses type inference to work around the lack of any name for the anonymous type.  Consider the following illegal and legal examples:

 DateTimeOffset time = ...;
 var anonType = new { x = 5, y = "hi" };
 var v = new Timestamped<typeof(anonType)>(anonType, time); // illegal
 var v = Timestamped.Create(anonType, time); // legal
 

We used the anonymous type trick while testing SelectMany too!

Enjoy!

In order to stop the problem from impacting more developers (discovering the problem only during deployment to physical devices, typically late in a development cycle), we’ve decided to temporarily pull the Rx v2.0 for Windows Phone 8 binaries from the Visual Studio Gallery and NuGet, until a fix is available.

We apologize for the inconvenience this is causing and will post updates as we’re working towards resolving this issue. In the meantime, the Rx v2.0 for Windows Phone 7 binaries can be used for Windows Phone 8 projects. While those binaries are compatible with Windows Phone 8, they won’t contain Rx’s Task<T> support and a variety of other enhancements.

This post will focus on what’s inside and how you can get started.

Getting the Reactive Extensions for JavaScript

The Reactive Extensions for JavaScript consists of a number of files, which you can include based upon the functionality you want.  This keeps the size of your includes down significantly, where you may only end up using a few of the many Observable operators we support.  Currently, we ship three variations of each file, a source version, a Visual Studio Documentation (VSDoc) version and the minimized version.

RxJS consists of the following files and we’ll cover the details of each in subsequent posts:

• rx.js – the  main library for the Reactive Extensions
• rx.aggregates.js – aggregation operators such as min/max, count, sum, and average
• rx.binding.js – binding operators such as multicast, publish and replay
• rx.coincidence.js – coincidence operators such as join, and groupJoin
• rx.experimental.js – experimental operators such as the imperative operators and forkJoin
• rx.joinpatterns.js – join pattern calculus implementation
• rx.testing.js – used to write unit tests for complex processing queries
• rx.time.js – time-based event processing query operations

You have a number of ways of getting RxJS including a direct download from MSDN, NuGet NPM via Node.js, and as well on our GitHub page.

Installing with NuGet

The first option of getting RxJS is through NuGet.  Starting with Visual Studio 2012, NuGet is automatically built in, but for previous versions you can install via www.nuget.org.  We have a number of packages in NuGet which correspond to the names of our files from above.  Each package contains the source file, as well as the documentation via a VSDoc file, and a minimized version. 

We ship the following packages in NuGet:

• RxJS-All
• RxJS-Main
• RxJS-Aggregates
• RxJS-Binding
• RxJS-Coincidence
• RxJS-Experimental
• RxJS-JoinPatterns
• RxJS-Testing
• RxJS-Time

In addition to these main packages, we will continue to deliver the bridges to other libraries such as jQuery, Dojo, MooTools, ExtJS and more.  Just search for RxJS-Bridges to find them all.

Installing with NPM and Node.js

In this release we’ve also made the Reactive Extensions for JavaScript available through NPM, a package manager built on the popular Node.js platform.   With this past release, we’ve made an effort to make sure the Reactive Extensions for JavaScript works great on Node.js.  We’ve worked on modularization where you can include all of RxJS including all the operators all the files such as aggregates, binding, time, and more.  

To get started, just install rx from NPM from a command window. 

> npm install rx

Once installed, you can reference RxJS like the following example of returning a single value and then writing the value to the console when we subscribe.

// Reference main Rx

var Rx = require('rx');

var observable = Rx.Observable.returnValue(42);

var subscription = observable.subscribe( function (value) {

    console.log(value);

});

RxJS, with its emphasis on querying streams of data, is really well suited for Node.js applications. We’ll explore more of RxJS and Node.js in subsequent posts

Asynchronous Module Definition (AMD) support

Modularity is important for many JavaScript developers as code bases in JavaScript become larger, we look for ways of modularizing our code bases and loading only what we need.  One emerging format for modularity has emerged in Asynchronous Module Definition (AMD) which provides a way for JavaScript developers to build modularity into your web based applications.  The AMD format has been embraced by such libraries as jQuery, Dojo, MooTools and now, RxJS.

In the following example, we can use Require.js to load both the main RxJS library as well as the time-based operators to build a simple observable sequence which writes to the console every half second.

// Require both core and time-based operators

require(['rx', 'rx.time'], function (Rx) {

    // Print a value every 500ms

    var subscription = Rx.Observable

        .interval(500 /* ms */)

        .subscribe( function (x) {

            console.log(x);

        });

});

How Do I Get Started…

One of the often asked questions when it comes to RxJS is how one gets started using the library.  This To that end, we’ve created a GitHub repository especially for our samples called RxJS-Examples.  This is just a sampling of some of the examples we have which highlight some of the Reactive Extensions capabilities.

• Autocomplete (source) (demo)
  An autocomplete scenario which throttles typing to query Wikipedia for search suggestions.
  
• Canvas Painting (source) (demo)
  Painting on a HTML5 Canvas.
  
• Drag and Drop (source) (demo)
  Drag and Drop example with the Volta logo.
  
• AMD and Require.js Integration (source) (demo)    
  Integration of the Asynchronous Module Definition pattern, Require.js and RxJS.
  
• Time Flies Like an Arrow (source) (demo)
  A time based delay for each letter based upon its position .
  
• Testing using QUnit (source) (demo)    
  Unit testing example using QUnit showing how you can test the timing aspects of observable sequences.
  
• Testing using Node.js and Mocha (source)
  Unit testing example with Mocha and Node.js, which shows how to test the timings of observable sequences.
  

This is just the start of some of the samples and we’ll be posting more in the near future as well as more complete documentation.

Conclusion

We hope you enjoy the Reactive Extensions for JavaScript V2.0!  Stay tuned to this blog for more in the coming weeks and check out our samples on how you can get started with RxJS.

Today, we’re extremely pleased to announce the availability of Reactive Extensions for .NET (Rx) v2.0 RTM, aligned with the availability of Visual Studio 2012 RTM and Windows 8 RTM for MSDN subscribers. This is a major milestone for the Rx project and we hope you’ll love what you see!

In this post, we’ll focus on how to download and install the bits for use in various application frameworks. Unlike previous posts about the v2.0 pre-releases, we’ll defer further technical details to a series of follow-up posts. Nonetheless, we’ll give a brief introduction into the use of Portable Library with Rx v2.0 RTM.

Note:  We’ve written this post in the typical font used for big announcements nowadays – Comic Sans – in honor of the Higgs boson discovery. In case you don’t want to partake in this celebration for the remainder of the post, click here to switch fonts.

Before we get started, make a note of the supported platforms for this release:

• .NET Framework 4
• .NET Framework 4.5
• .NET Framework 4.5 for Windows Store apps
• Silverlight 5
• Windows Phone 7.5

Although this post was authored on Windows 8 using Visual Studio 2012 for screenshots, Rx can be used with Visual Studio 2010, and/or on older versions of the operating system as well. (For example, at the time of writing this post, Windows Phone development wasn’t yet publicly available in Visual Studio 2012, so that’d be a case where you have to use Visual Studio 2010 for the time being.)

Reactive Extensions for JavaScript (RxJS) users can expect the v2.0 release – including support for WinJS used in Windows Store apps – to hit the web very soon. Watch this blog for the announcement.

Option 1 – Installing the Rx SDK using Windows Installer

The traditional way of installing the Reactive Extensions SDK is through the Windows Installer (MSI) package one can get from the Download Center. Using this approach, you’ll get tight integration with Visual Studio through the Add Reference dialog for various target platforms.

We’ll talk about the integration with Visual Studio shortly. Let’s focus on the target platforms first. After clicking through the EULA page, you’re presented with an option to install the “Typical” feature set of the SDK, the “Complete” on, or to customize the installation using “Custom”. Let’s choose the latter option to illustrate the target platforms and talk a bit about some important changes here.

As you can see from the next screenshot, the structure of the SDK has changed quite a bit:

First of all, notice how the “.NET Framework 4” binaries are not installed by default. We chose this approach to reduce the clutter in the Add Reference dialog in Visual Studio 2012 when installing both the “.NET Framework 4.5” and “.NET Framework 4” assemblies.

When both sets of assemblies are installed on the system, projects targeting .NET Framework 4.5 will have duplicate entries for the Rx assemblies in the Add Reference dialog. Because .NET 4.5 is fully compatible with .NET 4 assemblies, the project management system shows the .NET 4 SDK assemblies as well, alongside the .NET 4.5 SDK assemblies which are optimized for the target platform.

Though one can safely run Rx v2.0 on .NET 4.5 using our .NET 4 assemblies, this is suboptimal. Various features such as “await” support on observable sequences and improved exception propagation (using ExceptionDispatchInfo) wouldn’t be available. Also, users have to make sure not to mix-and-match Rx assemblies targeting different versions of the .NET Framework. For example, using System.Reactive.Core built for .NET 4 together with a copy of System.Reactive.Linq built for .NET 4.5 may or may not work. Such combinations were never tested and will likely result in unexpected runtime behavior.

Tip:  If you’re planning on using Rx v2.0 for both .NET Framework 4 and .NET Framework 4.5 projects, consider using NuGet to prevent issues when referencing assemblies. Using NuGet – which we’ll cover further on – it suffices to pick the Rx packages you need, and the package manager will take care of downloading the binaries that match (or are best suited for) your project’s target platform.

Secondly, the refactoring of Rx v2.0 into a Portable Library based core and platform-specific assemblies for “.NET Framework 4.5” and “.NET for Windows Store apps” (used by Windows 8 XAML applications) is reflected in the feature tree as well. We’ll come back to this in a bit.

After completing the installation, you’ll find the product binaries for selected target platforms under “Program Files (x86)\Microsoft SDKs\Reactive Extensions\v2.0” (omit the x86 part in the path if you’re on a 32-bit system). We changed the installation location – compared to our v1.x release – to consolidate all of Microsoft’s SDKs under the same file system location.

At this point, you’re ready to start playing with Rx v2.0 inside Visual Studio 2012. In the screenshot below, you can see the Rx assemblies show up in the Add Reference dialog for a Console Application project targeting .NET Framework 4.5:

If you decide to use the Reference Manager instead of NuGet (see further), make sure to include System.Reactive.PlatformServices. This assembly contains the so-called platform enlightenment provider that’s responsible to discover platform-specific capabilities for use by the platform-neutral core assemblies that are based on Portable Library. In the selection above, System.Reactive.Interfaces, System.Reactive.Core, and System.Reactive.Linq are all portable assemblies that are shared with Rx v2.0 for .NET 4.5 for Windows Store apps. We’ll come back to enlightenments later in this post.

One additional thing that the MSI-based installer takes care of is installing the so-called Rx v2.0 “Extension SDK” for Windows Store apps. In such projects, the Add Reference dialog has Rx presence in two spots. First of all, the regular Assemblies, Extensions tab contains all of the Rx assemblies in one spot:

When going down this route, make sure to include System.Reactive.PlatformServices for the same reasons as the ones we discussed before. Doing so will enable Rx to take advantage of the WinRT APIs to introduce concurrency on the WinRT thread pool. However, when using the Extension SDK model, you don’t have to worry about picking the right set of assemblies at all. On the Windows, Extensions tab in the Reference Manager dialog you’ll find a one-click way to include all of Rx, tailored for Windows Store apps:

This new Extension SDK model greatly simplifies the procedure of using another SDK, regardless of its internal organization. In the past, different pieces of functionality were often fused together in massive assemblies without proper layering, merely to simplify development and deployment operations. In fact, for Rx v1.0 ease of adoption was an important goal. Long time Rx fans may recall an old split of the Rx API – prior to the v1.0 RTM release – where we had an assembly called System.CoreEx. In order to simplify the usage of Rx, we decided to fuse this assembly with System.Reactive.

However, as portability became an important goal, some things had to be split into a separate assembly (System.Reactive.PlatformServices). At the same time, some use cases didn’t require the full set of Rx operators to be deployed, e.g. because some apps’ sole purpose is to render a sequence on a UI thread. As a result, the core of Rx was split into System.Reactive.Core and System.Reactive.Linq. The former contains core scheduler infrastructure as well as a bunch of base classes, while the latter contains the LINQ query language layer of Rx. Assemblies like System.Reactive.Windows.Threading (for synchronization with the UI in Silverlight, WPF, Windows Phone, or Windows Store apps) only depend on System.Reactive.Core.

Thanks to the new Extension SDK model, as well as the increasing popularity of the NuGet package manager, the inclusion of Rx (or any other SDK for that matter) has become largely friction-free, whilst allowing a better internal organization of the API with proper layering in place. From a deployment point of view, an increasing amount of application models rely on packaging mechanisms, e.g. to upload apps to a store or to a cloud platform, taking away the friction of copying many assemblies.

After installing the Rx SDK, you’ll find the Extension SDK showing up in the Tools, Extensions and Updates dialog as well:

Intermezzo – The refactored API surface

From the discussion above, you’ll likely have noticed the refactored API surface with different assembly names than what you were used to in Rx v1.0. As explained briefly, part of this has to do with splitting platform-specific from platform-neutral functionality, which allowed us to support Portable Library for projects that use Rx. The layered cake diagram of Rx, when hosted in a .NET 4.5 “desktop app” process is shown below:

In here, the green assemblies are portable, meaning they don’t rely on specifics of the underlying platform and can be ported to other target platforms as well. In particular, those assemblies are shared with the Rx v2.0 SDK features targeting .NET 4.5 for Windows Store apps. As a result, this common core cannot depend on various capabilities that don’t exist in the intersection of those platforms, such as thread creation, timer, or thread pool APIs.

For Rx to achieve optimal performance, it needs to find out about platform-specific capabilities that can be used to enhance performance and provide the best possible experience. This is where the blue assembly on the right comes in. While it’s a separate assembly, various infrastructure-only (i.e. not for public consumption) interfaces provide a very tight integration with the portable subset of Rx. When this so-called “platform enlightenment provider” is not available, the portable core falls back to functionality in the intersection of the targeted portable platforms.

The orange assemblies contain bridges to platform-specific APIs such as Windows Forms and WPF (for synchronization with the UI thread), which existed before in Rx v1.0. One notable new assembly is System.Reactive.Runtime.Remoting which contains the .NET Remoting support allowing observable sequences to be exposed as a MarshalByRefObject.

When targeting .NET 4.5 for Windows Store apps, there are different platform-specific assemblies, including the blue enlightenment provider that now leverages Windows Runtime functionality, as well as the orange assemblies that provide access to platform-specific APIs such as Windows XAML and various Windows Runtime APIs (such as the new IAsyncOperation<T> interface). On this platform, the picture looks as follows:

The green assemblies are byte-by-byte identical to the ones used for Rx v2.0 targeting .NET 4.5 “desktop apps”, and are really Portable Library assemblies. When building a Portable Class Library (discussed in a future blog post dedicated to this topic), you’ll directly include those assemblies as well.

In order to show you the effect of running the same portable core of Rx with different System.Reactive.PlatformServices assemblies, have a look at the two call stacks illustrated below. The first runs a timer-based Rx source generator in a .NET 4.5 Console Application, while the latter runs exactly the same code in a Windows Store app.

versus

As you can see, running the same piece of portable code on different platforms resulted in Rx taking advantage of whatever is the best possible way to run timers for the target platform. Notice the System.Reactive.PlatformServices assembly show up in both runs; this is where the platform-specific Rx functionality sneaked itself in underneath the portable System.Reactive.Core and System.Reactive.Linq assemblies.

Option 2 – Installing the Rx assemblies using NuGet

An alternative way of including Rx into your projects is by using NuGet. Starting with Visual Studio 2012, you’ll find the Package Manager directly integrated in the IDE experience, so you won’t have to do anything special to use NuGet. For previous releases of Visual Studio, follow the instructions on www.nuget.org to download and install the Package Manager.

The following package names are commonly used with Reactive Extensions v2.0:

• Rx-Main – installs the System.Reactive.Interfaces, System.Reactive.Core, and System.Reactive.Linq assemblies, as well as the project’s target platform enlightenment provider in System.Reactive.PlatformServices.
• Rx-Xaml – installs Rx-Main as well as System.Reactive.Windows.Threading. This package is used for UI synchronization and can be used on any platform that supports XAML, including WPF, Silverlight, Windows Phone, and Windows Store apps.
• Rx-WinForms – installs Rx-Main as well as System.Reactive.Windows.Forms. Similar to the XAML package, this one is used for UI synchronization, but with the Windows Forms message loop instead of the XAML-specific dispatcher. Only available for .NET 4.0 and .NET 4.5 projects.
• Rx-Remoting – installs Rx-Main as well as System.Reactive.Runtime.Remoting. Use this package to get access to the Remotable extension method that can be used to expose an observable sequence over .NET Remoting. Only available on .NET 4.0 and .NET 4.5 projects.
• Rx-Providers – installs Rx-Main as well as System.Reactive.Providers. This is where the Qbservable mirror image of the System.Reactive.Linq API lives, allowing creation of query providers that translate event stream queries from expression trees to target query languages.
• Rx-WinRT – installs Rx-Main as well as System.Reactive.WindowsRuntime. If you need to bridge with the IAsyncInfo family of interfaces in Windows Runtime, this is the additional package you need. Only available for Windows Store apps projects.
• Rx-WindowsStore – equivalent to the Extension SDK, including all assemblies that are tailored for use with Windows Store app projects. Besides the Rx-Xaml package, this also installs Rx-WindowsRuntime, and transitively includes Rx-Main.
• Rx-Testing – provides access to the testing library, used for writing unit tests for reactive queries using virtual time scheduling. Integrates with the test framework in Visual Studio.

In case you need fine grained control over the lowest layers of the Rx stack, you can also use Rx-Interfaces, Rx-Core, Rx-Linq, and Rx-PlatformServices directly. This is only recommended for advanced scenarios where you don’t need enlightenments, for example when writing a library on top of (part of) Rx.

The screenshot below shows the experience of using NuGet to include Rx-Xaml in a WPF project. Needless to say, this experience is completely analogous in other project types:

Search for Rx-Xaml in the search box. Notice the dependencies listed on the right.

After resolving and expanding the dependencies, NuGet asks to accept the license. Notice how the Rx-PlatformServices package was included as well, which will ensure Rx performance is optimal for the target platform (here .NET 4.5).

Finally, we end up with the required assemblies referenced in the project:

And you’re ready to start playing with Rx!

Intermezzo – What about the “Experimental Release”?

Historically, we released Rx at two difference cadences. Before hitting v1.0 RTM, we did a lot of experimentation to land the final design for the core API of Rx. During this process, quite a few semi-baked ideas were introduced in the API surface. By the time we release Rx v1.0 RTM, we had to find a place for those APIs that we were still noodling around with. This is what become known as the “Experimental Release”.

The model for the Experimental Release was to ship the whole of Rx as a separate “dot” release: v1.0.* was the Stable Release and v1.x.* was the Experimental Release. While this approach worked well, it had a number of drawbacks:

• To use the Experimental Release, on had to toss out references to the Stable Release and replace all binaries with experimental ones. Doing so is a painful process, also involving the change of NuGet package names to Rx_Experimental (at the time, there was no semantic versioning).
• With the above, the support for the product also vanished when using the Experimental Release, even though the experimental functionality was largely additive on top of the stable API surface. The wholesale binary replacement didn’t reflect the additive nature at all.

Because a picture is worth a thousands words, here’s an illustration of this model (omitting a few other experimental releases):

One of the reasons we went with this approach was to make sure functionality migrating from experimental to stable didn’t break as it moved up. How could that happen? Well, if you have a static method – say for an observable sequence generator method - that’s not meant to be invoked as an extension method, defining it on a class called “ObservableEx” isn’t future proof. As the method moves to stable and gets defined on the “Observable” class instead, this breaks existing code that depended on the experimental functionality. Essentially, splitting a class definition across assemblies isn’t supported.

While moving to the Rx v2.0 release, we felt the cost of maintaining two parallel releases far outweighed the name compatibility advantage. Especially given the refactored API and assembly surface, the pain of replacing a whole bunch of assemblies (and hence loosing support) feels like non-justifiable. At the same time, it wasn’t at all clear how to position a v2.0 Beta in the grand scheme of things. Would a Beta Release be an experimental one?

By the time we shipped Rx v2.0 Beta, it became clear we couldn’t drop the experimental API on the floor, as it’d prevent our cutting edge users to migrate from the latest Experimental Release to the v2.0 Beta release. In the picture below, you can see this transition:

I’m drawing the assemblies in the Beta Release in purple, to emphasize their blended nature of the original stable (blue) and experimental (orange/red) functionality we inherited directly from the latest v1.1 build. Nothing here changed in the Release Candidate stage, where we still had all of the what-used-to-be experimental functionality in the product. We left all of this functionality marked with an [Experimental] attribute, so users could keep track of what was still not considered to be fully baked.

Note:  For Beta and RC we used NuGet’s semantic versioning feature. We will continue to ship pre-release software using this capability. We consider pre-release builds to be early previews of what we plan to ship for a next major release. Experimental functionality – as discussed below – is more unstable with no promises made yet, and we won’t use the terminology of Beta, Release Candidate, etc. for this going forward.

For RTM, we revisited the list of experimental APIs and decided to refactor what was left as truly experimental into a System.Reactive.Experimental assembly, which is only available through NuGet as the Rx-Experimental package. This allows us to ship frequently as we have new experiments we feel our users may be interested in, without having to worry about complex test matrices for the SDK installer, VSIX packages, etc. The new picture looks as follows:

The System.Reactive.Experimental assembly extends all of the Rx APIs (here only showing four assemblies, in reality the experimental library may also extend the capabilities in System.Reactive.Windows.Threading, etc.) and “sits around” all of the stable assemblies as an additive set of APIs. You can continue to run the stable product assemblies, combining them with one single experimental one, rather than having to replace all of Rx wholesale. With this, we can provide better support as we know the heart of Rx was unmodified despite the addition of an experimental layer.

Going forward, the System.Reactive.Experimental assembly will continue to live its own life, moving independently from the stable core of Rx. Today, together with the Rx v2.0 RTM stable set of assemblies, we also shipped the first version of System.Reactive.Experimental. Currently, both have version numbers that are in sync (v2.0.20814), but in the future you’ll see the experimental assembly moving forward independently.

For a next major release of Rx (no promises on timing in this post, though), some of the experimental functionality may promote to that release’s Beta to make its way to the release’s RTM stage. Once a feature enters the major release train, it’s meant to ship eventually in the stable core. Some experimental stuff may stay experimental forever though.

So, what about compatibility for API member names? Quite simply, we don’t make any guarantees that functionality in experimental will work as-is when (if ever) it moves to the stable API. For example, extra query operators in System.Reactive.Experimental are defined on a static class called ObservableEx (where “Ex” stands for “Experimental” and not “Extensions”), paired with QbservableEx for query provider support. Both classes live in the System.Reactive.Linq namespace just like the stable querying API in the System.Reactive.Linq assembly, so all of this functionality blends in nicely. (You can still recognize such operators by looking for the [Experimental] attribute annotation, which could also be used to write tooling to analyze your use of experimental unstable functionality.)

Because a lot of those experimental operators are defined as extension methods, an eventual move to the stable assemblies won’t cause breakages. However, for static methods that can only be invoked using static method invocation syntax, there will be a source-level compatibility break, requiring you to substitute uses of ObservableEx for Observable.

As we prepared for this split, we took the opportunity to promote a few operators to the stable API. One set of such methods are the “imperative operators”, such as “If”, “Case”, “DoWhile”, etc. We’ve seen those being used quite a bit (surprisingly to some extent) and we shipped those in the ROM of Windows Phone 7 before. Considering both those points, and given that their functionality is well-defined and no longer considered “experimental”, we went ahead and polished those (including performance-related work) to put them straight on Observable in the stable API. Not doing so would require them to move to ObservableEx, impairing migration for Windows Phone 7 users from the Rx version in the ROM to the Rx v2.0 release.

The list of experimental APIs for the initial Rx v2.0 System.Reactive.Experimental is rather small:

• Create for use with iterators (largely redundant due to the introduction of the new async features)
• Expand to recursively expand a sequence (potentially leading to unbounded concurrency if not used carefully)
• ForkJoin which can be replaced with composition of CombineLatest and LastAsync
• Let for trivial observable bindings (not preventing duplication of side-effects, hence quite dangerous)
• ManySelect, the “co-monadic bind operator” which no-one really understood
• ToListObservable which was introduced to be paired up with the Create on the top of the list (and in a lot of cases ToList is better anyway)

Option 3 – Installing the Extension SDK from the Visual Studio Gallery

While discussion Option 1, using the Rx SDK MSI, you already saw the concept of Extension SDKs. One additional way to get the Rx v2.0 Extension SDK for Windows Store apps is to go straight to the Tools, Extensions and Updates menu in Visual Studio 2012 and navigate to the Visual Studio Gallery, Tools, Extension SDK section on the left. In there, you’ll find Reactive Extensions listed as well:

If you haven’t installed the Rx SDK yet, this window provides you with an option to install the Extension SDK. After completing this step, you can simply include Rx in a Windows Store app project by the steps outlined before: simply go to the Add Reference option and navigate to Windows, Extensions on the left of the Reference Manager dialog. Simply mark the checkbox next to the Reactive Extensions entry and you’re done.

We hope you’ll enjoy Rx v2.0! Stay tuned to this blog for more posts (in the regular font again, I promise) about various Rx v2.0 features and improvements.

Bart J.F. De Smet
Senior SDE – Cloud Programmability Team

For the full schedule, see https://channel9.msdn.com/Events/Ch9Live/Channel-9-Live-at-Tech-Ed-Europe-2012. I’m on at 2:45PM local time, so tweet any questions you have about Rx or LINQ then.

We’ve been able to repro the issue and trace it back to new code signing procedures that have been introduced in Rx v2.0 Release Candidate for .NET 4.5 and .NET for Metro style apps (see Enhanced Strong Naming). Unfortunately, the regression for older platforms went unnoticed due to “strong name verification skip entries” being set up on various build and test agents. We’re working on correcting the issue.

Our sincere apologies for the inconvenience. We’ll update this page as we issue a fix very soon.

Update:  We’ve updated the NuGet packages with a fix. The new package version number is 2.0.20622-rc.

Update:  The SDK MSI installer has also been updated (publication date 6/22/2012). It suffices to install the new MSI, which will perform an in-place upgrade.