Microsoft .NET logo

Understanding the New Cross-Platform .NET

Tweet about this on TwitterShare on Facebook1Share on Google+0Share on LinkedIn19Share on Reddit0Email this to someone

Microsoft .NET logo

Part 1 of a 4-part series.  A link to part 2 is at the bottom.

Java has been my primary bread-and-butter for more than 15 years.  However, over the past five years, my two most recent companies have been mixed shops that use both Java and C# to some degree.

My initial impression was that “C#-as-a-language” is about five years ahead of Java, but “.NET-as-a-ecosystem” is a decade or more behind.  So I learned… just enough.  Last year when Microsoft open-sourced the upcoming CoreCLR, issued a patent covent for it, and announced plans for official Linux and OS X support, my personal interest level skyrocketed.  C# and .NET have since become a main focus of my personal development over the past year.  I’m extremely interested to see how Microsoft’s changing mentality trickles into its wider community, and accelerates the evolution of that ecosystem as a whole.

This new legal model coincides with new versions of .NET components.  These aren’t just incremental updates, they represent a developer experience fundamentally different from previous versions.  Moreover, they’re still in active development, and don’t yet have an official release date as of this writing.

So there are a ton of brand new eyeballs on .NET right now, coming from Hacker News, Reddit, and other online communities.  A lot of the resources they might use to learn about .NET are outdated, at least in terms of this new stuff.  Moreover, some of the new approaches borrowed from other communities might seem alien to longtime .NET developers.  There’s a lot to learn, for newbies and veterans both, and no good “Rosetta Stone” bridging the gap between them.  Here, I’ll talk about the major components from the perspective of Java or JavaScript veterans who are newbies to .NET.

“.NET Framework” vs. “.NET Core” vs. “Mono”

.NET Framework

The Java world has the Java Virtual Machine (JVM), an application that executes bytecode.  This bytecode might come from Java source, or from alternative languages like Groovy or Scala.  There’s also the concept of a Java Runtime Environment (JRE), which encompasses the JVM along with a deep standard library.

The Microsoft model is very similar, executing bytecode with the Common Language Runtime (CLR).  Bytecode typically comes from C# source, but sometimes Visual Basic or F# instead.  The “.NET Framework” is an umbrella term that likewise includes the CLR and a standard library.

.NET Core

The Java world has an open source implementation (OpenJDK) of about 99% of the JRE.  There are some odd bits around cryptography or GUI development which will not or cannot be open sourced, so if you need those then you must use a proprietary JRE build from Oracle.

Going forward, a Microsoft-backed foundation will offer an open source implementation called “.NET Core“.  This consists of a CLR runtime (i.e. “CoreCLR”), and a subset of the standard library.  The full-blown “.NET Framework“, which includes desktop GUI libraries and support for older versions of ASP.NET, will continue to be a proprietary bundle.  The full .NET Framework remains tied to Windows, but the new .NET Core subset will be officially supported on Linux and OS X as well.

DotNet components

Although analogous to the differences between OpenJDK and Oracle JDK, the differences between .NET Core and .NET Framework are much more profound.  As mentioned already, cross-platform support will only be available with .NET Core.  Unfortunately, you still can’t write a desktop Windows app using WPF (i.e. an analogue to JavaFX) and magically run it as an OS X or Linux desktop app.

On the other hand, .NET Core is designed to use the standard library in a more sophisticated way.  The full proprietary .NET Framework is an all-or-nothing monolith, similar to the Java Runtime Environment in size and manner of use.  Meanwhile, .NET Core is fundamentally modular.  You can isolate only those portions of the standard library that your application actually uses.  If you’ve been hearing about “Project Jigsaw” coming with Java 9 next year, but aren’t sure what that’s about, then .NET Core provides a glimpse of Java’s future today.

What this means is that .NET Core allows you to bundle the runtime itself into your deployment artifacts.  Java developers are growing accustomed to their build tools generating single-file “uber JAR’s”, with all of an application’s third-party dependencies bundled.  However, you still need the correct JRE installed on the target machine(s).  The JRE is over a hundred megs, so if you want to embed that too, then you’re probably talking about container technologies like Docker.  With .NET Core, your runtime environment can be stripped down to tens of megabytes rather than hundreds.  So the new build tools make it easy to bundle .NET itself into your application deliverable, with no need for .NET to be present on the target machine(s).  This isn’t quite as dead simple as Golang or Rust, which compiles everything into a static executable with no VM at all, but it’s still a huge leap forward in devop-friendliness.


