A coworker of mine spent some hours yesterday hunting down memory leaks in an app that he'd already gotten 'leak-free' back when it was in Silverlight 3. Turns out that the leaks are caused by changes in Silverlight 4 and not in our code. As you surely know, Microsoft releases major Silverlight versions pretty frequently (there's at least one major new version each year). That's great and all when it comes to introducing new features and capabilities, but it truly sucks if you keep introducing new problems as well. The total amount of time (and thus, money) that we've lost hunting down leaks that are located in either the core Silverlight code or the Control Toolkit (also Microsoft code) is just starting to become embarrassingly high.
To give you an idea of what kind of leaks that keep popping up, be sure to check out these links: http://forums.silverlight.net/forums/t/179177.aspx http://forums.silverlight.net/forums/t/179358.aspx http://forums.silverlight.net/forums/t/180702.aspx http://forums.silverlight.net/forums/t/181257.aspx http://forums.silverlight.net/forums/t/171739.aspx
If anyone from Microsoft reads this: please, pretty please, pretty please with sugar on top: can we get a little bit more QA from you guys? If you can put out products like WebMatrix and LightSwitch, than surely you must have enough resources available to make sure that your real development platforms do not become a cost-sink for your customers due to your own lack of quality control, no?
Update: it's also quite telling that the search phrase "silverlight memory leak" is the number one search phrase through which people get to this site. #justsaying
Pingback: Is Silverlight suitable for an enterprise class web-based product UI? | Q&A System