I had a five day vacation, and opted to write a little game in Silverlight 2 Beta 1. I went down this route, because from what I understood, Silverlight would allow me to create an interactive application that a person could use on a website. Since I could write the back-end in Visual Basic rather than some unknown language (Unknown to me anyway) it seemed like the perfect fit for what I wanted to do.
I installed the SDK and started a new project in Visual Studio 2008. I told it that I wanted to add the Silverlight projects to my already-existing website. It went through a small updater to take my website from DotNet 2.x to 3.5. After it was done, I was faced with the new Silverlight development screen, and so I set about doing some research and getting things setup.
The first thing I did was put a canvas together and made the background a picture of checkerboard. I set the resolution at 600x600 and made each square 75pixels by 75pixels. Everything was squared off to make it easier to work with.
From there, I created round buttons which acted like the checkers. I wrote a handler that allowed me to grab any checker and move it on the board. I then wrote code so that a player couldn't put the checker on a white square or off-the-board. In addition, I wrote in the code so that when the player places the checker it ends up being placed to the closest colored square and lines itself up.
All of this worked out fine, and I was happy with the way Silverlight was working for me.
First Problem Rears its Head.
So the next day I created new tables in SQL Server and prepared to use these tables to store game information and syncrhonize player's moves between turns. Here is where Silverlight starts to go bad. It doesn't support System.Data. Not at all. You can't attach to SQL. Period. No ADO for you! I didn't spend a lot of time trying to research why this decision was made. All I know is that it sucks.
The solution, it appears, is that you have to write a web service and then call the web service from within Silverlight. This seemed cumbersome, but I assumed the reason for this was wise, and so I went about creating a web service. I figured I'd do something simple and just return a string that says, "Hello World!" and make sure I could get everything working properly.
Second Problem Arrives.
Unfortunately, the old way of adding a web reference to a Silverlight project is not supported. Instead the Silverlight team appears (And this one I'm not so sure of) wants you to use Windows Communication Foundation instead of a standard web service. I honestly don't know that much about WCF and its advantages and disadvantages but it appears to be more secure than a regular Web Service, so I went about the task of creating a WCF Service and having it pass the same string of "Hello World!". The examples on the web detail how to do it, and it seems pretty straight-forward. I created a method called "TossCookies" and then added a reference to it in my Silverlight project. Supposedly, if you want the results from the method, you would just call it like this...
BUTTON.TEXT = WCFService.TOSSCOOKIES()
Third Strike? We'll keep going...
Well, that didn't happen here. Instead I was faced with a menu option such as this...
WCFService.TOSSCOOKIESASYNC
Now, I know what asynchronous and syncrhonous is, but I wasn't sure what the deal was here, as this information was part of the examples I was following on the web. It was starting to get a little ridiculous to fetch data from my SQL server with all the hoops I needed to jump through. But I went ahead and did the research and found that the Silverlight team made all WCF communication Async only, and that I had to add a handler for every service call. Their argument is that they don't want the Silverlight application to hang-up while waiting for a response from a web server. I don't think that argument holds a lot of weight especially if the applications are on the same box, and well, because all of this would be easier if they just supported System.Data in the first place for those of us who want to actually use data with Silverlight. But, fine, these guys work at Microsoft so they are wiser than I am.
I set about creating my Async handler and got everything situated properly, which isn't easy because 95% of the Silverlight examples are written in C# and while I can translate C# fairly well, some things escape me and I end up searching for hours to see how other VB developers attempt to do what I'm doing.
Once I got all of this working, I fired off the application and was faced with a new error...
Fourth Strike... Seriously?
Turns out, for whatever reason, the Silverlight consumer of the WCF requires that the website that it is taking the service from must have only one domain name associated to it. So, for instance, if you have IIS running, and you have a website like www.vgnextd.com and you also setup vgnextd.com as an alias. Silverlight will throw an error and bottom up. Supposedly this is "by design" and you either have to create a new website for the service, or remove the other domains from your website, or be smart and create your own factory to repair this stupid design implementation by the Silverlight crew. Luckily, some other smart people on the web blogged about this and produced a simply factory that one can use to get around this issue. I recompiled, updated everything and tried again...
Fifth Major Problem. I give the hell up.
Now the problem turns out to be that the service itself can't be consumed by Silverlight because of a Cross Domain issue. You can't just consume any web service with Silverlight. It has to be allowed to do it based on a security policy XML document that sits at the root of the web server. Which seems simple enough, put the XML file in the root of your web service, run the application again and you get a happy result.
Wrong! When you are developing/debugging Silverlight it doesn't actually run from your website, it runs in a file system directory and does not respect the security XML document. It never even sees the thing. I tried shoving it in the root of C:\ and other places where the file system fires from, but it was to no avail. It wasn't going to work.
Resolution
It shouldn't be this difficult to get at data with Silverlight. While I can imagine that someone may have an "ideal" setup that has every piece perfectly aligned to make everything work, it seems like an excessive amount of fidgeting to get an application running. The error messages are not verbose enough yet to detail what the real problems are, and the lack of a simple data provider makes it not worth dealing with except for weak applications that don't rely on a database back-end.
At my job, it would seem like a great idea to implement Silverlight server controls and utilize them to enhance a web browser experience to one that is likened to the desktop. However, it is not sensible enough or easy enough to approach it from that stand point. In practice, a web service and/or WCF service are capable of moving data back and forth but are not as robust as having access to System.Data. The Silverlight team should rethink the policy towards not including System.Data, and/or write a data wrapper themselves that can quickly get someone up to speed with using their data on Silverlight without the need to jump through so many hoops to get it working.
As for Checkers. I'm going to abandon the project until Silverlight becomes easier to work with. In the meantime, I'm going to begin work on a new ASP.NET/Ajax Shoutbox for DotNetNuke. Look for that blog posting in the future.