Let there be no mistake made that it’s pretty exciting that Microsoft is starting to release early bits for some of its products for us to test out. Windows 7, Visual Studio 2008 (Orcas), VS2010, VS11, Win8, etc. are just a few that come to my mind. These early releases are full of bugs and are definitely not production quality, neither should they be. So I’m just going to go ahead and preface everything I’m going to write with, “The Win8 WinRT framework is pre-beta and therefore should not be expected to work exactly as prescribed.” With that said there are a few key features that don’t work as expected and I’ll be touching on some of those.
I’m currently on a project with two other developers here at InterKnowlogy, Dan Hanan and Carmine Sampogna. We are at the tail end of porting what we call our Kiosk Framework to Windows 8 on the WinRT framework. The project has been a ton of fun and we’ve learned a lot. The project has not been as straight forward as we would have hoped. WinRT XAML is similar in capabilities to Silverlight 3 and 4. Sometimes you still feel like you’re in SL2, but again it is pre-beta software.
Carmine and I are running Win8 from bootable VHDs that we made following the steps in a post by another coworker Travis Schilling. Dan received one of the coveted Win8 Tablets from BUILD. And we’ve installed the full developer preview of VS11.
We found some help from someone who had already encountered the problem: http://metrotrenches.wordpress.com/2011/10/07/tailored/.
DependencyProperties are not typed: DependencyProperties are very important when designing UserControls that you intend to be used in different contexts with different DataContexts. In the current version of WinRT DPs are not typed, which is a big bummer. This work around was found at: http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/4fed80a8-1343-41ca-8c27-b20a00689f65.
ElementName bindings only sorta-kinda work: ElementName bindings help simplify and centralize values. One element contains the values and a bunch of others can grab those values. They are very important when it comes to attempting to implement a MutltiBinding workaround. However, we have found that in many cases ElementName bindings don’t work while in other cases it does. Not sure why.
Can’t retrieve non-template resources such as double, GridLength, Thickness, etc.: I discovered this because ElementName bindings were failing in a very specific case.
Works just fine if you are accessing a DataTemplate, ControlTemplate, or Style. However it seems to fail for structs, value types, and complex types.
DataTemplates cannot contain ContentControls that use ContentTemplateSelectors in some cases: I was trying to refactor a DataTemplate into App.xaml (because we can’t have multiple ResourceDictionarys) and I would continually get an Engine Execution Exception.
No Implicit DataTemplates: However there are implicit Styles.
One of the most annoying parts about development is that every run of our application is cut short by a FatalExecutionException which claims may be a bug in the CLR, or an ExecutionEngineException with no details. We can’t seem to get around these. Also, any exceptions thrown by bad XAML at runtime have zero details about what is wrong. Sometimes we get exceptions that have nothing to do with XAML or our UserControl but the exception is still thrown by a UserControl. Very Strange.
My coworker Dan has a post with more gotcha’s and his take on Win8. Overall, Win8 is cool, but the preview is severely lacking. We’re hoping it doesn’t take another 6+ months to get new bits!