Какой следующий шаг я должен предпринять, чтобы исправить MissingMethodException во время отладки? - PullRequest
Новая
       10

Какой следующий шаг я должен предпринять, чтобы исправить MissingMethodException во время отладки?

2 голосов
/ 20 мая 2009

Я вызываю некоторый код VB.NET в одной сборке из кода C # в другой сборке. Код строится нормально, но я получаю MissingMethodException, когда я звоню.

Обычно, согласно прочитанному Stack Overflow и результатам поиска Google для MethodMissingException, которые я прочитал, это происходит из-за несоответствия между библиотеками DLL, с которыми вы работаете, и библиотеками, с которыми вы работаете. Ни один из результатов не упоминает третью DLL. Подробнее об этом ниже.

Я подтвердил, что:

  • Путь целевой DLL совпадает с путем ссылки, в соответствии с окном вывода VS2008 при отладке
  • Это единственная версия целевой DLL, загруженная в систему, согласно ProcExp
  • «Отсутствующий» метод присутствует в соответствии с кодом
  • «Отсутствующий» метод присутствует в соответствии с сгенерированной XML-документацией
  • «Отсутствующий» метод присутствует в соответствии с рефлектором

Самое сильное преимущество - это дублирующая загрузка сборки, содержащей тип, используемый в сигнатуре «отсутствующего» метода. Это происходит как от SecondParty (на который я ссылаюсь), так и от FirstParty (с отключенным локальным копированием).

Ручное копирование всего в новый каталог устраняет проблему. Это затрудняет отладку: мне нравится просто нажимать на зеленый треугольник.

Деталь:

У меня третья сборка со строго типизированным набором данных ADO.NET. Давайте назовем тип ThirdParty.PortableData. Мой FirstParty заполняет его данными и передает его SecondParty.

вызывающий код в FirstParty, который не работает, выглядит примерно так: 

ThirdParty.PortableData data = GetPortableData()
SecondParty instance = new SecondParty()
instance.Data = data

(MissingMethodException выбрасывается из строки, которая вызывает метод с этим кодом в нем.)

Целевой код в SecondParty, который FirstParty не может найти во время выполнения, выглядит следующим образом: 

Public Property Data() As ThirdParty.PortableData
    Get
        ' ...
    End Get

    Set(ByVal value As ThirdParty.PortableData)
        ' ...
    End Set
End Property

Я тоже пробовал, с немного другим кодом вызова: 

Public Sub SetData(ByVal value as ThirdParty.PortableData) 
    ' ...
End Sub

DLL-библиотека ThirdParty загружается из более чем одного места, в соответствии с VS2008 и ProcExp - один раз из ссылочного пути и один раз из каталога сборки. MD5 дайджесты DLL совпадают.

Если я скопирую все в новый каталог, при условии, что есть только одна копия ThirdParty DLL, программа будет работать нормально.

У всех ссылок на ThirdParty функция «Копировать локально» отключена. И все же копия находится в FirstParty\bin\Debug.

Что еще я должен проверить? Как можно предотвратить MissingMethodException во время отладки, кроме сценариев после сборки, которые копируют продукты для сборки?

Ответы [ 3 ]

1 голос
/ 03 октября 2014

У меня была эта проблема со сборкой, зарегистрированной в GAC с использованием gacutil /i. При отладке Visual Studio не использовала локальную копию, а использовала копию из GAC (с тем же номером версии, но с другими объявлениями методов), что привело к исключению отсутствующего метода.

Решением для меня было перечислить все сборки из GAC, используя gacutil /l >myassemblies.txt, а затем удалить конкретную сборку из GAC, используя gacutil /u.

0 голосов
/ 22 мая 2009

Необходимым инструментом является Fusion Log Viewer . Он сообщит вам точные шаги, предпринятые CLR при попытке найти правильную сборку для загрузки.

0 голосов
/ 20 мая 2009

Скопируйте все файлы на новый чистый компьютер. Хеш все эти файлы, чтобы убедиться, что у вас есть уникальное значение для каждой DLL, не доверяйте номерам версий. Посмотрите, существует ли проблема. Я думаю, что ваша проблема будет решена на чистой машине.

Если это работает, вернитесь на свой компьютер и выполните глобальный поиск для каждой библиотеки DLL, запустите хэш и убедитесь, что это тот же самый EXACT-файл, который вы ожидаете.

У меня такое часто случается, когда люди жестко кодируют свои номера версий (1.0.0.0), а затем имеют 5 разных копий DLL на своем компьютере (локальный каталог, общие папки, GAC и т. Д.)

...