And Three More Silverlight Complaints

Unhelpful error messages rank high on my list of complaints about Silverlight and WPF. Take this particular error message: AG_E_PARSER_BAD_TYPE. I get it pretty regularly, but this particular instance started showing up about 15 minutes ago. The location that it points to (presumably in App.xaml? – it doesn't actually say) has nothing to do with the error in question.

The error is presumably triggered by some XAML I screwed up somewhere in one of the 50+ different XAML files in my solution. I have no idea which file (I just did a big search-and-replace as part of a codebase-wide refactor). So first of all: AG_E_PARSER_BAD_TYPE? Since when does that qualify as an error message? We're not doing sockets programming here, folks. The CLR allows for an incredibly rich set of exceptions. So why the incomprehensible error message? But more to the point, why am I being pointed to the wrong location? One of the things that makes the Silverlight tools for Visual Studio feel so frustrating is that they know which file is problematic, and they know precisely what the problem is, and they refuse to tell me. Yes, I know my reaction makes Silverlight a little more anthropomorphic than necessary. But it sure as heck feels like the Microsoft tools are out to get me sometimes. (For what it's worth, after an hour of troubleshooting, I opened the solution in Blend, and for once, Blend gave me what I needed to know, and immediately highlighted the problematic file.)

My second complaint is bogus error messages, i.e., error messages when there's no error. Again, to take one example of many, in one particular form in my project, Visual Studio lists 27 different errors, all having to do with certain local controls not being found.

The assembly in question (SlideLinc.Client.dll) and the associated namespace (SlideLinc.Client) are registered correctly in the form, and indeed, the form loads and executes correctly at runtime. For once, Blend recognizes this, and doesn't raise any errors. In other words, there's no problem. But I've tried six ways from Sunday to make those errors go away in Visual Studio, and nothing has been successful. In this particular case, it's generally not that problematic – except when it comes time to track down a real error, and you have to fight your way through dozens of bogus error messages to find the right one. (It's at least a tad ironic that these bogus error messages at least show up at the right time, i.e., when the app is compiling, and are able to point me to exactly the place where they – incorrectly – think the error is occurring. In contrast, the quite real AG_E_PARSER_BAD_TYPE error that I ran into above showed up way too late, at runtime, and wouldn't even tell me which file it was occurring in. It's this kind of stuff that makes you pull your hair out – and which has cost me at least a month of troubleshooting on my current project.)

My third complaint is more specific, and has to do with the Add Service Reference feature in Visual Studio. Specifically, I run into two reoccurring, distinct, but possibly related bugs when I try to update my service references. Neither of these occurred with the March 2009 SL3 CTP, and both started showing up immediately after I upgraded to SL3 RTW.

1. Periodically (about a third of the time), when I pull open the "Configure Service Reference" dialog box, the "ObservableCollection" option for collection types isn't available; instead, there's something listed called "(Custom)", which is apparently interpreted as "Array[]". So when it generates your proxy references, it generates any list of values as an array, rather than an ObservableCollection. This breaks all your existing code, which of course was written to expect an ObservableCollection in those instances. What usually fixes it for me is simply restarting Visual Studio. Nothing else seems to work.
   
2. The second problem is that periodically the Reference.cs file fails to generate – which of course also breaks all your existing code. I ran into a tip from someone, somewhere, who recommended deselecting the option "Reuse types in specified referenced assemblies", and then select only "System.Core". When I do this, and then I update my service reference, it seems to fix this pretty reliably. Sometimes it happens anyway, at which point in time I simply change which referenced assemblies it should try to reuse, and then immediately everything works again.

On this last point, I should note that lots of other folks besides me have been running into these issues. Indeed, I don't know anybody who regularly works with Silverlight and WCF who hasn't run into them. It's also been quite well-documented on the forums. I've tried to report these bugs on the MS Connect website, but I can't figure out how: I don't seem to have that option.

I should note that the Silverlight runtime itself seems to be pretty darned stable, all things considered. I've beat the thing to death with stress tests, and haven't run across any bugs worth mentioning that weren't my own damned fault. All the real problems seem to show up in the various tools you use to build Silverlight applications.

It seems to me that there are going to be some massive improvements to the .NET platform coming with the impending .NET 4.0 / Visual Studio 2010 release. I keep hoping that the reason these bugs haven't been fixed out in the wild is that MS is working so hard to improve the quality of that upcoming release.

I can hope, can't I?