ReactiveUI is a M-V-VM framework like MVVM Light or Caliburn.Micro, that is deeply integrated with the Reactive Extensions for .NET. This allows you to write code in your ViewModel that is far more elegant and terse when expressing complex stateful interactions, as well as much simpler handling of async operations.

What’s New in 3.1

Tons of stuff.

ReactiveUI has improved dramatically since the previous version. Over the next few weeks I’ll be posting blog articles on how to use new features in ReactiveUI, but here’s the short list:

• User Errors: – A new API to separate the generation and presentation of errors that should be presented to the user in a friendly way. This is the Testable, Elegant, user-friendly way to make that MessageBox.Show() call.

• ReactiveUI.Routing – An entirely new component to ReactiveUI, designed for creating multi-page applications using Dependency Injection / IoC, while not being tied to any specific IoC container.

• First Class Async / Await Support – ReactiveUI now allows you to use Task<T> in many places in the framework where it makes sense.

• Ordering and Filtering of Models – using the new CreateDerivedCollection methods, ViewModel collections that “follow” Model collections and apply custom filtering / ordering are now easy to create.

• NLog Logging – A rewritten logging framework, based on NLog

• Preliminary support for WinRT (including async/await via LinqToAwait) and Gtk# on Mono 2.10.

• An overhaul of how ReactiveUI handles binding errors that results in more reliable applications.

• Many cleanups to APIs to make using ReactiveUI more straightforward and intuitive

A new sample: Play for Windows

Many of the new features in ReactiveUI 3.1 were prototyped and refined in Play for Windows, a .NET 4.5 client for the Play Music Server. This application is a production-quality application that demonstrates many of the new ReactiveUI features, especially Routing and RxUI.Testing.

Breaking Changes

ReactiveUI is now following the SemVer versioning scheme. This means, that v3 now has breaking changes. However, apart from one, these changes shouldn’t be overly difficult to fix.

• Deprecated Platforms – ReactiveUI has dropped support for .NET 3.5, SL4, and WP7.0. You must upgrade to .NET 4.0/4.5, SL5, or WP7.1 (Mango) to use ReactiveUI 3.1. Rx has decided to deprecate these platforms soon as well.

• Logging Changes – The interface between RxUI 2.5’s Log() method and RxUI 3.1’s is slightly different (methods like “InfoFormat” are now just “Info”, etc.)

• Disabled Bindings now Crash – In ReactiveUI 2.5, if an ObservableAsPropertyHelper or the CanExecute of a ReactiveCommand terminates with OnError, the exception disappears into the ether and the binding stops working. In RxUI 3.1, this will result in an item being sent to the new ThrownExceptions Observable.

  This Observable is special, in that if there are no Subscribers, items gets sent to the global RxApp.DefaultExceptionHandler, which by default, crashes the application.

• Deprecated / Changed Methods – Some methods, particularly in MessageBus and ReactiveUI.Testing, have changed names to be more consistent with Rx (i.e. AdvanceByMs vs. 2.5’s RunToMilliseconds), or have been removed, such as ObservableCollectionView (use CreateDerivedCollection() instead).

Thanks!

Thanks to the following people for contributing patches to ReactiveUI 3.1:

• Phil Haack
• Johan Laanstra
• Lowell Smith
• Stanislaw Swierc
• Tim Clem

The Details

On startup, we write out the V8 DLL to a temporary directory and call Assembly.Load to load it. Unfortunately, even though the write succeeds, the Load fails for some reason. On AppHarbor, we would always fall back to Jurassic, but in 1.1 I disabled this fallback because of performance issues (and because it made it harder to debug the V8 load failures).

Can I make an ISO out of a Windows install directory? Definitely!

Here’s how to take any Windows Install directory from Vista onward and turn it into a DVD ISO:

1. Download oscdimg.exe from here, which I’m certainly hosting illegally. Don’t tell anyone in Redmond. (This is a public tool, just normally wrapped in a huge download; I’m hosting it solely for convenience sake)
2. Open up cmd and copy oscdimg.exe to the *parent* directory of the Windows install (i.e. if it’s in E:\Windows8, copy it to E:\)
3. Cd to inside the Windows directory (i.e. the folders should be “Boot”, “Efi”, “Sources”, etc)
4. Run the following command:
..\oscdimg.exe -u2 -h . -bboot\etfsboot.com ..\MyCoolNewImage.iso

