Unlimited Possibilities through Code
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.
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.
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).
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.
NETCF 3.7 runtime (hugely updated Execution Engine) NETCF 3.7 BCL (essentially offering the Silverlight 3 BCL Apis with a small delta) The UI model has been replaced and offers two options Silverlight 3 UI + Windows Phone device specific features (e.g. accelerometer , location service) 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.
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.
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)
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.
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 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.
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.
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.
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 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.
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.
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.
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.
02/04/2010 05:51 #
I hope there will eventually be an announcement. It seems to be a wide open market with few competitors, well SQL CE.
Wait, since SQL CE is unmanaged, does that mean it won't run on windows phone 7?
03/04/2010 05:53 #
From what I currently gather SQL CE is not present - although they could do it because they have all the unmanaged versions already optimized to those platforms (SH and ARM cpus).
I have heard so much wild speculation that I don't believe anything at this point.
05/04/2010 04:10 #
I do agree that Silverlight is an underserved market, but I think that is by Microsoft design. They want everything to be service driven and use online services. They appear to be skipping over the local database entirely. I guess your phone is never supposed to be out of range of a tower, or your Silverlight app on a desktop that is offline.
08/04/2010 03:34 #
I don't think that Compact Framework is dead: if you dig into the mscorlib assembly from the Phone 7 ROM (some people have succeeded to extract the files from it...), you can see that some classes are protected against their usage by Silverlight (for example, the System.Reflection.Emit namespace, that exists now !), AND others are protected against their usage by the Compact Framework!!!
In fact there are two new attributes, named System.Security.FrameworkVisibilitySilverlightInternalAttribute and System.Security.FrameworkVisibilityCompactFrameworkInternalAttribute, used to protect the code access in the BCL.
©2010-2012 Jason Short. All Rights Reserved. The opinions expressed herein are my own and do not represent my employer’s views in any way.