There are many "flavors" of the .NET Framework:

  • Full ("normal")
  • Client profile subset
  • Silverlight in web browsers
  • "Silverlight" on Windows Phone
  • Compact framework
  • WinRT

When C# code is needed on a new platform, it would seem that Microsot prefer to take the full CLR and strip it down to a small subset, creating new assemblies and moving types around, instead of just using existing assemblies such as those in the BCL. Silverlight for example has different classes/methods to WPF (even down to some methods having slightly different signatures or very different implementations), instead of simply referencing the same implementation of List<T> as WPF.

Is this the ideal architecture, or a sign of legacy? Shouldn't the BCL run on all platforms, with just different presentation/IO libraries on each? Or are the BCL and other libraries too bloated, and splitting them out would create too many backward compatibility problems, to be acceptable?

If we started from a blank canvas and weren't worried about backwards compatibility, would the current situation really be the best way to handle multiple platforms?

  • 7
    What's with all the close votes? This is a perfectly legitimate question. Commented Jan 24, 2012 at 19:50
  • 2
    This looks like it might get closed, probably because it's worded a bit judgementally (it sounds as if you've already decided that it's "badly architected"). You might want to rephrase it as "why are there so many flavours of .NET?" Commented Jan 24, 2012 at 19:52
  • 1
    @FrustratedWithFormsDesigner is right. The question starts with a bias against .NET. If the tone was more neutral I suspect no close votes would have been cast.
    – Oded
    Commented Jan 24, 2012 at 19:55
  • 2
    It feels to me like you are trying to start an argument, not looking for constructive answers to your question. I'm guessing that is why you are getting close votes.
    – Tyanna
    Commented Jan 24, 2012 at 19:55
  • 2
    @Oded and others - I've reworded the title and body, hope that meets with your approval :) Commented Jan 24, 2012 at 19:59

3 Answers 3


What Microsoft is doing, splitting the routines into multiple packages, is common. There is a version of .NET that runs on single board computers (.Net Micro Framework) with limited memory. It would not make any sense to include in that version everything required to run a full graphical user interface for example.

If you look at Apple, the iPhone does not contain all the routines that one would find on a Mac.

  • But rather than a developer copying/pasting the code to List<T> to create Micro Framework List<T>, shouldn't the BCL be split up properly such that the binaries run on all platforms? Commented Jan 24, 2012 at 19:48
  • 2
    In other words, shouldn't making the code run on another platform just be a case of choosing which assemblies to support? Commented Jan 24, 2012 at 19:49
  • 1
    Java does this as well. For instance, Java Card is a subset of Java.
    – Bernard
    Commented Jan 24, 2012 at 19:54
  • 2
    @PaulStovell: I'm not sure how MS does it... but I wouldn't be surprised if MS had a separate build path/script (to put it lightly) that takes the code and builds it for the target platform - so it's not a copy/paste of List<T> but it might prune some things from the code or merge with some platform specific things and produce a deployment item. Commented Jan 24, 2012 at 19:57

I don't think .NET is the problem. While there are various runtimes, they are still compatible, which is why technologies like the Portable Class Libraries works (for the majority of the runtimes you listed).

For example, shouldn't each flavor reference a single, shared assembly called "System.Collections.dll", instead of each runtime having its own copy of System.dll/mscorlib.dll with various copies of the collections?

Why is this needed? As long as they are all compatible (again, see the Portable Class Libraries), this shouldn't matter, as the BCL is part of the runtime itself, and distributed in tandem.

  • Shouldn't I be able to write a class that only uses List<T> and run it on any platform without creating a portable library? Or shouldn't List<T> itself be in a portable library? Portable libraries feel to me like a workaround rather than part of an elegant design. Commented Jan 24, 2012 at 20:01

.NET is essentially replacing and expanding com objects in a windows environment. It's also used to identify a lot of vastly different technologies, imagine if Adobe renamed all their products to have a common word in their name, that's sort of whats happening with .NET

Not the answer you're looking for? Browse other questions tagged or ask your own question.