Experiencing: Silverlight 2 beta 2

For those of you who have been living under a rock for the last few weeks: Silverlight 2 beta 2 has been released!

I must say though: I wasn’t that impressed at first. Not enough new stuff, not the controls I wanted, quite a few bugs, … but I got to know the new features better, and, well, I’m slightly impressed now. I’m not going to document all the new features here (lots of sites do that already) – just the ones that stand out, for me.

Let’s start with the “bad”: only one new control (the tabControl)? Still only basicHttpBinding in WCF? I was at least expecting a simple ComboBox…

… on to the “good”. I’ve only got one word for you: VisualStateManager! What a wonderful addition – no more coding&running animations from codebehind for simple state changes – once you get used to it (and it’s quite straightforward), you’ll be convinced this is a real time-saver!

Silverlight 2 is still beta software, so you can expect to encounter quite a few bugs. Here are a few I’ve encountered, including solutions – hope it helps some of you out!

1) When using the VisualStateManager, you might notice Visual Studio will give you an error on the line ““: ‘The attachable property ‘VisualStateGroups’ was not found in type ‘VisualStateManager”. This code is, btw, generated by Blend – it should work.

And it does :-) It’s just that Visual Studio thinks it doesn’t.

Solution: try building your app, it just might work. And if it doesn’t (and fails to build due to this specific error), close the file containing the VisualStateManager-syntax. Your app will build&run.

2) After some heavy switching between Blend & VS, I noticed that, when running my app, the latest version wasn’t what was being shown. (Re)building with F5 just started an older version of my app, ignoring my recent changes (even after cleaning the complete solution). I’ve had this happen quite a few times already…

Solution: right-click your SL-app > Debug > Start new instance. The latest version of your app will build&run. Another way to make this work is changing the port of the development webserver.

3) WCF calls are giving me headaches! I made a very, very simple application: SL client calling a WCF service from a ServiceHost. Added crossdomain.xml, added reference via VS, it automatically created the necessary config-files, all very easy. But: calling my WCF service kept on giving me 404-errors… I checked and rechecked everything: the binding was correct (basicHttpBinding), the service was running correctly (I could access it, view the WSDL, …), the automatically created ClientConfig-file was correct, everything looked ok.

So… I tried exactly the same in SL2B1, just to make sure I wasn’t missing something – but in beta1, everything worked as you’d expect it to.

Solution: well, apparently there are quite a few issues with WCF calls and SL2B2. Ranging from failed installs to wrong config-files to wrong bindings to… But in my case, the problem was situated on the crossdomain.xml-file. After reading through a few posts on the Silverlight.NET-forums (this post and this post were very helpful – check ’em out if you’re having WCF issues), I decided to try and change the crossdomain.xml-file to a clientaccesspolicy.xml-file (for the correct xml, see this post). After this, my service call worked flawlessly!

I’m absolutely positive my crossdomain.xml-file is ok, but apparently beta2 has some issues with it. So, if you’re have problems with WCF service calls from SL, and you’re using a crossdomain.xml-file, try using a clientaccesspolicy.xml-file instead.

Happy coding/designing!

 Tweet about this on TwitterShare on LinkedInShare on Facebook