Thursday, April 1, 2010


Initially this post was about WP7 Printing. Two days ago I thought that it would be nice to write about printing from WP 7 and iPhone and the only "compatible" that I could think of was using a WiFi printer (on the iPhone the bluetooth stack doesn't have implemented the SPP and you have to hack it ). It's something I've already did years ago in Compact Framework when I wasn't using PrinterCE or PrintCe and wanted to share it cause it is a new beginning and at some point in a small business application you will need to print something. (it was a proof of concept).
I got everything prepared and started writing the WP7 app when I saw that in the System.Net there is no socket support. I've started digging up, again, in the emulators files wanting to see if the System.Net file is the same on the emulator with the one in the SDK ("\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone"). What I've found out using Reflector is that there is no System.Net in the emulator image, but all the functionality is implemented in mscorlib.dll and there is also the Socket class fully implemented. What Microsoft did is to "cripple" the assemblies in the OS for the SDK. They made the version to be 2.0.5 (for some of the files) which will make compiled programs run just fine on 3.7 which is the the version on the emulator. mscorlib for example in the development tools is 428kb and on the emulator is 1,18MB. Almost every assembly in the SDK is "crippled". If you want to compare the sizes just download this zip.
I wanted to see if I can pass this restriction but the answer is no because the classes that are not available in the SDK assemblies on the emulator are compiled with the tag [FrameworkVisibilitySilverlightInternal, SecuritySafeCritical] (there is more than one tag) which results in a MethodAccessException if you try to use it.
Printing just turned out into frustration. Sockets are there, database support it's there, Microsoft can use it but developers cannot. It's not that it is not implemented (like copy/paste), but somebody decided that it's not safe to use them. On WP7 forum somebody said that this functionality could compromise the user experience and it is not ready for prime time. It is strange cause we have being using sockets and database in NETCF programs for years and never influenced the user experience or seemed not ready.
WP7 is a nice platform but developers don't have what they need, and some of this it's because Microsoft decided that they don't need it. WebIS don't have what they need, Resco also, Mozilla stops development on WM and one week later they have an Android beta version, Skype don't have a WM version anymore should be enough reasons to change attitude.
Microsoft needs developers


  1. I feel your pain. I started development on a UPnP control point application for WP7 only to run into the same hurdle. It's frustrating enough to know that WinCE 6 includes this functionality, but I can somewhat understand MS reluctance to let people pinvoke native code. What I don't understand is why there's no sockets access whatsoever - I'd at least consider rolling my own upnp libraries if it were an option. This is an unnecessary and frustrating limitation on a mobile device.

  2. Congratulations for your article. I fully agree with all your remarks.

    I recently made the same constatation with the System.Reflection.Emit namespace which is hidden for developpers... because of this famous attribute FrameworkVisibilitySilverlightInternal !!!

    But I have a last hope: it is possible to strip the mscorlib assembly from this attribute, and rebuild a ROM using this stripped library!

  3. If you would have a lot of time to invest you could probably hack it, but the question is why would you wanna do that? I expect that they will change a lot of things in the summer beta, but this doesn't mean that I am not frustrated right now. They made some good choices but also a lot of bad ones. I cannot explain why all the brains working for Microsoft didn't get it right from the beginning.

  4. After investigationg further, I have found another interesting attribute: FrameworkVisibilityCompactFrameworkInternal.

    It seems that the Compact Framework v3.7 provides some classes only for Compact Framework only, and other classes for Silverlight only. This means that Microsoft has certainly for aim to have two major solutions for devices: existing Windows Mobile (with CF 3.7) AND Windows Phone 7, with Silverlight.

    So some libraries or classes are not available (at the moment) on one or another solution.

  5. This is good feedback Dan - I am sure someone is listening ;)

  6. Hey - I'm trying to get my head around this...
    I can see [SecuritySafeCritical, FrameworkVisibilitySilverlightInternal] on Socket.

    As Regis suggested, is it not a matter of compiling against that library? - what exactly causes exceptions?

  7. Hrmmm....

    looks like its the CLR, so perhaps we need to sign with a new strong key and find where the matching public key is that the CLR references when it does its checking...?

  8. Oh, forgot to mention - referencing GAC_System_v3_7_0_0_cneutral_1.dll using extern alias Ripped. compiles ok, then throws methodaccessexception.

    The test was:
    tb1.Text += Ripped.System.Net.Sockets.Socket.OSSupportsIPv4.ToString();

  9. This comment has been removed by a blog administrator.