System.MissingMethodException：メソッドが見つかりませんか？

かつて私のasp.net webformsアプリで機能していたものが、次のエラーをスローします。

System.MissingMethodException：メソッドが見つかりません

DoThisこの方法は、同じクラスにあり、それが動作するはずです。

私にはそのような一般的なハンドラがあります：

public class MyHandler: IHttpHandler
{
    public void Processrequest(HttpContext context)
    {
      // throws error now System.MissingMethodException: Method not found?
      this.DoThis(); 
    }

    public void DoThis()
    {
    //
    }
}

これは、DLLの古いバージョンがまだどこかに残っている場合に発生する可能性のある問題です。最新のアセンブリが展開され、複製された古いアセンブリが特定のフォルダーに隠れていないことを確認してください。あなたの最善の策は、構築されたすべてのアイテムを削除し、ソリューション全体を再構築/再展開することです。

⚠️ 間違ったNugetパッケージバージョン ⚠️

私は、私たちの会社で内部EF Nugetデータアクセスパッケージと引っ張ったユニットテストプロジェクトだったそのコード に引っ張られ、そのバージョンだった外部のパッケージ方法現在のバージョンの後ろに。

問題は、パッケージのNuget設定がに設定されていることleast versionでした。以前のバージョンが勝ち、運用中に使用されました...

そのため、パッケージとアプリの両方で使用される一般的なアセンブリに対して誤ってバージョンが取得されていました。

💡 ソリューション 💡

Nugetでパッケージを設定/更新し、最新の[get]を使用して、問題を修正しました。

サーバーに正しい.NET Frameworkバージョンをインストールすることで、この問題を解決しました。Webサイトはバージョン4.0で実行されていて、呼び出し先のアセンブリは4.5用にコンパイルされていました。.NET Framework 4.5をインストールしてWebサイトを4.5にアップグレードすると、すべて正常に動作します。

Visual Studioを再起動すると、実際に修正されました。古いアセンブリファイルがまだ使用されていることが原因であると考えています。「クリーンビルド」を実行するか、VSを再起動すると修正されるはずです。

これは、別のDLLではなく、同じアセンブリで参照されているファイルで発生しました。ファイルをプロジェクトから除外し、再度含めたところ、すべてが正常に機能しました。

.NET MVCプロジェクトでこれに遭遇しました。根本的な原因は、NuGetパッケージのバージョンの競合でした。いくつかのプロジェクトで解決策がありました。各プロジェクトにはいくつかのNuGetパッケージがありました。1つのプロジェクトでEnterprise Library Semantic Loggingパッケージのバージョンを使用しており、他の2つのプロジェクト（最初のプロジェクトを参照）で同じパッケージの古いバージョンを使用しています。すべてエラーなしでコンパイルされますが、パッケージを使用しようとすると、不思議な「メソッドが見つかりません」というエラーが発生しました。

修正は、2つのプロジェクトから古いNuGetパッケージを削除して、実際に必要な1つのプロジェクトにのみ含まれるようにすることでした。（また、ソリューション全体をクリーンに再構築しました。）

あなたの参照をチェックしてください！

ソリューションプロジェクト全体で一貫して同じサードパーティライブラリを参照していることを確認してください（バージョンを信頼するだけでなく、パスを確認してください）。

たとえば、1つのプロジェクトでiTextSharp v.1.00.101を使用していて、NuGetまたはiTextSharp v1.00.102をどこかで参照している場合、これらのタイプのランタイムエラーが発生し、なんらかの方法でコードに侵入します。

同じDLLを指すように3つのプロジェクトすべてでiTextSharpへの参照を変更し、すべてが機能しました。

独自のNuGetサーバーで開発する場合は、アセンブリのバージョンがすべて同じであることを確認してください。

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

また、プロジェクトやソリューションを「クリーン」にして、再構築してみてください！

オフにしてからもう一度オンにしてみましたか？冗談はさておき、私のコンピュータを再起動することが実際に私にトリックをもたらしたものであり、他の回答のいずれにも言及されていません。

この問題が発生しましたが、UIプロジェクトから以前のバージョンのDLLを参照していたことが原因であることがわかりました。したがって、コンパイルしたときは嬉しかったです。ただし、実行時には以前のバージョンのDLLが使用されていました。

