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.

One of the new controversial features that is being added to the latest version of Rails, is the default inclusion of two languages that make web development easier – one for simplifying CSS called “Sass”, and a language for writing more readable, elegant Javascript, which is called CoffeeScript. The examples from these two sites illustrate the languages far better than I could.

Both of these languages share some common characteristics – they both try to generally stay “true” to their target language (i.e. CoffeeScript compiles down to clean, readable JavaScript that generally has a 1:1 mapping from source to target statement), and they both attempt to solve some of the historical “ugliness” associated with their target language. I’ve used both Sass and CoffeeScript before in the past and I think they are a brilliant contribution to web development, and allow you to write cleaner, more reusable code.

These two languages have excellent support in Rails, as well as in node.js, two of the latest “hip” web development platforms, and I was surprised that someone hadn’t beaten me to the punch and created NuGet packages to enable support for these – a lot of people had solutions for different pieces, but most were proof-of-concepts or were difficult to use. With NuGet, there is zero reason that web libraries should be anything other than “one-click install”.

So without further ado, I present, SassAndCoffee – an ASP.NET library to add drop-in support for Sass/SCSS and CoffeeScript!

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)

That’s all there is to it! Files will be cached in your AppData folder and will be regenerated whenever you modify them.

How does it work?

SassAndCoffee embeds the original compilers in the DLL as (Sass 3.2.0 and CoffeeScript 1.1.0 as of this writing) and uses IronRuby and Jurassic respectively to execute the compilers against your source.

Why is this better than [SOMEOTHERPROJECT]

• No external processes are executed
• You don’t have to install Ruby or node.js
• It’s in NuGet so you don’t have to fiddle with web.config
• Files are cached and are rebuilt as-needed.

Thanks

Several folks helped me out with some of the integration details of this project – if it weren’t for them, I would still be stuck in the mud right now:

• David Padbury for helping me out with the CoffeeScript compiler
• Levi Broderick for giving me a few hints as to how to rig up the HttpModule
• Jimmy Schementi for telling me the proper way to redirect ‘requires’ to an embedded resource

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. Check out this video for an overview:

Click here to view the embedded video.

ReactiveUI on Hanselminutes

Check out the recent Hanselminutes episode about the Reactive Extensions as well if you’ve got more time. Scott and I chat about some of the ideas in RxUI and how we can take the ideas in the Reactive Extensions and use RxUI to apply them to Silverlight and WPF apps.

What’s new in ReactiveUI 2.3 – update to work with Rx 1.1.10425

As you may have noticed, the latest version of Rx has changed quite a bit, in both the functionality and the namespace structure. The latest build is just a release to make RxUI compatible. Another fix is, that since NuGet 1.2+ fixes the support for WP7, so I’ve updated the normal packages. If you’re already using the WP7-specific packages, I’ve updated those too.

Where can I find the library?

On NuGet! The best way to install ReactiveUI for a project is by installing the ReactiveUI package for WPF/Silverlight/new WP7 projects, or ReactiveUI-WP7 for existing Windows Phone 7 projects.

If NuGet isn’t your thing, you can also find the binaries on the Github page: ReactiveUI 2.3.0.0.zip.

Where can I see a sample?

A sample project for WPF 4.0 that includes everything you need to see how it works is on the Github page: ReactiveUI 2.1 Sample.zip. It includes a small sample app, the RxUI binaries, and some sample test cases.

Disable Parallels Shared Folders

The cause is that files that are normally local are being redirected to network shares. Disable this in Parallels and all will be right with the world again!

No! RxUI provides all of the core components that you need to use the M-V-VM pattern, but many people already have applications written using some of the other great .NET MVVM frameworks, such as MVVM Light or Caliburn.Micro – rewriting an entire codebase just to use Rx is a total bummer.

Fortunately, in ReactiveUI 2.2, there have been several features introduced in order to make using RxUI with existing frameworks easier – you can try out RxUI on a per-page basis, instead of rewriting your whole app.

There are really three core bits that are central to MVVM: a ViewModel object, an ICommand implementation, and a change-notifying Collection. Let’s take a look at how we can Rx’ify these three items.

Using MVVM Light alongside ReactiveUI

First, File->New Project and create a new “MVVM Light” projects via the template. Then via NuGet (you are using NuGet, right?), add a reference to the “ReactiveUI” project. Now, crack open MainViewModel.cs. The critical thing to know is, all of RxUI’s awesomeness are extensions onto an interface called IReactiveNotifyPropertyChanged. Ergo, we need to make MainViewModel implement this. But don’t panic, it’s easy!

Step 1: Change the class definition to implement IReactiveNotifyPropertyChanged.

Step 2: Add a field of type “MakeObjectReactiveHelper”, and initialize it in the constructor:

Step 3: Paste in the following code at the end of your class, which just uses _reactiveHelper to implement the entire interface:

An important caveat about MakeObjectReactiveHelper

One thing that probably won’t affect you, but it might: MakeObjectReactiveHelper doesn’t properly completely implement IReactiveNotifyPropertyChanged unless you are also implementing INotifyPropertyChanging – most ViewModel implementations don’t (in fact, the interface doesn’t even exist in Silverlight or WP7). This means that in certain circumstances when you use the WhenAny or ObservableForProperty with a deep path (i.e. x.Foo.Bar.Baz), you may get duplicate notifications. In practice, this usually isn’t a big deal.

Watching ObservableCollections to create ViewModel collections

With RxUI 2.2, you can easily create a collection which tracks an existing collection, even if the source is an ObservableCollection. Here’s the syntax:

Creating ReactiveCommands like RelayCommands

Unfortunately, the story for ICommand isn’t as easy, you have to wrap commands one-at-a-time in order to subscribe to them. Here’s how to do it: