Breaking News: Future Version of .NET Framework to Run on the Mac


Breaking News: Microsoft is working on having a version of the framework that will run on the Mac!  That's right -- Rory broke this story just the other day in his interview with Scott Guthrie.

First, a little bit of background, which although not secret has largely went unnoticed so far.  Hopefully you've heard of WPF/E, which is a subset of WPF that runs in the brower, even Firefox and Safari.  So far the first CTP is largely focused on the cool graphics capabilities and supporting media.  But even in this first CTP the XAML can be programmed against on the client-side using JavaScript, even with Ajax.  But its also already been discretely said that in the future WPF/E will also contain a small cross platform subset of the CLR.  That will mean that we will also be able to use C# or VB on the client-side to program against WPF/E!  And that will be true even in Firefox and Safari on the Mac -- and this is old news that simply hasn't been widely talked about.

Mike Harsh as early as March 23, 2006 said:

So what is WPF/E?  It is a cross-platform, cross-browser web technology that supports a subset of WPF XAML.  WPF/E also has a friction-free install model and the download size we’re targeting is very small.  WPF/E supports programmability through javascript for tight browser integration.  The WPF/E package also contains a small, cross platform subset of the CLR and .NET Framework that can run C# or VB.NET code.  Yes, we are bringing C# programming to the Mac.

And Joe Stegman said this just last month:

To be clear, "WPF/E" is independent of the .NET Framework.  In a future version, we'll support a small cross platform CLR based execution engine that will run on both Windows and Apple OS X (everything we do from a runtime perspective works on both Windows and Apple OS X).  In general, our tools are dependent on Windows but with the current version of "WPF/E", you can develop using a text editor and deploy on any web server.  When we support the small CLR, compiling/debugging will require Windows (and so will our designer tools) but running/deployment will still work cross platform.

And then Scott said this in the interview at the 9 minute mark:

Scott: And overtime we'll also support a managed programming language, uh framework, against WPF/E as well.  So in addition to using JavaScript, you'll be able to use C#, uh
Rory: You mean, even for the other?
Scott: Yeah even for the Safari and Mac.

But what Scott said in this interview with Rory went beyond the small CLR for WPF/E in the browser.  Instead Scott said that they were also looking at a version of this that would run outside of the browser, even on the Mac!  Listen to this interview and its pretty clear that Scott was probably not intending to announce this until Mix.  Rory was also quite suprised and wondered if he needed to remove this from the video.  But Scott said he could keep it and acknowledged that this was probably the first time this was publicly talked about.  Rory was of course very excited to be the one to get this scoop out of Scott.  :)

So here's what Scott said in the interview at the 23:45 mark:

Rory: Is there any possibility of eventually having a framework that runs outside the browser?
Scott: Yea, yea, that's definitely something we're looking at is, uh, kind of what we call the in-browser experience and kind of the out-of-browser experience.  And so that's something we'll talk more about at mix, uh
Rory: And that stuff's secret now? Cause I don't mean to bring up something that's secret.
Scott: No, no, well that's something, uh, that we haven't talked about publicly yet. But that's certainly a scenario we're thinking about.
Rory: Do I have to get that out of the video?
Scott: No, you can keep that.
Rory: I can keep that? Is this like the first time anyone's heard it?
Scott: Probably, yeah.

Just having the ability to use our favorite .NET language and a subset of the CLR inside the browser to target an incredibly rich graphics platform like WPF/E is huge to me, but if we're not even restricted to the browser -- wow!  For instance, Keith Elder already has a post on his blog where he considers some of the possibilities, and that's just one person thinking out loud.  Of course right now the first CTP is still very much cool graphics and media, but this is a very strategic start.  Why?  Because this is focusing on what isn't easily possible any other way, and its getting the big media players involved.  And if the big media players use it then you can bet that everyone will be downloading the plugin just like they do now for Flash.  Most users aren't going to care about the .NET part, but once its ubiquitous, then we will also be able to take advantage of it.

