Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as not constructive by kevin cline, Jalayn, Oded, Mark Trapp Jan 24 '12 at 20:25

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

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
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

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.

share|improve this answer
    
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? –  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 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<T> but it might prune some things from the code or merge with some platform specific things and produce a deployment item. –  Steve Evers Jan 24 '12 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.

share|improve this answer
    
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. –  Paul Stovell Jan 24 '12 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

share|improve this answer

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