Compact Framework is finally dead (or is it)

I think many people know that we used to produce a Compact Framework (CF) provider for VistaDB.  We didn’t do it for VistaDB 4 specifically because of a couple issues that I saw coming, and couldn’t get clear answers from anyone at Microsoft.  I think since the Windows Phone 7 announcement things are finally clearing up, but Microsoft has some confusing terminology.

Compact Framework for Visual Studio 2010

A lot of people noticed this doesn’t exist.  There is no mobile story in the Visual Studio 2010 betas at all.  There were a lot of people saying it would come later, but I had suspicions over a year ago it was going away.  There is no Compact Framework for .Net 4.  But there is a new Visual Studio for Windows Phone as a part of the tools preview.

Silverlight 4 has a compact framework

But Silverlight 4 has a “compact framework” embedded in it.  Not that this is in any way shape or form similar to the actual Compact Framework.  It is a severe subset of what was already a subset of the full .Net framework.  The Silverlight subset of .Net does not include encryption, lots of XML features, ADO.Net, etc.  The Silverlight subset of .Net is really only a few core system libraries that let you write C# / VB.Net code for Silverlight.  You don’t even bind against the desktop runtime, you must target the Silverlight 4 runtime through a special project.  You cannot have a single solution with both Silverlight 4 and .Net 4 as simple output targets (you can do through linking files, etc, but not the same as you could for CF – target).

Windows Phone 7 Silverlight and compact framework

I was recently twit’d a link to a great blog by Abhinaba Basu who works on the NETCF team for Microsoft.  In his posts he discusses the Phone 7 NETCF and how it works to a great amount of detail. 

He states that Windows Phone 7 uses Compact Framework 3.7.  What follows is the summary of his post.

1. NETCF 3.7 runtime (hugely updated Execution Engine)
2. NETCF 3.7 BCL (essentially offering the Silverlight 3 BCL Apis with a small delta)
3. The UI model has been replaced and offers two options
   1. Silverlight 3 UI + Windows Phone device specific features (e.g. accelerometer , location service)
   2. XNA features with Windows Phone device specific features (e.g. accelerometer , location service)

For #2 and #3 the level of difference is same in magnitude as you compare WinForm with Silverlight on desktop. They are simply two different programming models.

In case you hit a 3.5 API  that’s missing then it’s either because it’s (a) WinForm based API that got totally replaced, or (b) a BCL API that the Silverlight profile doesn’t support. The workaround is to search for how to do the same thing in Silverlight (e.g. use XDocument instead of XmlDocument). In some cases you’d get into situations where there is no direct alternative. E.g. there is no P/Invoke and if your code say P/Invoked to get data from a bar-code scanner you cannot do so now.

Now he has some valid statements about how this new NETCF is NETCF – because that was the code they started from initially.  But you cannot call it Compact Framework 3.7 and rip out all of winforms!  Then it is something new.  Every Compact Framework has always had Winforms.  That would be like shipping a Windows 7.1 and it not allowing you to run any Windows 7 apps except Silverlight ones. 

The “new” NETCF is really just Silverlight .Net extracted

This is what I get from the posts.  The “new” NETCF is just Silverlight’s version of .Net extracted to be outside the Silverlight runtime on the phone.  It is not a Compact Framework on it’s own because you cannot write code against it directly, you must use Silverlight.  So why bother even calling it NETCF? 

Honestly, I don’t really care about the version of .Net that is on the phone.  But the terminology drives me nuts!  Don’t call it something that implies a level of compatibility people expect.  If you tell me it is CF 3.7 then I automatically expect everything that was built against CF 3.5 will work.  Not that major parts have been ripped out and modified to match the Silverlight version of .Net.  When did that become a distribution for .Net? 

(hint: it’s isn’t a distro and you can’t target that subset)

Phone 7 doesn’t have a Compact Framework

There, I said it.  There isn’t a Compact Framework on the Windows Phone 7.  You can only code against Silverlight or XNA, both of which will consume this new internal version of NETCF 3.7.

You can write managed code.  In fact, you can only write managed code.

No Native Apps

You cannot write C++ apps for the Windows Phone 7, no unmanaged code.

So if you can’t write unmanaged code, and you can’t write managed code directly against CF…  That means you can only write against Silverlight or XNA.

I applaud the direction of Windows Phone 7

I want to be perfectly clear.  I really like the direction.  Go 100% managed code, I like the addition of XNA.  I think the whole move is fantastic.  But I don’t like the message or terminology around .Net and Compact Framework.  Call it what it is – a new version of .Net specifically for the Windows Phone 7.  It is a new distribution that people will have to get used to the libraries present, the nuances, etc.  But don’t try to sell me on the fact that it is still Compact Framework – it isn’t.

Database Vendors still shafted

Several people have told me that the only reason I care about this is because VistaDB can’t run in this environment.  There is some truth to that, it was what started me down the whole path.  When I heard that Silverlight was going to allow 100% managed code to run within a browser I got very excited.  Then my hopes were smashed when I read about the subset of .Net that was included.  This new version of .Net was never documented as a new fragmented version of .Net.

I tried to reach Microsoft people about this issue.  I talked to so many that I was sick of it.  Many PM’s told me that they understood my point of view, but that most developers are not writing applications to ADO.Net and it is too late in the product cycle to add it in now.  That was for Silverlight 2.  Silverlight 3 and 4?  Same thing.  No one wants databases in their Silverlight apps, I was told.  They can just bind against WCF services on the server. 

