In my previous post I have discussed about why Silverlight development in not traditional, and I talked about the biggest issue user and developers have with Mouse Button, I have made a list and I am trying to point and clarify all the misconceptions about Silverlight that are associate with traditional web development, where developers just expect thing to be like they were in ASP.NET or HTML.
When I first started with Silverlight I was a bit frustrated because nothing seem to work as it was meant to be I was expecting .NET libraries, resources and just about anything that I knew about traditional web development, the first day I started with Silverlight 1.1, I saw "Hello World" example and then decided to replace that text with a random number, I have used Cryptography quite a lot earlier and I like to use PRNG random number instead of Random, and so I wanted to import/include System.Security.Cryptography and I failed, I tried again and failed I tried System.Data failed, I tried System.Speech failed, this was too much for me and frustrated I gave up. Silverlight altogether.
And had it not been for a boring weekend few months later and that moment of curiosity of why I can't import those libraries in my Silverlight application, I would never have bothered with Silverlight. I think there are many developers out there who try what I did and who gave up the way I did, and the only reason is Silverlight is untraditional.
So what exactly am I bragging about? And what is so untraditional about Silverlight that I got wrong ? Why Microsoft restricted access to them libraries? Why was my misconception? Or did Microsoft really restricted libraries? The answer is simple and the impact is big.
Silverlight doesn't require .NET framework at Client/Server.
Huh? What? But Silverlight require .NET 3.5 isn't? Yes, of course it does! Is it confusing? Ok lets first talk about Silverlight Plug-in, do you know that "Silverlight is cross-platform"? And Silverlight plugin (1.0, 1.1, 2.0) is/will be in few MBs, So do you expect to installed all the framework in that few MBs? Or do you propose to install .NET framework on Mac/Linux? And do you also know that you can host Silverlight application on Linux servers (without .NET framework), just by setting MIME types for XAML?
So we don't need .NET framework on Client or Server?
That's what I said, didn't I?
But we need .NET framework 3.5 for Silverlight!
Yes, you need .NET framework 3.5 for Silverlight applications but not to host or render them in browsers, you need the framework to compile the Silverlight application. You need .NET Framework at compile time and not runtime.
So what does it mean to Silverlight applications? And what actually happen?
Silverlight when complied creates a DLL (Dynamic Link Library) which includes all embedded resources (if any) along with the complied managed code, Silverlight compiler uses .NET Framework 3.5 to compile this library, when a Silverlight application is initiated with Silverlight plug-in installed, the plug-in tell the browser to go and download the DLL or the downloader object and interprets the DLL to the browser to render or perform tasks.
So it means Silverlight can only include that libraries that Silverlight plug-in (running at the client) can interpret?
Yes and it is the reason you can't include any library reference in Silverlight.
Coming back to the examples for libraries that I have given earlier System.Security.Cryptography, System.Data and System.Speech. Since database is always present on the server, there is no point in using System.Data in Silverlight ever, Silverlight works in a browser sandbox and can't access generic hardware so System.Speech is out of question, but System.Security, well there is something that we can expect to use in Silverlight but can't because of choice, again System.Security uses .NET framework so the plug-in should be able to interpret it by itself, and if it is implemented then the plug-in size might increase by another 1MB, so the plug-in size will increase with every library they include, and while Microsoft is struggling with adoption of Silverlight, consider to include these libraries.
So what libraries will be included in Silverlight 2.0? And how big the plug-in will get?
That is Microsoft to answer, not me. And I am glad I don't have to make that decision to balance plugin size.