Debugging your VisualState triggers

Windows 10 includes some the RelativePanel and new VisualState improvements to make it simpler to design “adaptive” displays.  But like all declarative languages, debugging is just simply painful.

To make the VisualState features work, you have to

• create a VisualStateManager in your grid (or similar); 
• the VisualStateManager in turn as a VisualStateGroup; 
• the VisualStateGroup has a set of VisualState items (you will always have two or more).  
• The VisualState in turn has a VisualState.StateTrigger (often an AdaptiveTrigger with a MinWindowsWidth) 
• and finally VisualState.Setters to actually change your display.

Problem #1: if you mistype the name of your control, it’s just silently ignored.  It doesn’t even spit out a warning into the Output window.  If you are an inconsistent caser (like me), you’ll find this a rich productive bug farm.
Problem #2: the rules for the RelativePanel aren’t tricky, but you have to get used to them.  It’s tough to try to learn both the rules for RelativePanel while also learning how to make the AdoptiveTrigger work.
Problem #3: for a short while my C# project was set to “any CPU”.  It would “compile” and run with no warnings, and then run the last actual build.  All my “changes” would be completely ignored!
To fix your problems:

1. Never set your project to “Any CPU”.  Yes, it used to be the awesome value, but now it’s the horrific value.  I don’t even know why they still include it as an option
2. Never type your control names in the XAML designer.  Always do a cut-n-paste so that the name is guaranteed correct