Weird .NET Issues

This page briefly describes some weird issues you may encounter in the .NET Framework, with links to more detailed discussions. My criterion for selecting these issues was my own bafflement when I first encountered them.

• AnyCPU Versus Any CPU, or projects versus solutions.
• Application Settings Folders and their weird naming scheme.
• WPF Focus Disables Commands and drives developers crazy.

Additionally, there are some weird .NET performance issues that I discuss elsewhere. User-defined value types can be surprisingly slow due to inadequate CLR JIT optimizers; and WPF drawing performance relies on disabling anti-aliasing and freezing all eligible objects.

AnyCPU Versus Any CPU

If you look at a Visual Studio solution file, you’ll find that the .NET platform identifier for “pick x86 or x64 at runtime” is spelled Any CPU – note the space! But if you look at a Visual Studio project file, the equivalent platform identifier is spelled AnyCPU – without a space.

This is not because MSBuild ignores embedded spaces, as you will discover when you try to target AnyCPU on a solution file or Any CPU on a project file. Rather, it’s a silly legacy issue that MSBuild silently works around by substituting one spelling for the other when propagating solution settings to projects.

A Microsoft Connect item has been opened for this issue – and closed as “Won’t Fix” in late 2009. Guess we’ll never see a fix for that one, so you simply have to be aware that projects require a different platform identifier than solutions.

Application Settings Folders

The System.Configuration namespace provides a convenient mechanism called Application Settings to semi-automatically manage and upgrade your application’s user settings. The MSDN Library page Application Settings Architecture gives an overview of this mechanism.

Unfortunately, it also contains an error. Section “Settings File Location” claims that the configuration file for the current user is stored in the folder Application.LocalUserAppDataPath, just as you’d intuitively expect. But if you look there, you’ll find one or more folders with very strange names instead.

As it turns out, Application Settings creates a new folder for every new version of your application, and the folder name encodes the current version. The marked reply in this MSDN Forum thread explains the exact composition of the folder name.

If you wish your next application version to continue using the previous version’s settings, you must explicitly call an Update method to retrieve the settings from the older version’s folder, as described in this Stack Overflow thread.

On the other hand, if you wish Application Settings wouldn’t litter your file system with a hundred strangely named folders in the first place, you’re out of luck. The default LocalFileSettingsProvider that defines these folder names does not expose any way to change them. You would have to implement an entire new custom settings provider, as explained in the Application Settings Architecture article, but for my part I’d rather use XDocument to manage my settings manually.

WPF Focus Disables Commands

This section covers two issues, both stemming from the bizarre way WPF handles input focus. The matter is discussed at length in the aptly titled MSDN Forums thread A FocusScope Nightmare.

WPF windows distinguish multiple “focus scopes” which are predefined for menus and toolbars, and can be defined for any control via FocusManager.IsFocusScope. What the MSDN Library leads you to believe is that focus scopes can be created at will, to remember each focused element in various subsections of a window.

But in reality, it’s a very limited hack that’s just about good enough to make menus and toolbars work – while accidentally breaking routed commands. First, setting IsFocusScope on your own controls will result in very strange behavior. See Daniel Grunwald’s Code Project article on what can happen, and how to create your own focus scope mechanism that works properly.

Accidentally disabled commands are the other casualty of this design. Since the goal was to dispatch menu and toolbar commands to input controls in the main window, i.e. the parent focus scope, WPF simply disables any routed commands for menu and toolbar items whose targets cannot receive keyboard input – without even evaluating their CanExecute handlers! If an item’s CommandTarget is a null reference (the default), WPF substitutes the currently focused element in the parent scope for this target check. This means that WPF will merrily disable your entire main menu if a non-interactive image is focused…

Fortunately, the workaround is just a few lines of code. During creation of your main window, loop through all menu and toolbar items and set their CommandTarget to the main window itself. A window can always receive keyboard input, and a valid CommandTarget prevents WPF from checking the focused element in the parent scope. Your routed commands will now properly evaluate their CanExecute handlers to decide if they should be enabled, regardless of whether some focused element can receive input.

This page was last updated on 05 July 2011. Current version available at http://www.kynosarges.org/