QuickWatch не работает правильно для показа ".ToString()" свойств Nullable

У меня есть свойство nullable integer в vb.net.
Это свойство в коде имеет правильное значение, но в QuickWatch всегда отображается 1, если я не инициализирую его значением, а затем отобразите шесть цифр на цифровом диске.

Мои коды:

Public Property MyNumber As Integer?

MyNumber = 6546

MessageBox.Show(MyNumber.ToString())

И для свойства nullable double в QuickWatch всегда отображается 4/94065645841247E-324.

Я тестирую это на .Net 4 & 4.5 на visual studio 2010 & 2013 и получаю тот же результат. Однако С# не имеет этой проблемы

EDIT:

Я также добавляю свой результат проекта, как вы видите в окнах часов, оба из них показаны

Почему это происходит?

EDIT:

Эта проблема связана с .Net 4 и 4.5 и 4.5.1. С .Net 2.0 и 3.5 нет проблем.

Ответ 1

Подтверждено, это действительно ошибка в отладчике. Я искал файл connect.microsoft.com и не нашел ничего похожего, это не ошибка, которая поражает многих программистов VB.NET. Не совсем удивительно, это происходит не так, если вы добавляете .ToString() в имя переменной с нулевым именем. Никто никогда не делает этого.

Это не ошибка, с которой вы можете получить помощь на этом сайте, это ошибка, которую Microsoft должна исправить.

Характеризуя ошибку немного, это, похоже, ошибочно относится к определенному парсеру выражений VB.NET, встроенному в отладчик. Причина, по которой вы не можете воспроизвести это в проекте С#. И почему битность процесса не имеет значения, 64-разрядный отладчик также показывает плохие значения. Это, как правило, непостоянный код, который Microsoft работает для выхода на пенсию. Основная проблема заключается в том, что они должны были создать эквивалент компилятора VB.NET в отладчике, чтобы эти выражения могли быть проанализированы. Ограниченный, хотя этот парсер почти не поддерживает весь язык. Побочным эффектом является то, что код, выполняемый отладчиком, может отличаться от кода вашей программы.

Генерация кода для Nullable (Of T).ToString() довольно сложная, для этого требуется условное преобразование бокса. Анализатор передает его для любого такого выражения, обратите внимание, как MyNumber.GetHashCode() также производит неправильное значение. И MyNumber.Equals(5456.0). Тип выражений, которые требуют преобразования бокса.

Вы также можете сообщить об этой ошибке на сайте connect.microsoft.com, но я бы не рекомендовал тратить время. Как уже отмечалось, Microsoft работает над удалением этого синтаксического анализатора, и это, наконец, произошло. Работает на Roslyn, компиляционном сервисе, который можно использовать где угодно. Он был интегрирован в VS2015, и, насколько известно, его использует и отладчик. Не уверен на 100%, я узнаю через 9 дней, когда выйдет VS2015. Может быть, кто-то, у кого есть установленная версия бета /RC, может подтвердить с комментарием.

UPDATE: подтверждено исправлено на VS2015.

Между тем, пока вы не сможете обновить, обходным путем является просто прекратить использование ToString() для переменных с нулевым значением в ваших быстрых/часовых выражениях. Это глючит.