Off to the side there is Mono, an open-source alternative .NET implementation that’s been around 10 years.  Mono is not a Microsoft project, but rather is sponsored by Xamarin, a company specializing in letting developers use C# to write Android and iOS mobile apps.

Mono has the same limitations as .NET Core, in that it doesn’t try to implement most of the desktop GUI features that are tightly coupled with Windows.  In the long term, Mono and .NET Core may effectively merge together.  Either way, it seems like Mono going forward will be of interest primarily to mobile app developers, and people running older .NET applications on Linux.


For writing traditional Windows desktop apps, very little is changing.  The .NET Framework remains proprietary, monolithic, and tightly-coupled with Windows.  However, the new open source .NET Core offers an intelligent modular approach to deploying server-side code to Windows, OS X, and Linux environments.

In the next section of this four-part overview, we’ll look at the ASP.NET framework and the development and build tools offered under its umbrella.

  • Pingback: Understanding the New Cross-Platform .NET, part 2 (ASP.NET) -

  • Pingback: Understanding the New Cross-Platform .NET, part 3 (Visual Studio) -

  • Pingback: Understanding the New Cross-Platform .NET, part 4 (demo walkthrough) -

  • Steven Dobay

    “My initial impression was that “C#-as-a-language” is about five years ahead of Java…” and Scala is how many years ahead of C#?

    • double years = Math.sqrt(-1);

      • Steven Dobay

        Nah, FUD!

      • Steven Dobay

        Licking microsoft’s ass again?

        • Demetri Obenour

          Call me when you have user-defined value types of arbitrary size, generics that can hold your primitives and even user-defined structs without boxing them, extremely simple and powerful FFI, ahead-of-time compilation, SIMD, LINQ, single-file executable delivery (via Mono), unsafe pointers with pointer arithmetic, unsafe stack-allocated arrays, unsafe fixed-size buffers, fast startup, and proper tail calls (although C# does not expose the last), superb COM interop (on Windows), and an LLVM-based optimizing compiler. Not to mention not one but TWO production-ready (or nearly so) implementations. Both cross-platform.

          • Steven Dobay

            “Call me when you have user-defined value types of arbitrary size” – search for AnyVal, it’s far far far better

            ” generics that can hold your primitives” – we’ve better – look for AnyVal 😀

            “extremely simple and powerful FFI” – search for native apis, not a big thing in 2015

            “SIMD, LINQ” – .net bullshit, just go and explore the possibilities of FP…

            “unsafe pointers… unsafe…” – you can’t be serious!!!

            “and proper tail calls (although C# does not expose the last)” – got it, @tailrec – you can check at compile time

            “superb COM interop (on Windows)” – you can eat windows, however it isn’t a c# only thing

            “and an LLVM-based optimizing compiler” – Scala itself optimize better than cs, it can beat it at any time

            ” Not to mention not one but TWO production-ready (or nearly so) implementations. Both cross-platform.” – yeah, they work like shit on linux… To use them for GUI apps, your only choice is GTK and a shitty IDE. Not to mention slow runtime…

            After all, I only see fanboyism towards c#, nothing more. It’s a pretty average language with a really huge marketing which often posion beginners.

          • Demetri Obenour

            CLI (Common Language Infrastructure) languages have value types that allow one to hold struct pair { long a; long b; }; unboxed. The JVM has no analog to this. This feature is invaluable when one needs to avoid GC allocations (such as in real-time systems). Scala’s AnyVal only avoids object allocation for types with a single field. C# structs do not have this restriction.

            Scala tail recursion only works for a subset of cases. The CLR supports general tail calls — including to functions not even known at compile time. F# exposes this feature.

            SIMD is the only way to get top perf on math workloads from a modern processor.

            As far as unsafe code: I am serious. It can make some code much faster by (for example) avoiding array bounds checks. Also, it allows direct interop with pointer-based native APIs. Of course it should be used with extreme care.

            One thing to point out: it is possible to compile C++ to CIL bytecode. In fact, Microsoft does just that — and not just as a toy. C++/CLI supports most C++ features even when compiling to pure CIL bytecode. Try doing that with Java bytecode. This possibility _only_ exists because CIL supports unsafe code.

            Unlike JNI, the CLI FFI does not require writing C/C++ stubs, which is tedious and error-prone. Writing code that calls foreign functions is unsafe anyway — the difference is solely in whether it is the managed or native code that is unsafe. In C#, one can write unsafe code on the C# side, and avoid having to write new C++ code.

          • Steven Dobay

            “CLI (Common Language Infrastructure) languages have value types that
            allow one to hold struct pair { long a; long b; }; unboxed. The JVM has
            no analog to this. This feature is invaluable when one needs to avoid
            GC allocations (such as in real-time systems). Scala’s AnyVal only
            avoids object allocation for types with a single field. C# structs do
            not have this restriction.”
            – CLI does create objects for value classes.

            “Scala tail recursion only works for a subset of cases. ”
            – as tail call optimization, right? Which isn’t present in c#… Scala supports it in ALL cases and you can check it compile time. This thing isn’t magic.

            ” In C#, one can write unsafe code on the C# side, and avoid having to write new C++ code.”
            – unsafe code will be unsafe at all the time.

            But after all of this “optimizations”, why .net languages are slower than Scala in general?

          • asdfasdf

            Oh yeah…tons of Scala web apps running the world.


          • Steven Dobay

            Yes, of course: twitter, linkedin, coursera, theguardian etc. And what
            is on the .net side? Some crappy bloatware website along with the ms page created by .retards?
            Most websites I’ve seen written in .net is slow like hell while being
            totally dysfunctional. And how about that messy crap(you would call it code) you write with the .net-fanboys? You only use it because of the network-effect not because you know what you’re doing…

          • Peter P

            Anyone can write and push a website up to the internet. Anything with a .aspx extension is a webform, i.e. old school, most likely bad MVP implementation). Take a look at the new .NET Core RPS:



            I have been trying to find the benchmarks of Node to Java to other stacks… with no luck. If memory serves me, Node is 400k rps, Java is near or at 1mill rps.

  • Stephen

    What will be the possibilities to develop on the .NETCore using Mac or Linux? Do we still need VisualStudio.Net ?

    • I go further into that in the third part (note that this is a series of 4 posts!):

      Basically, the “official” story is the new Visual Studio Code editor. It’s very similar to Atom (they share a lot of the same code), and it comes bundled with the Omnisharp plugin for C# intellisense.

      It’s still very early on in the “preview” stage, and I’m sure a lot more functionality will be coming… but to be honest, right now it’s nowhere NEAR the ballpark as the real Visual Studio IDE. Maybe it could be just enough for a team’s HTML/CSS designer to do their thing on their MacBook, while the “real programmers” do their back-end thing on Windows laptops. But I don’t think Microsoft is going to convince back-end or full-stack developers to use Visual Studio Code as their primary IDE. I’m not sure that Microsoft really WANTS to convince people… they may see it as a P.R. thing, that gives some developers just enough of a “taste” to make them want to use Windows.

      As far as non-Microsoft alternatives, there is the open source MonoDevelop IDE from Xamarin. Most Linux distributions have packages for MonoDevelop, and Xamarin has a free binary package for Windows and OS X called “Xamarin Studio”. It’s really nice (especially for being free). If you want to approach C# development on OS X or Linux today, and don’t want to run Windows in a VM or anything like that, then I would definitely recommend MonoDevelop / Xamarin Studio.

      The “Mono” open source alternative .NET implementation does tend to be a bit rough around the edges and quirky about compatibility issues. However, MonoDevelop works great with “official” .NET implementations. It’s going to be awhile longer before the “official” .NET Core is fully production-ready on Linux and OS X… but if you’re just tinkering around and learning C#, then you can probably get by with Mono for now and .NET Core should be there by the time you’re ready for serious work.

      One last item, of totally personal speculation. In my Java work, I am huge fan of the IntellJ IDE from JetBrains. They also make a very popular add-on for Visual Studio called ReSharper. Microsoft’s upcoming changes to .NET and Visual Studio really cut into JetBrains’ business, making a lot of ReSharper’s functionality redundant and unnecessary. So if ReSharper stops making as much sense as a Visual Studio add-on… MAYBE JetBrains might think about converting it into a standalone IDE, and competing with Visual Studio head-to-head? JetBrains makes IDE’s for every other major language, and just launched a new one for C/C++, so it’s not crazy.

      Overall, it would definitely be good to see more options (especially cross-platform ones) for .NET development tools as the community expands. Visual Studio is nice, but the paid versions are ridiculously-expensive compared to the IDE’s for every other language, and it’s very much tied to Windows. I think there will be a market for a cross-platform alternative that is more beefy than MonoDevelop, but doesn’t have all of Visual Studio’s Windows-specific tooling that Linux or OS X developers don’t care about.

  • Thanks for writing this great introduction Steve! I’ve been using .NET since 1.0, looking forward to using .NET Core.

  • Steven Dobay

    Tell us, why would anybody consider .net instead of Scala?

  • Rodrigo De Salvo Braz

    Thanks, this is the first in many pages I’ve seen that actually explains the differences between all these components, and what the consequences are.