Method not found system ошибка

13

3

2

0

2

also.. try to «clean» your projects or solution and rebuild again!

0

[assembly: AssemblyVersion("0.2.6")]
[assembly: AssemblyFileVersion("0.2.6")]
[assembly: AssemblyInformationalVersion("0.2.6")]

2

Have you tried turning if off and on again? Jokes aside, restarting my computer was what actually did the trick for me and isn’t mentioned in any of the other answers.

using AutoMapper;

namespace Your.Namespace
{
    public class MappingProfile : Profile
    {
        MappingProfile()
        {
            CreateMap<Animal, AnimalDto>();
        }
    }
}

2

1

I came across the same situation in my ASP.NET website. I deleted the published files, restarted VS, cleaned and rebuild the project again. After the next publish, the error was gone…

I solved this problem by making a shelveset with my changes and running TFS Power Tools ‘scorch’ in my workspace (https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f). Then I unshelved the changes and recompiled the project.
This way you will cleanup any ‘hanging-parties’ that may be around in your workspace and will startup with a fresh one.
This requires, of course, that you are using TFS.

In my case, my project was referencing Microsoft.Net.Compilers.2.10.0. When I switched it to Microsoft.Net.Compilers.2.7.0, the error went away. What a mysterious error with such a variety of causes.

In my case it was a folder with olders DLLs of the same name that those wich were referenced in my .csproj file although the path was explicitly given they were somehow included therefore the several versions of the same DLLs were in conflict.

I’ve had the same thing happen when I had a number of MSBuild processes running in the background which had effectively crashed (they had references to old versions of code). I closed VS and killed all the MSBuild processes in process explorer and then recompiled.

I had a test project that references 2 other projects that each referenced different versions (in different locations) of the same dll. This confused the compiler.

Answers

• Read the «Overload Resolution» of
  this for the resolving order when other overloading function and function with optional parameter coexist.

  • Marked as answer by
    Philip Atz
    Saturday, November 28, 2015 10:57 AM

• The choice of function to use is determined at compile time. Since CSC defaults to include MSCORLIB itself, maybe that’s why it sees the function in the 4.6 version and think it should choose that run.

  Maybe you should try the approach
  here, to instruct it not to link the standard libraries automatically, and then explicitly add reference to the version of mscorlib you’ll be targeting at.

  See if this can resolve your problem.

  • Marked as answer by
    Philip Atz
    Saturday, November 28, 2015 10:56 AM

• Yes, you are right in that the resolution into «object
  arg0,
  object arg1»
  is occurring for the same reason that causes the 4.6 version of `mscorlib.dll` to be included in the build’s bin folder. The link you sent about getting rid of an MSCORLIB warning did not help me, but I now know what the problem was. Apparently, Microsoft
  Build Tools 2015 builds with .NET 4.6 in mind, even if your project targets 4.5.2, unless you have the 4.5.2 Targeting Pack installed (which I didn’t). After installing the Targeting Pack, I can see that the bin folder produced by the Build Tools no longer
  includes `mscorlib.dll`.

  I am undecided on whether this constitutes a bug for Build Tools 2015. I believe the Build Tools should produce an error, or at least a warning, saying that «You are trying to build an assembly that targets .NET 4.5.2 without having the 4.5.2 Targeting
  Pack installed». This would make more sense than the Build Tools silently trying to compile the assembly with the .NET 4.6 resolution information they have available, bundling in the 4.6 `mscorlib.dll` in the process.

  Another thing that is highlighted by this are, I guess, the effects of Microsoft’s decision to add this new overload to .NET 4.6:

  public static string Format(IFormatProvider provider, string format, object arg0, object arg1)

  I believe it was a breaking change, only in subtle ways, and a bad one because of that.

  • Marked as answer by
    Philip Atz
    Saturday, November 28, 2015 10:57 AM

• Thank you cheong00, that is an interesting read. I have tried the following code in LINQPad, which does indeed prove that «params object[] args»
  is assigned lower resolution priority:

  void Main()
  {
  	Test(CultureInfo.InvariantCulture, "{0}='{1}'", "key", "value");
  	Test(CultureInfo.InvariantCulture, "{0}='{1}'", args: new[] { "key", "value" });
  }
  
  private static void Test(IFormatProvider provider, string format, object arg0, object arg1)
  {
  	"object arg0, object arg1".Dump();
  }
  
  private static void Test(IFormatProvider provider, string format, params object[] args)
  {
  	"params object[] args".Dump();
  }

  The question still remains however: Why is «object
  arg0,
  object arg1»
  even considered as an option for resolution of string.Format() when I am targeting .NET 4.5.2?

  • Edited by
    Philip Atz
    Friday, November 27, 2015 11:37 AM
  • Marked as answer by
    Philip Atz
    Saturday, November 28, 2015 10:57 AM

