Tater Salad

You can chop em up, mash em up, or boil em in a stew.

  • Categories

  • Archives

Silverlight in JavaScript (1.0) vs. Managed Code (2.0, formerly 1.1a)

Posted by caseyrayl on January 18, 2008

I have recently begun work on a Silverlight 1.0 project and for the first time had the (un?)fortunate opportunity to write a significant amount of JavaScript. I am not sure how hotly this topic is debated, or if it is even debated at all, but I wanted to come out and discourage anyone thinking about building a Silverlight RIA from doing it in JavaScript.

Now I am not knocking the JavaScript implementation of Silverlight. It works well enough. But JavaScript is a clunky and cumbersome development environment. Browser consistency is a problem, performance is exponentially slower than managed code, and the language has huge deficiencies like a lack of type safety and nothing close to the facilities provided by the .NET framework.

Unfortunately 2.0 is still in alpha, and I know that building anything with alpha technology is a scary prospect. While it isn’t much consolation right now, I think the beta will be a much firmer platform, and one that can be carried forward into release. If you can hold off till it hits I think you will be in a much better position. If you absolutely can’t wait, use Flex.


Posted in Uncategorized | 3 Comments »

Debugging Silverlight 1.1 Alpha Refresh in Visual Studio

Posted by caseyrayl on November 26, 2007

I have gotten back into some Silverlight code and have been playing with the new version of Visual Studio 2008 and the Silverlight 1.1 alpha refresh. Since picking it back up I have run into some interesting speed bumps that were not there my first time around.

The 1.1 alpha refresh introduced a stricter Silverlight security model which completely disables access to any asset on the local file system. This means if your app utilizes external resources, you have to debug it via a web project of some sort. I was already using an IIS project for deployment so switching over wasn’t a big deal for me, but I had to go through some rigmarole to get it set up initially. For ASP web developers, it is probably all old hat, but for someone with no prior experience, it is an annoyance to have to set it up just so you can debug a Silverlight application. Plus you have to be running certain versions of Windows. Overall not a very friendly way to get your feet wet with Silverlight.

So what is the answer? Well there is an internal web server built into Visual Studio called Cassini. Using it and VS you can quickly create a web project that you can then link to your Silverlight application and test locally.

The process goes like this: right click on your solution that houses your Silverlight application and select Add -> New Website. In the dialog box that appears, select ASP.NET web site as the template, make sure the Location combobox is set to “File System”, and enter the path you would like the site created in. Once the project for the site is created, right click on it and select Add Silverlight Link. A dialog should appear that lists your Silverlight projects within the same solution. Click on the one you want linked in. If it asks you if you want to enable Silverlight debugging, say YES! You should now see the files for your application that are set with a build action copied into your web application. All that remains is to right click on your start page and select Set As Start Page. You should now be able to launch your Silverlight application locally and do anything you need to for testing.

If for some reason you find that the debugger isn’t loading your symbols for your application, or inexplicably skips over your break points, check that the debugging properties are correctly configured. Right click on the web project and select Property Pages. In the dialog box, select Start Options on the left side. At the bottom you will see the debuggers that are enabled for your project. If Silverlight is already checked and you still can’t debug it properly, try enabling Native Code as well. I have run into several instances where I have had to do this to get the debugger working.


Posted in Uncategorized | Leave a Comment »

2nd Interview Online.

Posted by caseyrayl on August 2, 2007

Just a quick post to let everyone know that the second Silverlight interview I did is live.  You can watch it here.  Be forewarned that it is pretty long, weighing in at a hefty 28 minutes.  I hope you enjoy it. 


Posted in Uncategorized | Leave a Comment »

Intertron Superstar

Posted by caseyrayl on July 7, 2007

I went down to Redmond recently to do a few interviews about the game we just built in Silverlight.  The first one is available now over at on10.  Overall it was a good experience, and I will link the other interview once it is online.


Posted in Uncategorized | 1 Comment »