That’s all there is to it! Now you’ve got a shiny new bootable ISO that you can load into a VM or burn to DVD.

SassAndCoffee is a library for ASP.NET (both MVC and old-school WebForms) that adds drop-in support for two new languages: Sass and SCSS, a language that allows you to write reusable, more structured CSS, as well as CoffeeScript, which is a JavaScript dialect that is much more syntactically elegant, but still preserving 100% compatibility with regular JavaScript.

How to use SassAndCoffee

• Add the package reference via NuGet
• Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
• Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)
• To get the minified version of a file (either a coffee file or a standard js file), ask for the “.min.js” version (i.e. “scripts/test.min.js”)

What’s New in SassAndCoffee 1.1 – Update All The Things

SassAndCoffee updates its version of V8 to the latest released code that runs even faster, as well as the latest released version of CoffeeScript, version 1.1.2. In an attempt to catch some tricky-to-debug errors that folks are having on 64-Bit IIS, I’ve also disabled Jurassic on 64-bit AppPools, since it was unusably slow anyways. This means that if V8 fails, SassAndCoffee will crash and hopefully provide some debugging information to assist in telling me what’s going on.

What else is new?

SassAndCoffee now correctly handles JavaScript with non-ASCII characters, as long as the file is encoded in UTF-8. Thanks to Roman Kvasov who taught me a thing or two about V8 that I didn’t know, as well as contributing the code to fix it!

SassAndCoffee is a library for ASP.NET (both MVC and old-school WebForms) that adds drop-in support for two new languages: Sass and SCSS, a language that allows you to write reusable, more structured CSS, as well as CoffeeScript, which is a JavaScript dialect that is much more syntactically elegant, but still preserving 100% compatibility with regular JavaScript.

How to use SassAndCoffee

• Add the package reference via NuGet
• Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
• Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)
• To get the minified version of a file (either a coffee file or a standard js file), ask for the “.min.js” version (i.e. “scripts/test.min.js”)

What’s New in SassAndCoffee 1.0 – Rigging VS2010 to be compatible

The most common issue that people experience with using SassAndCoffee wasn’t actually an issue with the code at all – the symptoms were that it would work fine on their development machine, but when they deployed to production, all the SCSS/CoffeeScript files would return 404 File Not Found.

Why? Since VS2010 doesn’t recognize these files, it sets its build action to ‘None’, which means the files won’t be deployed. However, since VS runs your app locally from the same directory, it would still find the files on your box. The ultimate case of “Works On My Machine”!

The Properties Dialog, where you can reset this property

Well that’s annoying. How do you fix it?

Now, when you install SassAndCoffee, you will see a dialog offering to install a file onto your box – this “pkgdef” file will configure VS to consider Sass/SCSS/Coffee files as Content. Here’s the details on how this works.

Configurable Caching Support

SassAndCoffee now has three types of cache options, which can be configured by adding a setting to the appSettings block with a key of SassAndCoffee.Cache:

• NoCache – Compile every file when requested, don’t cache anything
• InMemoryCache – Cache a limited number of files in-memory, but don’t persist anything to disk
• FileCache – The default option (and previous behavior) – cache compiled files in App_Data

What else is new?

• SassAndCoffee had its first external contributions by Steven Robbins and Ken Browning! You have no idea how excited I am about this.
• The biggest change was support for NancyFx by Steven’s Herculean effort to decouple the core compilation code from the ASP.NET pipeline. SassAndCoffee is now in a great place for other non-ASP.NET frameworks to use as well, such as Manos.

If you use the Silverlight version of ReactiveUI, you will currently encounter a lot of issues that appear to be the classic InvalidOperationException, where a Silverlight object is being accessed by a background thread – it might look something like this:


