I updated Mvvm Light to version 5 and noticed that
See this MVVM Light 5 issue:
WPF is the only XAML framework that uses the CommandManager to automagically raise the CanExecuteChanged event on ICommands. I never liked that approach, because of the "magic" part, but this is a "feature" of WPF and of course I have to support it. No question here.
In V5, I moved to portable class library for all the newest versions of the XAML frameworks, including WPF4.5. Unfortunately, there is no CommandManager in PCL, and I have to admit that I didn't realize that at first sight. So of course now the automagical part doesn't work anymore. Again, so sorry about that.
I am not expecting you to raise CanExecuteChanged everywhere now, not after using the CommandManager in your application, which is what the WPF team intended. So I will try to find a way to restore the CommandManager usage in the WPF4.5 version of the toolkit.
Definitely not looking for excuses ;) but hope that explaining why the issue arose helps to make sense of this. It's going to be my priority No. 1 until I find a way to solve this in the PCL version. In the meantime, like I mentioned before, I think that going back to V22.214.171.124 should fix that. Please let me know if it does not.
So the temporary recommended solution is to revert back to the previous version. I did it and it worked.
I agree that the CommandManager is doing "magic". Once I had null reference exception within the
CanExecute condition and as a result I have obtained neverending cycle of error messages like cards in Windows Solitaire. If I started a new project I would prefer not to use this "magic" but to change an existing and already deployed project would be quite painful.