Polity
09 нояб. 2011, в 03:59

Поделиться

Ben Gripka
07 июль 2013, в 00:43

Поделиться

Jelani
12 фев. 2015, в 03:38

Поделиться

Неправильная версия пакета Nuget

У меня был проект модульного тестирования, который включал пакет доступа к данным EF Nuget наших компаний, и эта версия сильно отставала от текущей версии.

Для параметров Nuget для упомянутого пакета была установлена least version для тех других пакетов, которые были зависимыми от второго уровня.

Следовательно, он молча получил неправильную версию для соответствующей сборки.

Решение

Установив/обновив пакет в Nuget, чтобы [получить] последний исправил проблему.

ΩmegaMan
31 март 2016, в 22:56

Поделиться

Я просто столкнулся с этим в проекте .NET MVC. Коренной причиной были конфликтующие версии пакетов NuGet. У меня было решение с несколькими проектами. В каждом из проектов были некоторые пакеты NuGet. В одном проекте у меня была версия пакета Semantic Logging Enterprise Library, а в двух других проектах (эта ссылка была первой) у меня были более старые версии одного и того же пакета. Все они компилируются без ошибок, но при попытке использовать пакет он дал загадочную ошибку «Метод не найден».

Исправлено удаление старых пакетов NuGet из двух проектов, так что он был включен только в один проект, который действительно нуждался в нем. (Также я сделал чистую перестройку всего решения.)

Mark Meuer
01 май 2014, в 23:46

Поделиться

Josh Noe
17 авг. 2012, в 20:33

Поделиться

Если вы разрабатываете свой собственный сервер NuGet, убедитесь, что все версии сборки одинаковы:

[assembly: AssemblyVersion("0.2.6")]
[assembly: AssemblyFileVersion("0.2.6")]
[assembly: AssemblyInformationalVersion("0.2.6")]

sennett
26 авг. 2013, в 00:16

Поделиться

Проверьте свои ссылки!

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

Например, если вы используете iTextSharp v.1.00.101 в одном проекте, а вы NuGet или ссылаетесь на iTextSharp v1.00.102, то в другом месте вы получите эти типы ошибок времени выполнения, которые каким-то образом стекаются в ваш код.

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

Juls
24 янв. 2017, в 09:24

Поделиться

user384080
12 нояб. 2013, в 23:09

Поделиться

У меня была эта проблема, и оказалось, что это связано с тем, что я ссылался на предыдущую версию DLL из моего проекта пользовательского интерфейса. Поэтому при компиляции он был счастлив. Но при запуске он использовал предыдущую версию DLL.

Проверяйте ссылки на все другие проекты, прежде чем предполагать, что вам нужно перестроить/очистить/перераспределить ваши решения.

Jamie Lupton
06 апр. 2016, в 14:25

Поделиться

Использование Costura.Fody 1.6 и 2.0:
Потратив кучу времени на поиски такой же ошибки, когда все остальные потенциальные решения не работали, я обнаружил, что старая версия DLL, которую я встраивал, была в той же директории, из которой я запускал только что скомпилированный .exe. Очевидно, он сначала ищет локальный файл в том же каталоге, а затем смотрит внутрь своей встроенной библиотеки. Удаление старой DLL сработало.

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

grep 65535
20 апр. 2018, в 17:27

Поделиться

В моем случае это была проблема с копией/вставкой. Я как-то закончил конструктор PRIVATE для моего профиля отображения:

using AutoMapper;

namespace Your.Namespace
{
    public class MappingProfile : Profile
    {
        MappingProfile()
        {
            CreateMap<Animal, AnimalDto>();
        }
    }
}

(обратите внимание на отсутствующую «общественность» перед ctor)

который скомпилирован отлично, но когда AutoMapper пытается создать экземпляр профиля, он не может (конечно!) найти конструктор!

DaBeSoft
04 окт. 2017, в 15:04

Поделиться

Также возможно, что проблема связана с параметром или возвращаемым типом метода, который сообщил об отсутствии, и «отсутствующий» метод сам по себе является прекрасным.

То, что происходило в моем случае, и вводящее в заблуждение сообщение заставило его заняться гораздо дольше, чтобы выяснить проблему. Оказывается, сборка для типа параметра имела более старую версию в GAC, но более старая версия имела более высокий номер версии из-за изменения используемых схем нумерации версий. Удаление этой старой/более высокой версии из GAC устранило проблему.

Jimmy
05 сен. 2017, в 21:58

Поделиться

fbastian
17 сен. 2015, в 09:45

Поделиться

Irshu
08 июль 2015, в 10:42

Поделиться

Lee Bailey
22 янв. 2014, в 10:49

Поделиться