So there you go -- its just a matter of time before there will be a small CLR version of the .NET framework everywhere, with your favorite .NET language of course!


  • Erm... you can have mono on the Mac now, which more functionality than the wpf/e framework. Or am I missing something?

  • That's a good question. And I think the answer is that it depends on what you're doing. Mono is likely to support a larger subset than this new mini-CLR, but then again this new mini-CLR might be more up-to-date than Mono. So if you're going to run something on the Mac you'll need to decide what the relevant subset is that you need, and how best to accomplish that. Then there's the issue of size and ubiquity since Mono is very large, as is the full .NET, while the new mini-CLR is going to be very small. And over time we'll probably find that the new mini-CLR will hopefully become very ubiquitous so that we won't have to worry about even a small download, while that's not likely to be the case with Mono. Finally, the other aspect, like it or not, is something that you already know very well, and that is that the vast majority of MS devs only care about the official MS stack, and Mono ends up never even being considered.

  • wow, is this the news of the year for me....

  • Hi Paul,

    Microsoft at the moment have several different branches of their CLI implementation, the .NET Framework as we know it today is branched into the SSCLI (Rotor) line. Rotor is different to the commerical CLI in that several parts are replaced, largely to remove commerical interests but also to allow for cross platform running. There Microsoft have added a Platform Application Layer (PAL), which is a unmanaged C++ layer that sits at the very base point between the CLR and the OS that allows the IL to be run across different chips and translates system calls (error calls etc) and thread allocation etc. The PAL allows Rotor to run on windows, the OSX and FreeBSD. OSX and FreeBSD are close targets as the OS are very similar (OSX being based on FreeBSD) so adapting the PAL for each is not as much as work as say Linux would be (and possible with work).

    So the .NET framework can with an adaption like the PAL be run on other platforms. What I suspect Microsoft will do is either a) extend the PAL for the commerical line so that window dependent code can use it. b) keep the PAL light weight and lighten the framework to reduce the windows dependent code. Microsoft will also improve perf with the PAL for the commerical line.

    Thats my take on it :)


  • Seems like the more Apple is spitting in the face of microsoft, the more microsoft likes them.

    After vista, windows and all other bashings, MS should just cease all Apple development. No Mac Office means OSX is as good as dead in any business environment.

  • That's a pretty stupid assessment. OS X wouldn't go anywhere just because Microsoft would stop doing Office. The iWork suite, if expanded the way the rumors indicate, works just fine.

  • It's great to see Microsoft moving forward on the initial .NET and IL vision of mulit-platform support. It sounds like WPF/E will give Adobe Flash and even Apollo some good competition...

  • I think this is more about stemming the flow of Rich Web App development and taking on Flash, rather than any serious support for C# and .NET on OSX.

    If MS really wanted the .NET CLR to be a cross platform solution they could do it by porting the lot (runtime, library, tools) to OSX. But they have no interest in doing so: they make their money and dominate the market through Windows. Why would they do anything to weaken that?

  • I'm with Krishna on this one. Don't expect to be able to write any cross-platform enterprise app with this WPF CLR.

    But you most probably can code Tic-Tac-Toe in C# and XAML and run it on MacOS.

    If they want to support the WPF/E plugin for various browsers, it makes sense to slightly extend that support for rich UI's to the desktops. Similar to downloading a Flash file and running it locally...

  • Wim, I think you're missing the point of this. WPF/E has the possibility to build richer front ends that HTML can't handle today or that are difficult to do or require fancy frameoworks built on a house of cards. Having a rich UI that can talk to the server to get data to the client doesn't require a huge amount of functionality in terms of framework...

    It's in Microsoft's interest to be a player in this area or else loose out to Flash or other tools that are starting to crop up to take that place.

    Whether Microsoft can make any inroads on anything but Windows is another story, but it all depends on how well they execute WPF/E and whatever CLR framework/language features they support. Let's just hope it's not crippled to the point of being unusable...

Comments have been disabled for this content.