ソリューションを再ビルド/クリーンアップ/再デプロイする必要があると想定する前に、他のすべてのプロジェクトのリファレンスを確認してください。

私の場合、それはコピー/貼り付けの問題でした。私はどういうわけか私のマッピングプロファイルのプライベートコンストラクタで終わった：

using AutoMapper;

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

（俳優の前に欠けている「パブリック」に注意してください）

これは完全に正常にコンパイルされましたが、AutoMapperがプロファイルをインスタンス化しようとしたときに、（もちろん！）コンストラクターを見つけることができません！

私は、同じ例外がスローされるという同様のシナリオがありました。私のWebアプリケーションソリューションには、たとえば、DALとDAL.CustSpecという名前の2つのプロジェクトがありました。DALプロジェクトにはMethod1という名前のメソッドがありましたが、DAL.CustSpecにはありませんでした。私のメインプロジェクトには、DALプロジェクトへの参照と、AnotherProjという名前の別のプロジェクトへの参照がありました。私のメインプロジェクトはMethod1を呼び出しました。AnotherProjプロジェクトには、DALプロジェクトではなくDAL.CustSpecプロジェクトへの参照がありました。ビルド構成には、DALとDAL.CustSpecプロジェクトの両方がビルドされるように構成されていました。すべてがビルドされた後、私のWebアプリケーションプロジェクトのBinフォルダーには、AnotherProjおよびDALアセンブリが含まれていました。ただし、Webサイトを実行したとき、WebサイトのTemporary ASP.NETフォルダーのファイルにはDAL.CustSpecアセンブリがあり、DALアセンブリはありませんでした。何らかの理由で。もちろん、Method1を呼び出す部分を実行すると、「Method not found」エラーを受け取りました。

このエラーを修正するには、AnotherProjプロジェクトの参照をDAL.CustSpecからDALだけに変更し、Temporary ASP.NET Filesフォルダー内のすべてのファイルを削除してから、Webサイトを再実行する必要がありました。その後、すべてが機能し始めました。また、DAL.CustSpecプロジェクトがビルドされていないことを、ビルド構成でオフにして確認しました。

これが将来誰かを助ける場合に備えて、私はこれを共有すると思いました。

ASP.NET Webサイトでも同じ状況に遭遇しました。パブリッシュされたファイルを削除し、VSを再起動し、プロジェクトをクリーンアップして再ビルドしました。次の公開後、エラーはなくなりました...

私は自分の変更でシェルブセットを作成し、ワークスペースでhttps://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627fでTFS Power Toolsの「scorch」を実行することにより、この問題を解決しました。次に、変更を保留解除し、プロジェクトを再コンパイルしました。このようにして、ワークスペース内に存在する可能性のある「ハンギングパーティ」をクリーンアップし、新しいパーティで起動します。もちろん、これにはTFSを使用している必要があります。

また、問題が報告されているメソッドのパラメーターまたは戻り値の型に問題がある可能性もあり、「欠落」メソッド自体は問題ありません。

それが私の場合に起こっていたことであり、誤解を招くメッセージが原因で問題を解明するのにはるかに長い時間がかかりました。パラメーターの型のアセンブリはGACで古いバージョンであることが判明しましたが、使用されているバージョン番号付けスキームの変更により、古いバージョンでは実際にはバージョン番号が高くなっています。その古い/より高いバージョンをGACから削除すると、問題が修正されました。

Costura.Fody 1.6および2.0を使用：
他のすべての潜在的なソリューションが機能しない状態でこの同じ種類のエラーを調査するのに多くの時間を費やした後、埋め込まれているDLLの古いバージョンが、実行しているのと同じディレクトリにあることがわかりました新しくコンパイルされた.exe。どうやら、同じディレクトリでローカルファイルを最初に探し、次に埋め込みライブラリを内側に探します。古いDLLの削除は機能しました。

明確に言うと、私の参照が古いDLLを指しているのではなく、古いDLLのコピーが、コンパイルしたシステムとは別のシステムでアプリケーションをテストしているディレクトリにあったということです。

私の場合、.csprojファイルで参照されたものと同じ名前の古いDLLが含まれているフォルダーでしたが、パスが明示的に指定されていたため、それらが何らかの形で含まれていたため、同じDLLのいくつかのバージョンが競合していました。

問題の原因がGACの古いバージョンのアセンブリである場合。
これが役立ちます。方法：グローバルアセンブリキャッシュからアセンブリを削除します。