at System.Windows.Threading.Dispatcher.VerifyAccess()
at System.Windows.DependencyObject.GetValue(DependencyProperty dp)
at System.Windows.Controls.Primitives.ButtonBase.get_Command()
at System.Windows.Controls.Primitives.ButtonBase.UpdateCanExecute()
at
System.Windows.Controls.Primitives.ButtonBase.OnCanExecuteChanged(Object
sender, EventArgs e)
at ReactiveUI.Xaml.ReactiveCommand.b__0(Boolean b)
at
ReactiveUI.ObservableAsPropertyHelper`1.<>c__DisplayClass4.< .ctor>b__0(T
x)
at System.Reactive.AnonymousObserver`1.Next(T value)
at System.Reactive.AbstractObserver`1.OnNext(T value)
at System.Reactive.AnonymousObservable`1.AutoDetachObserver.Next(T
value)
at System.Reactive.AbstractObserver`1.OnNext(T value)
at
System.Reactive.ScheduledObserver`1.<>c__DisplayClass639.b__637()
at System.Reactive.ScheduledObserver`1.b__634(Action
self)


You’ll also see the message in the Console output, "WPF Rx.NET DLL reference not added - using Event Loop"

How to fix it

The easiest way to fix this is by adding this block to your App.xaml.cs:

What’s the Deal??

One of the goals of RxUI was that the core library didn’t have a dependency on WPF/Silverlight: since an Observable Model object or an Observable collection is useful regardless of the domain! However, to do this, we need to do some trickery to ensure the experience is correct.

In a Console app, we don’t have a message loop, so we use EventLoopScheduler; this has the result of creating a single thread where all of our “UI actions” happen – it’s a Dispatcher without the Dispatcher. In WPF/Silverlight, we do have a real message loop, so we want to use DispatcherScheduler as our “put it on the UI thread” scheduler – but, we can’t link to System.Reactive.Threading.dll without pulling in WPF, even if we don’t use it!

What I do is, in the RxApp startup routine, I use Reflection to attempt to find the DispatcherScheduler Type and instantiate it at runtime. In WPF, the code that is currently there works like gangbusters – in Silverlight though, you have to be way more specific – Lukas Cenovsky does a great job tracking down the bug in this mail thread: you have to specify not just the fully namespaced Type name, but the fully qualified assembly name! (i.e. not just “System.Reactive.Windows.Threading”, but all of the version details and the public key token.

How come this doesn’t happen in unit tests?

Because in Unit Tests, there is no working Dispatcher (you can queue items to it, but they will never run) – ReactiveUI knows this and switches the Scheduler automatically in a unit test runner to Immediate, which makes writing simple unit tests far easier. That has the side-effect for me though, that some of my code is never covered by a unit test. Oops!

tl;dr; - Reflection works a lot differently on Silverlight, and is generally way more of a pain.

SassAndCoffee is a library for ASP.NET (both MVC and old-school WebForms) that adds drop-in support for two new languages: Sass and SCSS, a language that allows you to write reusable, more structured CSS, as well as CoffeeScript, which is a JavaScript dialect that is much more syntactically elegant, but still preserving 100% compatibility with regular JavaScript.

How to use SassAndCoffee

• Add the package reference via NuGet
• Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
• Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)
• To get the minified version of a file (either a coffee file or a standard js file), ask for the “.min.js” version (i.e. “scripts/test.min.js”)

What’s New in SassAndCoffee 0.9 – Speed, Speed, Speed!

SassAndCoffee now embeds the V8 Javascript Engine – this improves compilation speeds dramatically compared with previous releases. This feature only works on x86/amd64 on Windows, but if you’re on Mono or some other platform, SassAndCoffee will fall back to the old Jurassic-based engine. All of this is behind the scenes though, nothing changes from the perspective of a user (except for the NuGet package went from 400kb to 3.7MB!) Compilation speeds for Sass are improved as well through better reuse of IronRuby engine instances.

What else is new?

• The Sass @import directive now works – this is an awesome feature of Sass that really allows you to clean up your CSS files and write them more like code and keep it DRY!
• Reliability improvements – less crashification and race conditions

SassAndCoffee is a library for ASP.NET (both MVC and old-school WebForms) that adds drop-in support for two new languages: Sass and SCSS, a language that allows you to write reusable, more structured CSS, as well as CoffeeScript, which is a JavaScript dialect that is much more syntactically elegant, but still preserving 100% compatibility with regular JavaScript.

How to use SassAndCoffee

• Add the package reference via NuGet
• Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
• Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)
• To get the minified version of a file (either a coffee file or a standard js file), ask for the “.min.js” version (i.e. “scripts/test.min.js”)

Some things you don’t have to do

• Install any extra software, such as Ruby – everything is embedded in resources.
• Do any special configuration or make manual changes to your config files – NuGet will handle that.
• Run any commands to update the files – SassAndCoffee builds the files on the first request; if you make CSS / JavaScript changes, it’ll rebuild automatically.
• Do any special setup whatsoever when deploying – if it works on your box, it’ll work on the remote box (*)

* – a special note: VS2010 likes to mark CoffeeScript files as ‘do not deploy’ – make sure to hit F4 and mark them as content

What’s New in SassAndCoffee 0.8 – Minification and Combination

SassAndCoffee now supports JavaScript minification thanks to Mihai Bazon’s UglifyJS project – for both CoffeeScript files as well as your existing JavaScript files. It’s quite simple to use – anywhere you reference a JS file in your Views, rewrite the reference to “.min.js”.

It’s also a good idea to combine several Javascript files into one file to minimize requests – however trying to do this by-hand is a maintenance nightmare. To this end, SassAndCoffee will do this work for you. Here’s how to do it:

1. Open your View file, you probably have references to a bunch of scripts, whose source looks something like: @Url.Content("~/Scripts/jquery-1.5.1.min.js")
2. Copy the actual references (i.e. starting from ‘~’ on) to a file whose extension is “.combine” (i.e. ‘debug_all.combine’). These files don’t necessarily have to exist on-disk (i.e. they can be a CoffeeScript file). You can also just write a list of filenames, relative to the .combine file.
3. Reference the file as if it was a JavaScript file (i.e. ‘debug_all.js’)
4. If you change either the combine file or any file that it references, it will rebuilt – no need to rebuild anything by hand!

You can see an example of how this is used in the WebTest project on GitHub.

What else is new?

• Scripts are compiled/minified in parallel, improving performance. Unfortunately, minifying a significant number of scripts still takes a long time – this will be dramatically improved in the next release.
• Several bugs were fixed, such as fixing projects that didn’t have an App_Data folder, as well as a race condition where zero-length files could possibly be served up.

ReactiveUI 2.3.1 is a maintenance release. The big difference is to fix the NuGet packages because they were targeted at the wrong branch of Rx.NET – I had built against the 1.0 branch, but only the 1.1 branch is published.

Wrong Branch?

With the latest release of the Reactive Extensions, the team has split the product into two branches – the stable release (having a version number of 1.0.10425), and the experimental release (which begins with 1.1). While the term “Experimental” sounds scary, it’s currently a bit of a misnomer – Experimental is just the Stable release with some extra methods added. Conveniently, they tagged all of the differences with an Attribute called “Experimental”, so you can use a disassembler such as ILSpy or JetBrains’ dotPeek to find all of the new cool stuff if you find the “ExperimentalAttribute” class, then “Find Usages”.

Keep in mind, that the reason that the release is Experimental, is that these new APIs are subject to change – they might work differently in future releases, or be gone altogether.

One more thing

It’s not all boring changes – I added one small feature that folks were asking for: in your class definitions, if you have a custom property getter/setter and can’t use RaiseAndSetIfChanged, you can now use the Expression syntax with RaisePropertyChanging/RaisePropertyChanged. So, “RaisePropertyChanged(x => x.SomeProperty)”.

What is Rx-Xaml?

For the current Rx release, the DLL that contains “ObserveOnDispatcher” (and everything Dispatcher-related) is in a separate “System.Windows.Reactive.Threading.dll” assembly. This DLL is needed for any project that uses WPF/Silverlight/WP7. The Rx team decided to publish two separate packages for this DLL, “Rx-WPF” and “Rx-Silverlight”. While this is easier to grok, it also makes it difficult for projects like ReactiveUI that support both WPF and Silverlight, since I can’t write the dependency in my NuSpec file correctly. So, I created a new package, “Rx-Xaml”, that is a simple merge of “Rx-WPF” and “Rx-Silverlight” – based on the platform, it will do the right thing. I’ll keep this package up-to-date, so feel free to depend on it.