Search

Monday, September 07, 2009

.NET Compact Framework BCL < .NET BCL

Hyderabad Zoological Park

Over twitter some folks are regularly discussing about the fact that there are some chunks of desktop .NET Base class library (BCL) that are missing on the .NET Compact Framework (.NETCF). So I thought I’d post the rationale behind things that are missing and what criteria is used to figure out what makes it in.

First of all, .NET and .NETCF use completely different runtimes. So the BCL code doesn’t work as is. They need to be ported over. Something being available on the desktop reduces the effort of our BCL team but still significant cost is involved in making it work over NETCF. This means that its not as if everything is available on .NETCF BCL and we cut things out (elimination process), but the other way round where we start from 0 and we need to figure out whether we can take something in. In that process we use some of the following rationale.

  1. ROI: Does the user scenario that it enables on a mobile device justify the cost
    System.CodeDom.Compiler. Yea right you expected to compile on the phone didn’t you :)
  2. Easy workaround available: If there is an acceptable workaround for a given API then it drops in priority. A trivial example could be that we ship some method overloads but not the other. E.g. Instead of shipping all overloads of Enum.Parse we drop Enum.Parse(Type, String) and keep only Enum.Parse(Type, String, Bool).
    This applies at the level of namespace or Types as well.
  3. Lower in priority list: It needs work to get it done and it’s lower in priority than other things that is keeping the engineering team busy.
    If there are a lot of request for these features and not good/performant workarounds available then it will go up the priority list and make it to future version of NETCF
  4. Too large to fit: Simply too large to fit into our memory limitations
    E.g. Reflection.Emit which leads to other things missing like Dynamic Language Runtime, Linq-to-SQL
  5. No native support: It uses some underlying OS feature which is either not present on devices or is not relevant to it
    WPF, Parallel computing support

With every release developers ask for new features and we also negotiate to increase NETCF footprint budget so that we can include some (but not all) from those requests. To choose what makes it in we use some of the criteria mentioned above.

Given the system constraints under which NETCF works a vast majority of the desktop APIs will continue to be missing from NETCF. Hopefully this gives you some context behind why those are missing. If you approach NETCF simply from trying to port a desktop application then you would face some frustration on the missing surface area.

BTW: Do post your comments on this blog or on twitter (use the #netcf hashtag).

<Update: I made some updates to this based on feedback />

No comments: