Подтвердить что ты не робот

Метод не найден во время выполнения

У меня есть проект ASP.Net С#, пытающийся получить доступ к методам в классе в другом проекте. Он работает для первой половины методов в классе, но не для другой половины методов в классе, которые я недавно добавил. Они компилируются, но они бросают исключение метода, которое не было обнаружено во время выполнения.

Есть ли у кого-нибудь идеи, которые я мог бы попробовать? Я пробовал:

  • воссоздание файла .sln
  • Subbing в другом проекте библиотеки классов, который, как я знаю, работает. Похоже, что ошибка в моем основном проекте, который вызывает метод в другом проекте.
4b9b3361

ОТВЕТЫ

Ответ 1

"Метод не найден" - это очень специфическая ошибка, что означает, что ожидаемый метод (т.е. был там во время компиляции) просто отсутствует. Обычно это означает, что файлы, которые вы развертываете, отличаются от того, что вы думаете о них - в частности, я бы сказал, что вы развертываете старую версию библиотеки (в которой отсутствуют ваши добавления).

Проверьте DLL, развернутые на веб-сервере, на то, что, по вашему мнению, должно быть.

Ответ 2

Я была такая же проблема. В моем случае это было вызвано добавлением необязательного аргумента. Итак, сначала вы должны иметь:

referencingAssembly:

referencedAssembly.DoStuff(firstArgument, secondArgument)

referencedAssembly:

public void DoStuff(string firstArgument, string secondArgument)
{
   //stuff to do
}

Затем вы добавляете необязательный параметр к методу, но не предоставляете этот аргумент при его вызове.

referencingAssembly:

referencedAssembly.DoStuff(firstArgument, secondArgument)//unchanged

referencedAssembly:

public void DoStuff(string firstArgument, string secondArgument, string thirdArgument = "default value")
{
   //stuff to do
}

Локально, это будет собираться и работать нормально, так как новая сборка referencingAssembly.dll будет иметь ссылку на метод DoStuff (string, string, string). Но когда вы развертываете только измененную referencedAssembly (думая, что добавленный аргумент был необязательным, а referncingAssembly все еще работает), старая версия referencingAssembly выбрасывает MethodNotFound, так как он ищет метод с подписью DoStuff (string, string), которая является больше не присутствует в referencedAssembly, так как мы добавили дополнительный (необязательный) аргумент.

Возможным решением может быть перегрузка:

referencedAssembly:

public void DoStuff(string firstArgument, string secondArgument)//original method
{
   DoStuff(firstArgument, secondArgument, "default value")
}
public void DoStuff(string firstArgument, string secondArgument, string thirdArgument)//new overload of the method
{
//stuff to do
}

Или развертывание новой сборки referencingAssembly (которая будет ссылаться на метод с подписью DoStuff (строка, строка, строка)).

Ответ 3

была та же проблема, в моем случае установка optimizeCompilations на false в webconfig решила проблему

Ответ 4

Я столкнулся с такой проблемой, но смог ее решить. Я опустошил папку с bin и debug и снова попытался создать проект. это сработало, по крайней мере, для меня. Или попробуйте очистить решение и попытаться восстановить его. Но, конечно, публикация части вашего кода может быть более полезной.

Ответ 5

У меня была очень похожая проблема, и я обнаружил, что более старая версия сборки была установлена ​​в GAC. После того, как я удалил эту версию, проект скомпилирован и работает правильно. Поэтому проверьте GAC (C:\Windows\Assembly), чтобы убедиться, что он не указан там.

Ответ 6

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

public void WriteMessage(string msg) 
{
    ...
}

и появился новый запрос на модификацию, и он превратился в это:

public void WriteMessage(string msg, int code = 100)
{
    ...
}

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

После многих попыток ничего не сработало, даже очистить проект, перестроить, удалить и повторно добавить ссылку, затем я попытался изменить вызов метода проекта из:

...
library.WriteMessage('hello!');
...

в

...
library.WriteMessage('hello!', 100);
...

а затем скомпилировал проект, он решил проблему, после чего я изменил ее на:

...
library.WriteMessage('hello!');
...

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

Надеюсь, это поможет кому-то, кто столкнулся с той же проблемой, с которой я столкнулся.

Ответ 7

Два проекта в вашем решении: проект A и проект B. Оба проекта используют пакет nuget "DoStuff", но разные версии пакета DoStuff:

  • project A ссылается на версию 1.1 DoStuff.
  • проект B ссылается на версию 1.0 DoStuff.
  • проект B ссылается на проект A.

версия 1.1 имеет новый метод, который используется в проекте A., когда проект B использует проект A, вы получите это исключение MethodNotFoundException, поскольку версия DoStuff проекта B не знает, о чем говорит проект A.

Чтобы предотвратить это, мы имеем unit test, который терпит неудачу, если проекты используют разные версии одного и того же пакета nuget. Относительно простой дверной замок, который спас нас пару головных болей в последние годы.

Ответ 8

Посмотрите, это должно быть самая странная причина когда-либо, но после целого утра, пробовав все, перестроив проект с нуля и т.д., я заметил, что единственное единственное, что могло бы избежать проблемы, состояло в том, что в моей библиотеке было другое имя сборки,

У меня было ужасное предложение из глубины моего разума о том, что я установил предыдущие версии dll в GAC, но я уже проверил это, и, кроме того, это никогда не было моим намерением. Но после этой тропы я узнал эту DLL (и все остальные из проекта!), Где установлен C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE!!!!!!

Аааарх! Думаю, я единственный, кто каким-то образом испортил это, но я понятия не имею, почему, я просто подумал, что могу избавить кого-то еще от этой развязки в отдаленной возможности, что кому-то так повезло!!

Ответ 9

Я столкнулся с той же проблемой, когда я запускал приложение с dll-пакетами, управляемыми пакетом nuget. Оказывается, когда я пытаюсь обновить dll из диспетчера пакетов nuget, он не обновил тестовый уровень. Я предлагаю вам проверить версию DLL, на которую вы ссылаетесь. Перейдите в ObjectBrower в VS и проверьте DLL и проверьте местоположение ссылки: убедитесь, что вы ссылаетесь на последние DLL.

Ответ 10

Ошибка также возникла, когда у меня был параметр Action as. Я передал метод, не завернув его в новое действие (..).

В DLL было:

public bool ShowMyForm(bool showConnectionWindow, Action onCloseNotify) {...}

Тестовое приложение называется DLL следующим образом:

private void onFormClose()
{
    MessageBox.Show("Form Closed");
}

private void ShowForm()
{
     mydll.ShowMyForm(true, onFormClose ); // bug here: wrap in Action
}

Когда я изменил вызов на

mydll.ShowMyForm(true, new Action(onFormClose) );

исключение исчезло. Текст исключений просто вводит в заблуждение - метод существует, но тип параметра дал исключение во время выполнения. Слишком плохо, что он не был выбран во время компиляции.

Ответ 11

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

Ответ 12

Мое дело было небольшим изменением других; но это может помочь кому-то. Я просто добавил необязательный аргумент в библиотеку и получил это сообщение из графического интерфейса, используя библиотеку.

Проблема была вызвана графическим интерфейсом и одной из его библиотек, ссылающихся на одну и ту же библиотеку, но одна из них не была обновлена.

У меня

  • GUI, ссылающийся на LibA и LibZ
  • Лива, ссылающаяся на LibZ

Итак, я просто удалил все папки "bin" и "obj" обоих LibA и GUI, убедившись, что обновленная DLL LibZ в обоих, и все снова работало.

Ответ 13

В моем случае я развернулся на ПК .NET 3.0 (Windows XP), а целью компиляции был .NET 3.5. Я действительно удивляюсь, почему нет более основного предупреждения...

Проблема заключается в использовании DataContract из System.Runtime.Serialisation.

Ответ 14

У меня возникла одна и та же проблема, даже я очистил и перестроил решение, которое не помогло. когда я опубликовал приложение, старая версия dll была в папке bin. Поэтому я изменил версию сборки в файле assemblyinfo. наконец, его работа. Новая версия доступна в папке bin.

Ответ 15

У меня возникла эта проблема, когда я скопировал решение в другое место на другой машине. Папка Build просто нужно было изменить. Не спрашивайте меня, почему, но решение было построено в папке сборки (мы будем называть эту папку A), тогда старая копия была скопирована из папки B в папку C. Во время выполнения он не смог найти мой последний код, потому что он был глядя на более старую версию в папке C. В свойствах для решения на вкладке "Сборка" я изменил путь вывода в папку B. Затем он построил последнюю версию в папке B, которую он скопировал в папку C, и все это снова работало.

Я не знаю, почему у нас есть папка C, в первую очередь. У меня есть решение codedUI Testing, а папка C - "C:\Users\\Documents\MyCodedUISolution\TestResults\_ 2017-04-20 11_31_29\Out". Что это используется и почему оно создано, я не знаю, но если старый код скопирован здесь, потому что вы меняете выходной путь или перемещаете решение, не меняя путь вывода на то, что вам нужно, тогда у вас проблемы.

Ответ 16

В моем случае я изменил возвращаемый тип метода из IQueryable в IEnumerable.

Я перекомпилировал и загрузил DLL, содержащую этот метод, но не DLL с кодом, который вызывает этот метод. Таким образом, вызывающая DLL все еще ожидала метод с предыдущим типом возврата и не могла его найти.

Ответ 17

Я не смог исправить это ни с одним из предложенных ответов. Я не смог найти какие-либо старые версии кастомной сборки. Я буквально искал везде с инструментом Все. В режиме отладки он показал правильную версию сборки, но так и не смог найти метод.

Включение автоматической .csproj файле .csproj исправило это для меня

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>

Я нацелился на пакет .NET Framework 4.5 в моем проекте. Указанный выше параметр не требуется, если все пакеты в проекте предназначены для .NET Framework 4.5.1 или более поздней версии.

Ответ 18

Это может быть запоздалый ответ: но одно из возможных решений - очистить папку временных файлов ASP.NET: т.е. C:\Windows\Microsoft.NET\Framework\vX.X.XXXXX\Temporary ASP.NET Files

Удаление папок, связанных с вашим сайтом, и перестройте решение.

Ответ 19

Если вы ссылались на другой проект как .exe, вам нужно перестроить его как .dll, для этого вам нужно установить в проекте проект для class library в настройках проекта, затем собрать его и ссылаться на dll в проекте, где метод был отсутствует.

Ответ 20

В дополнение к ответу Нирмана - не забудьте очистить временные файлы в папке C:\Users\UserName\AppData\Local\Temp\Temporary ASP.NET Files.

Я изменил тип поля класса с enum на string и после этого получил ошибку

System.MissingMethodException: метод не найден: 'DatnesVeidi DatnesModel.get_DatnesVeids() '

при рендеринге Razor view. Ни одно из предыдущих предложений не помогло, только очистка локальных временных файлов пользователя.