9

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?

Paul Stovell
  • 1,689
  • 1
  • 9
  • 14
  • 7
    What's with all the close votes? This is a perfectly legitimate question. – Mason Wheeler Jan 24 '12 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?" – FrustratedWithFormsDesigner Jan 24 '12 at 19:52
  • @FrustratedWithFormsDesigner: We have this same conversation when we talk about code smells. I think it would be difficult to suggest that something is bad design (or bad in general) without coming off as judgemental. It's still a perfectly legit question though. – Steven Evers Jan 24 '12 at 19:54
  • 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 Jan 24 '12 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 Jan 24 '12 at 19:55
  • 2
    @Oded and others - I've reworded the title and body, hope that meets with your approval :) – Paul Stovell Jan 24 '12 at 19:59
  • Sounds like [vendor lock in](http://en.wikipedia.org/wiki/Vendor_lock-in) to me. Microsoft is good at that – Raynos Jan 24 '12 at 20:04
  • 1
    Hi Paul, while this might make a great discussion forum topic, speculating about software product lineups is outside the scope of the Stack Exchange style of Q&A. –  Jan 24 '12 at 20:26
  • Not to mention that it isn't really constructive for us to speculate on why MS did it this way. – JohnFx Jan 24 '12 at 20:35
  • 1
    Paul, I voted to close your question because answers will not help you to choose an action; they can only affect your opinion. – kevin cline Jan 24 '12 at 21:31

3 Answers3

5

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.

JonnyBoats
  • 1,783
  • 13
  • 11
  • But rather than a developer copying/pasting the code to `List` to create Micro Framework `List`, shouldn't the BCL be split up properly such that the binaries run on all platforms? – Paul Stovell Jan 24 '12 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? – Paul Stovell Jan 24 '12 at 19:49
  • 1
    Java does this as well. For instance, [Java Card](http://en.wikipedia.org/wiki/Java_Card) is a subset of Java. – Bernard Jan 24 '12 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` but it might prune some things from the code or merge with some platform specific things and produce a deployment item. – Steven Evers Jan 24 '12 at 19:57
1

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.

Reed Copsey
  • 1,001
  • 6
  • 7
  • Shouldn't I be able to write a class that only uses `List` and run it on any platform without creating a portable library? Or shouldn't `List` itself be in a portable library? Portable libraries feel to me like a workaround rather than part of an elegant design. – Paul Stovell Jan 24 '12 at 20:01
1

.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

Ryathal
  • 13,317
  • 1
  • 33
  • 48