У меня был похожий сценарий, когда я получал такое же исключение. У меня было два проекта в моем решении для веб-приложений, названное, например, для DAL и DAL.CustSpec. Проект DAL имел метод Method1, но DAL.CustSpec этого не делал. В моем основном проекте была ссылка на проект DAL, а также ссылка на другой проект под названием AnotherProj. Мой главный проект сделал вызов Method1. Проект AnotherProj имел ссылку на проект DAL.CustSpec, а не на проект DAL. В конфигурации Build были сконфигурированы как проекты DAL, так и DAL.CustSpec. После того, как все было построено, в моем проекте веб-приложения были сборки AnotherProj и DAL в папке Bin. Однако, когда я запускал веб-сайт, временная папка ASP.NET для веб-сайта по какой-то причине имела сборку DAL.CustSpec в своих файлах, а не в сборке DAL. Конечно, когда я запускал часть, которая называлась Method1, я получил ошибку «Метод не найден».

Что мне нужно было сделать, чтобы исправить эту ошибку, было изменение ссылки в проекте AnotherProj из DAL.CustSpec только на DAL, удаление всех файлов в папке Временные файлы ASP.NET и повторный веб-сайт. После этого все приступило к работе. Я также убедился, что проект DAL.CustSpec не был создан, сняв флажок в конфигурации сборки.

Я думал, что поделюсь этим, если это поможет кому-то еще в будущем.

Ron Kanagy
30 март 2013, в 20:30

Поделиться

Должно быть ссылочной ошибкой от Microsoft.

Я почистил, пересобрал все мои библиотеки и все еще получил ту же проблему и не мог решить эту проблему.

Я только закрыл приложение Visual Studio и снова открыл его. Это добилось цели.

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

JayJay Barnard
29 янв. 2019, в 20:07

Поделиться

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

System.MissingMethodException: Method not found: '?'.

стек:

Server stack trace: 
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request)
   at myAccountSearch.AccountSearchClient.myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request)
   at myAccountSearch.AccountSearchClient.searchtPhone(String ID, String HashID, searchtPhone Phone1)
   at WS.MyValidation(String AccountNumber, String PhoneNumber)

Я считаю, что проблема была повреждена AppPool — мы автоматизировали утилизацию AppPool каждый день в 3 часа ночи, и проблема началась в 3 часа ночи, а затем закончилась сама по себе в 3 часа ночи на следующий день.

George
29 май 2018, в 22:40

Поделиться

R2D2
21 май 2018, в 10:17

Поделиться

В моем случае spotify.exe использовал тот же порт, который мой веб-проект api хотел использовать на машине разработки. Номер порта был 4381.

Я ухожу из Spotify, и все снова работает хорошо:)

Arda Basoglu
17 март 2017, в 18:13

Поделиться

nuander
01 март 2017, в 23:47

Поделиться

bytedev
26 нояб. 2015, в 16:51

Поделиться

Я столкнулся с этой проблемой, и то, что для меня было одним проектом, было использование списка, который был в примере. Пространство имен сенсоров, а другой тип — интерфейс ISensorInfo. Класс Type1SensorInfo, но этот класс был одним слоем глубже в пространстве имен в примере. Sensors.Type1. При попытке десериализовать Type1SensorInfo в список, это исключило исключение. Когда я добавил использование примера .Sensors.Type1 в интерфейс ISensorInfo, больше никаких исключений!

namespace Example
{
    public class ConfigFile
    {
        public ConfigFile()
        {
            Sensors = new List<ISensorInfo<Int32>>();
        }
        public List<ISensorInfo<Int32>> Sensors { get; set; }
     }
   }
}

**using Example.Sensors.Type1; // Added this to not throw the exception**
using System;

namespace Example.Sensors
{
    public interface ISensorInfo<T>
    {
        String SensorName { get; }
    }
}

using Example.Sensors;

namespace Example.Sensors.Type1
{
    public class Type1SensorInfo<T> : ISensorInfo<T>
    {
        public Type1SensorInfo() 
    }
}

Steven Koxlien
21 авг. 2015, в 20:31

Поделиться

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

У меня была эта ошибка при использовании Jenkins.

В конце концов выяснилось, что системная дата была вручную установлена ​​на будущую дату, что вызвало слияние dll с этой будущей датой. Когда дата была возвращена в нормальное состояние, MSBuild интерпретировал, что файл был более новым и не требовал перекомпиляции проекта.

Renato Chencinski
16 март 2015, в 20:40

Поделиться

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

Я сделал чистую и восстановил и отметил, что он пропускает два проекта. Когда я перестроил один из них, произошла ошибка, когда я запустил функцию и не закончил ее.

Итак, VS ссылался на модель, которую я переписал, не спрашивая меня, хочу ли я это сделать.

TheWizardOfTN
20 янв. 2015, в 18:53

Поделиться