Silverlight Game Development Post Mortem

Posted by caseyrayl on June 28, 2007

Well the game that I alluded to in some of my previous posts is now live. I am biased of course, but I am pleased with how it turned out. I think it is pretty fun to play and that is really the most important thing.


Anyway, there is quite a bit of discussion around the Flash/Flex and Silverlight development communities about which platform is better and why. While most of these conversations have been primarily speculative I think that after going through an actual development cycle with Silverlight I have something to contribute to the conversation. The Adobe camp radicals would have you believe that Silverlight will never amount to a hill of beans, and the Microsoft camp radicals would have you believe that Silverlight is going to put Flash six feet under. In my opinion they are both wrong. Right now a meaningful comparison between the two products is very difficult because of the state of Silverlight. It just is not fair to compare a full release product suite with one that is in various stages of development. In spite of that I am going to talk about some of the things that Zero Gravity utilized successfully in Silverlight and the processes we went through to build the game along with some of the things that are lacking and caused me some frustration, discuss some design considerations, and then wrap up with what I think the current state of Silverlight is.


As I mentioned in my previous post, we had quite a bit of concern initially that the size of xaml files would make web delivery of a moderate to large scale Silverlight application prohibitive. However the ability to archive assets and extract them at runtime provided a solution which the game utilizes in the form of a preloader. Virtually every asset, with the exception of some very small xaml files embedded in the assembly for the textbox control, are archived and pulled during the preload process of game initialization. Also, all of the video (wmv), audio (mp3), and images (png and jpg) in the game are built from dynamic MediaElement and Image construction. Their sources are set directly from the archived asset. I expect that asset archiving of this nature will quickly become a standard practice in Silverlight development unless Microsoft jumps the gun and gives us utilities to abstract the process entirely.


Included in our asset archive are all of our xml files that specify the metadata about each game board and the definition of the boards themselves. Unfortunately right now the only utilities that Silverlight provides to manipulate xml are the XmlReader and XmlWriter classes. For those who are not familiar with the .NET framework, the XmlReader class is a low level xml string tokenizer that allows forward only analysis of an xml string. It is a cumbersome way of parsing xml and will hopefully become unnecessary due to the eventual introduction of LINQ to the Silverlight platform. You can learn about LINQ here. I have not seen a specific date on when it will be introduced, so if you plan on building a Silverlight application anytime soon, say hello to the XmlReader.


On a more positive note, network communication development in Silverlight went surprisingly well for us. Initially I stubbed out a class where I intended to write my client side code for the communication to the web service that I knew was going to be built with ASP.NET and dummied up the returns so that my UI development could continue. Now normally in a Flash world, at some point myself and the service engineer would sit down and agree upon our data exchange format and API, then go off and write our respective pieces, and then come back and integrate them. But in Silverlight, we were both working in Orcas under the same project solution, and the service engineer was able to build his project right there and write both sides of the communication interface, one in his web service, and the other in my stubbed out class within the game. At that point all I had to do was refactor a bit of code to make sure my method calls matched his slightly modified API (due to emerging specs of course) and we were done. We were both pleased with how it progressed and the efficiency we gained from building the game with that paradigm.