So now this new Windows Phone 7 comes along and I think I am finally seeing the light.  Microsoft is going to use Silverlight on the mobile and browser platforms.  It makes good sense to get that code across those platforms to run the same.  What I don’t understand is why data access is a step child.  Most line of business applications still have these needs for databases on the device.  Not an xml dataset, but a database. 

Microsoft the Monopoly has returned?

Is Microsoft is going to provide the local data storage somehow, and not make it a pluggable architecture? That would be going back to their monopolistic practices of forcing all developers to use only their tools and closing the platform to third party extension.  If you have no choice as to how and where your data is stored on the device, then I think all developers lose in the long run.

Sure, you could develop your own data store for local Silverlight files using a custom binary file.  It would be proprietary, no interoperability with other databases, and a complete custom solution.  How do you get that data back to the desktop?  Figure it out.  What about syncing these devices ad hoc?  Figure it out.  Basically Microsoft is taking away one of the key benefits of their development platform – the lack of single vendor lock in for all tools and abilities.  We will end up with 10 different vendors selling solutions that are all incompatible, and the end user is the final victim.

I remember before Direct X was on Windows.  It was downright hard to get a 3D engine to work on a video card.  You had to write a custom driver of your own for every single card on the market. 

The glue that binds data access together

Ado.net was supposed to be that glue binding all the data access in .Net together.  You as the developer were not supposed to care (as much) about the underlying engine, just that it implemented Ado.net and you have a known way to do things. 

100% managed .Net code is not longer equal

100% managed .Net code will not run across all implementations of .Net now.  Take a cleanly written, fully managed application and try it.  You write your new business logic rules in a DLL that has no external dependencies, and all the features you need are included in every .Net runtime.  Still won’t run.

Silverlight won’t run it – you have to recompile to it only.  Even if you built the app to the Silverlight subset, you cannot run that exe or dll in Silverlight.  It must be compiled for Silverlight first.

NETCF won’t run it – even the “old” CF 3.5 wouldn’t run it without being recompiled first.

Dot Net 4 may or may not run it.  Did you include something that is required for .Net Client Profile or the full profile? 

What about Server Core framework?  Maybe.  Depends on what is needed at runtime.  And by the way, you cannot tell if it will work or not at compile time.  There is no target for it.  So go invest that time first to see if it will work. 

IL Code Promise seems to be fading

What happened to the promise of IL code not needing to know what it was running on?  The idea that you could take your C# or VB.Net code and run it on any framework that understood the same IL code?  That is gone from where I am sitting.  The only runtime that seems to be able to achieve this today is Mono, and that is not even run by Microsoft.

The promise of .Net, Java, all these IL compiled languages was to free up the programmer from having to know every detail about each runtime target they run on.  You can compile once and run anywhere!  Sorry, that was a nice utopian dream, but the reality is much messier.

Fragmentation is inevitable?

Most industry pundits will tell that fragmentation is inevitable.  All complex systems must eventually specialize in order to meet the needs of their target without adverse performance or complexity being placed across all systems.

Java has so many requirements and ways to run that I gave up it a long time ago (sorry, I don’t want to know what EJB container I am running in at compile time). 

I was a very early developer for Windows CE as well. I bought the Embedded Toolkit for Visual Studio and spent a lot of time building applications for the early editions.  You had to recompile each app for each target CPU, and had to give out 6 different setups depending on if the user wanted to install from their desktop or direct on the device. Then came the fragmentation.  They added Pocket PC versions, and then even more setups and binaries had to be built.  By the time I stopped building the games and tools I was selling on Windows CE I had build scripts that had to target 27 different outputs.  It was a royal pain, and pretty much unsustainable for anything that was supposed to go to general consumers. 

Is .Net just following the same path?  Fragmenting into specialties? Perhaps.  It worries me quite a bit because Microsoft has made this mistake before, and seems to be heading down the same path again.  I have joked around quite a bit with friends that should buy the domain stopfragmenting.net and put up a petition for Microsoft to stop this fragmentation of the platform that I so dearly love.  I think .Net could be the best thing to happen to programming since the creation of high level languages.  The abstraction from the low level details is the thing that drives such vast programmer productivity increases.  The depth and breadth of the core platform really enables you to do things that would have taken orders of magnitude longer with another platform.  It is this core set of abilities, and a supposition of core stability that attracted me to .Net back in 2001.

Mobile Future?

I think every developer has an eye on the mobile space.  It is obviously the future for so many types of applications.  Even if you just look at extensions to your desktop apps that users can take with them, the market is only going to continue to grow.

Perhaps that means building a database that would run on the desktop and Windows Phone 7 from the same database file.  It would mean a complete separation of the code though, because the two platforms are just not the same.  We have had a lot of interest in using VistaDB within Silverlight, but it can’t be done with the current limitations in the reduced .Net framework present.  But maybe an embedded database that has a desktop version shared by the same file format.  That sounds interesting.

As a thought experiment we have had some discussions around the concept.  We think it would only make sense to ditch SQL entirely, make the entire system based around LINQ.  If you are going 100% managed code, and have no ado.net or other common framework, how do users write queries?  SQL is terrible as a query language for novices to learn, and the complexity of parsing slows down as queries get more detailed.  Being able to write queries in your language would seem to make much more sense.  Not an announcement, just a though experiment.