Легкие сообщения MVVM прерваны после обновления SL5 - PullRequest
5 голосов
/ 12 декабря 2011

Я только что обновил свое приложение SL4 до SL5.Я скачал источник легкого инструментария MVVM для SL 5 и собрал его: http://mvvmlight.codeplex.com/SourceControl/changeset/changes/17256019ad97

Изначально все работало нормально, но обмен сообщениями GalaSoft почему-то не работает.Сообщение отправляется, но никогда не принимается получателем (используя Messenger.Default.Register).Нет предупреждений / ошибок сборки и ошибок в окне вывода.

Кто-нибудь знает о каких-либо серьезных изменениях в связи с новым обновлением MVVM Light SL5?

/ Thomas

1 Ответ

0 голосов
/ 10 января 2012

Со мной происходило то же самое при обновлении более старой версии MVVM Light (набор изменений 3bdbffb4e70a «BL0014 Misc»).Мгновенно перестал работать Send ().

Чтобы решить эту проблему, попробуйте использовать перегрузку .Register () с параметром receiveDerivedMessagesToo, установленным в true.

Эта проблема может возникать при отправке.() объекты, для которых создан какой-то тип DynamicProxy.Например, EntityFramework будет делать это, когда вы используете свойство Local в любой из коллекций контекста данных.

Например, EntityFramework DBContext для ctx.Dealers.Local создаст список элементов типа, которые выглядят следующим образом: System.Data.Entity.DynamicProxies.Dealer_D4CEAA0F527F5360DEB9B2B35305241B76A107C37B9DB8B368984B7DF69AEE1E

При сопоставлении с зарегистрированным прослушивателем, отправителем, отправившим заявку, не получил (-а), вы не получили (не отправили), так как вы не получили его, так как вы не получили уведомление о получении, так как вы не получили (не получили), поскольку вы не получили уведомление о получении, так как вы не получили (не получили), так как вы не получили (не получили), поскольку вы не получили (или не получили), поскольку вы не получили (-а) пересылку.

Почему это работало без необходимости, чтобы для метода receiveDerivedMessagesToo было установлено значение true, а сейчас нет?

Ранее MVVM Light "Messenger.cs" Messenger.SendToTargetOrType () имел этот код:

private void SendToTargetOrType<TMessage>(TMessage message, Type messageTargetType, object token) 
{ 
  var messageType = typeof(TMessage); 

Это прекрасно работало, так как фактический тип передаваемых данных не имел значения, только тип зарегистрированного типа.

Теперь код был изменен на:

private void SendToTargetOrType<TMessage>(TMessage message, Type messageTargetType, object token)
{
  Type messageType = message.GetType();

Теперь вместо него используется тип параметра.Это проблема, поскольку если ваше «сообщение» относится к прокси-серверу определенного типа, поиск зарегистрированных слушателей завершится неудачей.

...