Alright so enough of the infrastructure stuff and on to some view coding. Unfortunately when I started this project I had only an understanding of the C# language, but lacked any understanding of conventional visual windows programming. Perhaps if I had that understanding the concept of custom controls would have immediately clicked for me, but I didn’t discover their power until several weeks in. At this point I would equate them to Flash components because they serve the same sort of role but with an added facility which became the solution for a real stumbling block for me in Silverlight. In xaml markup, you can name your visual elements using the x:Name property and then use that name to locate the element in your managed code. The catch is that the names must be unique, regardless of where they fall in the structure of the xaml. Giving two elements the same name in a xaml file will cause an exception when the xaml is read, regardless of how you try to read it. Another even more problematic issue with this is that even if you have unique names in a xaml asset, you can only ever have one of those registered in the display list, because if you create another and attempt to add it, a name collision is occurring somewhere in the tree. The solution to this is the custom control. Each control creates a namescope which prevents name collisions between multiple instances of the same asset. Once I discovered this, I refactored all of the games board elements such as the player, the ship, the blocks, tubes, teleporters, and switches over to controls. The controls then encapsulate all the logic necessary to manipulate the asset, including its xaml defined animations, and expose functions necessary for clients to use them. I also used controls to expose properties in a simpler and more familiar way. A couple of examples of this are Canvas.LeftProperty masked as an “x” setter, a xaml defined ScaleTransform masked as a “scale” setter, and a xaml defined RotateTransform masked as a “rotation” setter. In general I do not think that the power of controls is adequately explained in the Silverlight tutorials, but then again, the documentation is currently quite sparse, so the power of a lot of things is not adequately explained.


The other view element that I want to discuss is controls and containers. Basically Silverlight lacks some very fundamental controls right now, most notably a text input facility, and does not support containers at all. Their absence means a huge loss of productivity for anyone currently trying to build a Silverlight application. Zero Gravity uses custom code to achieve its liquid layout and uses a freely available controls/containers library published by Dave Relyea which you can get here to implement its text input fields. Daves’ controls were quite helpful to me but they cannot take the place of actual Silverlight framework support for these facilities (Dave never claimed they could). The upside to this situation is that I have been told in no uncertain terms that a control and container library will be added to Silverlight but I do not expect it by the release of 1.0.


The promises of controls and containers are not the only promises Microsoft is laying down right now. Data binding and skinning support are also slated for the framework. When they get included is something I cannot answer, but the fact that these discussions are taking place, combined with the current state of the 1.1 alpha leads me to believe that Silverlight has a very bright future in the development community. However, that community is only half of what makes successful RIAs. We can’t forget about the design community and I do not think they are nearly as excited about the power of the Expression Suite and Silverlight.


Expression Blend is the primary animation facility for xaml assets and from my perspective it is so far out of sync with Silverlight right now that an efficient workflow between developer and designer isn’t achievable. Basically Blend is entirely geared toward WPF right now and the xaml it produces isn’t going to function in Silverlight without rework that a designer isn’t likely to do. The end result was that I had to edit quite a large amount of xaml by hand to get the assets to work. I don’t blame my designers for this at all. Sure you can see the xaml that Blend is building in the program at any time, but should a designer really need to understand that Silverlight does not support the Viewbox yet and that Canvas has to be used for everything? No, that would be ridiculous. This particular stumbling block is very much on Microsofts radar and I know they intend for the integration between the applications in the Expression Suite and Silverlight to be very tight. I am not worried about them fixing it in the future.


However, there are other design related problems that unfortunately I cannot speak to first hand, but can give at least an impression of. Blend is reportedly a fairly weak alternative to Flash when it comes to animation. Apparently the tools are rudimentary and the control required to animate efficiently is absent. I think that if anything is going to slow down Silverlight, this is it. Microsoft cannot sway a large number of designers the way the can sway a large number of developers because the pool of developers ready to learn Silverlight is so vast, while the pool of designers ready to leave Adobe is so small. Only time will tell with this and I wish I could give more insight into the situation, but I cannot animate my way out of a wet paper bag in Flash or Blend so I will say no more.


Looking back over this post you might have caught on that there are a lot of things left “to the future” with Silverlight, which goes back to my original point that making comparisons with Flash right now is just premature. The potential of Silverlight is obvious and very real, but I would caution anyone looking at it as a solution today. Right now Adobe has a superior technical and design platform, and that isn’t going to change over night. I believe Microsoft is going to close the technical gap quickly, and how fast they can close the design gap remains to be seen. Overall I would encourage any RIA developer out there to investigate what Silverlight has to offer because it might not be long before it becomes a very marketable skill.



Posted in Uncategorized | 4 Comments »