.NET 4.5 WPF Selector Bug With Objects who’s HashCode are not fixed.

I have an opened ticket at Microsoft Connect:
Items with Changing HashCodes Break WPF ListView (Selector) functionality in .NET 4.5, working in .NET 4.0

But their formatting is TERRIBLE, and I also want to maximize visibility for other people with the same problem:

Here’s the Transcript of the problem:

Description

It seems we’ve had a regression in the .NET 4.5 runtime that’s causing previously working code (runs fine under .NET 4.0 runtime) to behave differently when run under the .NET 4.5 runtime.

If you have a class with a changing GetHashCode() the selection logic inside the ListView/Selector control, the selection logic totally breaks.

For example:

public class Item
{
   public string Name { get; set; }
   public override int GetHashCode() { return Name == null ? 0 : Name.GetHashCode(); }
}

When you use this inside an ICollectionView databound to a list box, the listbox ceases to select correctly once the GetHashCode() changes under .NET 4.5

On .NET 4.0 the behavior is uninhibited, and selection works correctly as expected.

Working Example Code/Project:
Download NET45SelectorBugWithChangingHash.zip

Steps to Reproduce

  1. Create a WPF Application targeting .NET 4.0 on a machine using Visual Studio 2012 & with the .NET 4.5 runtime installed.
  2. Create Class with a GetHashCode() that’s deterministicaly changeable. (See Above)
  3. Create a ICollectionView / CollectionViewSource that watches an ObservableCollection of instances of the class from Step 2.
  4. Bind a ListView / ListBox to the ICollectionView made in Step 3 with IsSynchronizedWithCurrentItem=”True”
  5. Run Application and Select an item from the list.
  6. Deterministically change the selected item’s GetHashCode() (Change whatever property it’s proxying for).
  7. Select other items in the list, note how the CurrentSelected isn’t updated for the ICollectionView and the selection visuals for the List Box are broken

Extra:

  1. Return the original item’s GetHashCode back to it’s original value
  2. Observe that the selection behavior returns to normal

Actual Results

Selection breaks, ICollectionView is no longer having it’s Current adjusted, and the visuals for selection in the list box behave incorrectly.

Expected Results

No different operation from a normal ListView/Box, selecting a new item would update the selection visuals to show the new selection and the underlying ICollectionView would receive the call to update it’s Current to match the selection in the list box.