I have recently run into another problem with Microsoft’s stripping of the silverlight runtime. This time I was looking into using Sockets, because of the crippled WCF implementation. But sockets have been badly stripped. The only thing in the System.Net.Sockets namespace is the Socket class. No TcpClient no UdpClient and no NetworkStream. The System.Net.Security namespace is also gone. Meaning no SslStream.
With no SslStream and a sorely lacking implementation of WCF, silverlight is pretty insecure. Not in the fashion of a computer virus but in how FTP transmits passwords in clear text.
I’m not sure what kind of applications Microsoft expects people to write without being able send files larger then a few megabytes with WCF or to secure their Socket’s data with an SslStream. I’m starting to think Microsoft made a very bad mistake with trying to shrink the runtime so much. I bet people will either write insecure applications and blame silverlight or avoid it all together. Deep market penetration caused by a small download will mean nothing if developers don’t write programs for silverlight.
Anyways that’s enough complaining about the free framework that Microsoft spent a lot of money to write.
A rather simple yet time consuming solution to this issue is to port Mono’s implementation of .Net APIs that are needed. I’m not sure how much effort will be needed, but it should be rather simple to do. Write access to Mono’s repository would be required keep it synced with Mono so that’s not something I can do. Basically you would just sprinkle some compiler directives to exclude classes and methods that are not possible. Also add extension methods to extend silverlight classes that don’t have needed methods. Then write build scripts that compile those for silverlight. For limited subset of classes like the NetworkStream it should be relatively easy to port them to silverlight. Classes like the SslStream will require more effort because of its reliance on Certificate stores.