私の場合、MissingMethodExceptionは同じファイルにあるメソッドに対するものでした！

ただし、私は.Net Standard2を使用するNuGetパッケージを4.7.1ターゲットプロジェクトに追加したため、System.Net.Httpのバージョンの競合が発生しました（4.7.1：バージョン4.0.0.0、.NETを使用するNuGetパッケージ）標準2では4.2.0.0が必要です）。これは、4.7.2で改善されるべき既知の問題のようです（注2を参照）。

他のすべてのプロジェクトでこのようなバインディングリダイレクトを使用していました。これは、持っていない4.2.0.0をロードしようとするとすぐに例外が発生したためです。

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>

この1つのプロジェクトを除いて、System.Net.Http.HttpResponseMessageをパラメーターまたは戻り値の型（デバッグ中のパラメーター、実行時の戻り値の型）として使用するローカル関数を呼び出すときにのみSystem.Net.Httpを読み込もうとするようですデバッガなしのテスト、これも少し奇妙です）。また、System.Net.Httpの4.2.0.0バージョンをロードできなかったというメッセージを表示する代わりに、この例外を返します。

これはMVC4を使用しているときに起こりました。このスレッドを読んだ後、エラーをスローしていたオブジェクトの名前を変更することにしました。

私はクリーンとリビルドを行い、2つのプロジェクトをスキップしていることを指摘しました。そのうちの1つを再構築すると、関数を開始して終了しないというエラーが発生しました。

そのため、VSは、書き直したいモデルを参照しているのかどうかを尋ねることなく参照していました。

万が一の場合に備えて、古い問題ですが、私の問題は少し奇妙でした。

Jenkinsの使用中にこのエラーが発生しました。

最終的に、システムの日付が手動で将来の日付に設定され、dllがその将来の日付でコンパイルされることがわかりました。日付が通常に戻されたとき、MSBuildはファイルがより新しいと解釈し、プロジェクトの再コンパイルを必要としませんでした。

私はこの問題に遭遇しました、そして私にとっては、1つのプロジェクトがExample.Sensors名前空間にあるリストを使用していて、別のタイプがISensorInfoインターフェイスを実装していたということでした。クラスType1SensorInfo。ただし、このクラスは、Example.Sensors.Type1の名前空間の1層深いものでした。Type1SensorInfoを逆シリアル化してリストにしようとすると、例外がスローされました。ISensorInfoインターフェイスにExample.Sensors.Type1を使用して追加した場合、例外はありません。

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() 
    }
}

事実上クラッシュしたバックグラウンドで多数のMSBuildプロセスが実行されているときにも同じことが起こりました（古いバージョンのコードへの参照がありました）。私はVSを閉じ、プロセスエクスプローラーですべてのMSBuildプロセスを強制終了してから、再コンパイルしました。

同じDLLの異なるバージョン（異なる場所にある）をそれぞれ参照する2つの他のプロジェクトを参照するテストプロジェクトがありました。これはコンパイラを混乱させました。

私の場合、spotify.exeは、私のWeb APIプロジェクトが開発マシンで使用するのと同じポートを使用していました。ポート番号は4381でした。

Spotifyを終了すると、すべてが再びうまくいきました:)

メソッドが指定していないパラメーターを必要とするときにこの問題が発生しました

私の場合、コードはまったく変更されておらず、突然サーバーの1つがこれを取得し始め、この例外のみが発生しました（すべてのサーバーに同じコードがありますが、問題が発生したのは1つだけです）。

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が破損していたことです-私たちは毎日午前3時にAppPoolのリサイクルを自動化し、問題は午前3時に始まり、翌日の午前3時に自然に終了しました。

Microsoftからの参照バグである必要があります。

私はすべてのライブラリをクリーンアップして再構築しましたが、それでも同じ問題が発生し、これを解決できませんでした。

私が行ったのは、Visual Studio Applicationを閉じて再度開くことだけでした。これでうまくいきました。

このような単純な問題を修正するのにそれだけ時間がかかる可能性があることは非常にイライラします。

私の場合、私のプロジェクトはを参照していましたMicrosoft.Net.Compilers.2.10.0。に切り替えたところMicrosoft.Net.Compilers.2.7.0、エラーはなくなりました。このようなさまざまな原因による不思議なエラーです。