TypeLoadExceptionは「実装なし」と言いますが、実装されています

テストマシンに非常に奇妙なバグがあります。エラーは：

System.TypeLoadException: Method 'SetShort' in type 'DummyItem' from assembly 'ActiveViewers (...)' does not have an implementation.

なぜか分かりません。SetShortでありDummyItem、クラス、そして私もちょうど必ずそれが問題をバージョン管理、展開/ではないことを確認するために、イベントログへの書き込みとバージョンを再コンパイルしました。奇妙なことは、呼び出し側のコードがSetShortメソッドを呼び出さないことです。

注 -この回答が役に立たない場合は、時間をかけて、人々が追加した他の回答を下にスクロールしてください。

短い答え

これは、あるアセンブリのインターフェイスにメソッドを追加し、次に別のアセンブリの実装クラスに追加したが、新しいバージョンのインターフェイスアセンブリを参照せずに実装アセンブリを再構築した場合に発生する可能性があります。

この場合、DummyItemは別のアセンブリからのインターフェースを実装します。最近、SetShortメソッドがインターフェイスとDummyItemの両方に追加されましたが、DummyItemを含むアセンブリは、以前のバージョンのインターフェイスアセンブリを参照して再構築されました。つまり、SetShortメソッドは事実上そこにありますが、インターフェースの同等のメソッドにリンクする魔法のソースはありません。

長い答え

これを再現したい場合は、以下を試してください。

1. クラスライブラリプロジェクトを作成：InterfaceDef、クラスを1つだけ追加してビルド：

   public interface IInterface
   {
       string GetString(string key);
       //short GetShort(string key);
   }

2. 2番目のクラスライブラリプロジェクトを作成します。実装（別のソリューションを使用）、InterfaceDef.dllをプロジェクトディレクトリにコピーし、ファイル参照として追加し、クラスを1つだけ追加してビルドします。

   public class ImplementingClass : IInterface
   {
       #region IInterface Members
       public string GetString(string key)
       {
           return "hello world";
       }
   
       //public short GetShort(string key)
       //{
       //    return 1;
       //}
       #endregion
   }

3. 3つ目のコンソールプロジェクトClientCodeを作成し、2つのdllをプロジェクトディレクトリにコピーして、ファイル参照を追加し、次のコードをMainメソッドに追加します。

    IInterface test = new ImplementingClass();
    string s = test.GetString("dummykey");
    Console.WriteLine(s);
    Console.ReadKey();

4. コードを1回実行すると、コンソールに「hello world」と表示されます

5. 2つのdllプロジェクトのコードのコメントを外して再構築します-2つのdllをClientCodeプロジェクトにコピーして戻し、再構築してもう一度実行してみます。TypeLoadExceptionは、ImplementingClassをインスタンス化しようとすると発生します。

質問者自身の回答がすでに述べていることに加えて、以下に注意する価値があるかもしれません。これが発生する理由は、クラスがインターフェイスメソッドと同じシグネチャを持つメソッドを、そのメソッドを実装せずに持つ可能性があるためです。次のコードはそのことを示しています。

public interface IFoo
{
    void DoFoo();
}

public class Foo : IFoo
{
    public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
    void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}

Foo foo = new Foo();
foo.DoFoo();               // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo();              // This calls the interface method

エラーメッセージのメソッドが使用するクラスを定義する別のアセンブリへの参照がアプリ​​ケーションになかったときに、これが発生しました。PEVerifyを実行すると、「システムは指定されたファイルを見つけることができません。」というより役立つエラーが発生しました。

私は同じメッセージに遭遇し、ここに私たちが見つけたものがあります：私たちはプロジェクトでサードパーティのdllを使用しています。それらの新しいリリースがリリースされた後、新しいdllのセットを指すようにプロジェクトを変更し、正常にコンパイルしました。

実行時にインターフェイスクラスの1つをインスタンス化しようとすると、例外がスローされました。他のすべての参照が最新であることを確認しましたが、まだ運がありませんでした。エラーメッセージ内のメソッドの戻り値の型が、新しい参照されていないアセンブリからの完全に新しい型であることを（オブジェクトブラウザーを使用して）見つけるにはしばらく時間がかかりました。

アセンブリへの参照を追加すると、エラーが消えました。

• エラーメッセージはかなり誤解を招くものでしたが、多かれ少なかれ正しい方向を示していました（正しい方法、間違ったメッセージ）。
• 問題のメソッドを使用しなかったにもかかわらず、例外が発生しました。
• これは私に質問を導きます：この例外がいずれにせよスローされた場合、コンパイラはなぜそれをピックアップしないのですか？

次のシナリオでこのエラーを受け取りました。

• アセンブリAとBの両方がSystem.Web.Mvcバージョン3.0.0.0を参照しました
• アセンブリAはアセンブリBを参照し、System.Web.Mvcからクラスを返すメソッドを使用して、アセンブリBからのインターフェイスを実装するクラスがありました。
• System.Web.Mvcバージョン4.0.0.0にアップグレードされたアセンブリA
• アセンブリCは以下のコードを実行しました（FertPin.Classes.ContactはアセンブリAに含まれていました）。

var target = Assembly.GetAssembly(typeof(FertPin.Classes.Contact));

私の修正は、アセンブリBのSystem.Web.Mvc参照を4.0.0.0にアップグレードすることでした。今明らかなようです！

オリジナルポスターに感謝！

このエラーが発生する可能性のある他の場合は、署名されたアセンブリのバージョンが正しくない場合です。これはこの原因の通常の症状ではありませんが、ここに私がそれを得たシナリオがありました

• asp.netプロジェクトにはアセンブリAとアセンブリBが含まれ、Bは厳密に名前が付けられています

• アセンブリAは、Activator.CreateInstanceを使用してアセンブリCをロードします（つまり、個別に構築されたCへの参照はありません）。

• Cは、現在存在するより古いバージョンのアセンブリBを参照して構築されました

それが誰かを助けることを願っています-これを理解するのに私は年齢を要しました。

私にもこのエラーがありました。それは、任意のCPUアセンブリを参照する任意のCPU実行が、x86アセンブリを順番に参照したことが原因でした。

MyApp.Interfaces（Any CPU）を派生したMyApp.Implementations（Any CPU）のクラスのメソッドについて例外が報告されましたが、fuslogvw.exeでMyAppから非表示の「不正な形式のプログラムをロードしようとする」例外が見つかりました両方で使用される.CommonTypes（x86）。

私はこれに戻ってきます...ここでの答えの多くは、問題が何であるかを説明するのに優れていますが、それを修正する方法はありません。

これに対する解決策は、プロジェクトの公開ディレクトリにあるbinファイルを手動で削除することです。すべての参照をクリーンアップし、プロジェクトで最新のDLLを使用するように強制します。

IISが機能しなくなる傾向があるため、発行ツールの削除機能の使用はお勧めしません。

このエラーメッセージに対する別の難解な解決策があります。ターゲットフレームワークを.Net 4.0から4.6にアップグレードしました。ビルドしようとすると、ユニットテストプロジェクトで「System.TypeLoadException ...が実装されていません」というエラーが表示されました。また、「BuildShadowTask」タスクが予期せず失敗したという、実装されていない可能性のある同じメソッドに関する2番目のエラーメッセージも表示されました。ここでのアドバイスはどれも役に立たないようだったので、「BuildShadowTask」を検索し、MSDNで投稿を見つけました。そのため、テキストエディターを使用して、ユニットテストプロジェクトのcsprojファイルからこれらの行を削除しました。

<ItemGroup>
  <Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>

その後、両方のエラーがなくなり、プロジェクトが構築されました。

Autofacと多くの動的アセンブリ読み込みを使用している状況で、このエラーが発生しました。

Autofac解決操作の実行中に、ランタイムはアセンブリの1つをロードできませんでした。エラーメッセージはそれを不平を言ったMethod 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation。Windows Server 2012 R2 VMで実行すると症状が発生したが、発生しなかったが、Windows 10またはWindows Server 2016 VMでは発生し。

ImplementationAssemblySystem.Collections.Immutable1.1.37を参照IMyInterface<T1,T2>し、別ので定義されたインターフェースの実装を含みましたDefinitionAssembly。DefinitionAssembly参照System.Collections.Immutable1.1.36を。

IMyInterface<T1,T2>「実装されていない」メソッドにはIImmutableDictionary<TKey, TRow>、で定義されているタイプのパラメータがありましたSystem.Collections.Immutable。

System.Collections.Immutableプログラムディレクトリにあるの実際のコピーはバージョン1.1.37でした。私のWindows Server 2012 R2 VMでは、GACにSystem.Collections.Immutable1.1.36のコピーが含まれていました。Windows 10およびWindows Server 2016では、GACにSystem.Collections.Immutable1.1.37のコピーが含まれていました。ロードエラーは、GACに古いバージョンのDLLが含まれている場合にのみ発生しました。

したがって、アセンブリの読み込みエラーの根本的な原因は、への参照の不一致でしたSystem.Collections.Immutable。インターフェイスの定義と実装は同じように見えるメソッドシグネチャを持っていましたが、実際にはの異なるバージョンに依存しSystem.Collections.Immutableていたため、ランタイムは実装クラスをインターフェイスの定義と一致するとは見なしていませんでした。

次のバインディングリダイレクトをアプリケーション構成ファイルに追加すると、問題が解決しました。

<dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.1.37.0" newVersion="1.1.37.0" />
</dependentAssembly>

私はこれを「ダイヤモンド」形のプロジェクト依存関係で取得しました：

• プロジェクトAはプロジェクトBとプロジェクトDを使用します
• プロジェクトBはプロジェクトDを使用

プロジェクトAを再コンパイルしましたが、プロジェクトBは再コンパイルしませんでした。これにより、プロジェクトBは古いバージョンのプロジェクトD dllを「挿入」できました。

これは、ASP.NETプロジェクトに依存していたプロジェクト（およびアセンブリ名）の名前を変更したときに発生しました。Webプロジェクトの型は、依存アセンブリにインターフェイスを実装しました。[ビルド]メニューから[クリーンソリューション]を実行したにもかかわらず、以前の名前のアセンブリがbinフォルダーに残り、Webプロジェクトが実行されたとき

var types = AppDomain.CurrentDomain.
   GetAssemblies().
   ToList().
   SelectMany( s => s.GetTypes() /* exception thrown in this call */ )
;

上記の例外がスローされ、実装するWebタイプのインターフェースメソッドが実際には実装されていないことが報告されました。Webプロジェクトのbinフォルダー内のアセンブリを手動で削除すると、問題が解決しました。

また、アセンブリの1つの単体テスト中にコードカバレッジを有効にしていた場合にも、このエラーが発生しました。インターフェイスの新しいバージョンを実装するように更新したにもかかわらず、何らかの理由でVisual Studioはこの特定のDLLの古いバージョンを「バッファリング」しました。コードカバレッジを無効にすると、エラーが解消されました。

このエラーは、Assembly.LoadFrom（String）を使用してアセンブリが読み込まれ、Assembly.Load（Byte []）を使用して既に読み込まれているアセンブリを参照している場合にも発生する可能性があります。

たとえば、メインアプリケーションの参照アセンブリをリソースとして埋め込みましたが、アプリは特定のフォルダーからプラグインを読み込みます。

LoadFromを使用する代わりに、Loadを使用する必要があります。次のコードがその仕事をします：

private static Assembly LoadAssemblyFromFile( String filePath )
{
    using( Stream stream = File.OpenRead( filePath ) )
    {
        if( !ReferenceEquals( stream, null ) )
        {
            Byte[] assemblyData = new Byte[stream.Length];
            stream.Read( assemblyData, 0, assemblyData.Length );
            return Assembly.Load( assemblyData );
        }
    }
    return null;
}

マネージC ++に関連するこのタイプの問題のもう1つの説明。

特別な署名を持つマネージC ++を使用して作成されたアセンブリで定義されたインターフェイスをスタブ化しようとすると、スタブの作成時に例外が発生します。

これはRhino Mocksと、おそらくを使用するすべてのモックフレームワークに当てはまりますSystem.Reflection.Emit。

public interface class IFoo {
  void F(long bar);
};

public ref class Foo : public IFoo {
public:
  virtual void F(long bar) { ... }
};

インターフェイス定義は次のシグネチャを取得します。

void F(System.Int32 modopt(IsLong) bar)

C ++型longはSystem.Int32（または単にintC＃で）マップされることに注意してください。Rhino MocksメーリングリストでAyende Rahienが述べたようにmodopt、問題の原因はややあいまいです 。

ソリューションをMVC3からMVC5にアップグレードし、ユニットテストプロジェクトから同じ例外を受け取り始めました。

すべての参照を調べて古いファイルを探したところ、最終的に、ユニットテストプロジェクトでMvcに対してbindingRedirectを実行する必要があることがわかりました。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

私の場合、WinFormsツールボックスをリセットするのに役立ちました。

Formデザイナーでを開くと例外が発生しました。ただし、コードのコンパイルと実行は可能であり、コードは期待どおりに動作しました。例外がローカルで発生しましたUserControlは、参照されているライブラリの1つからのインターフェースを実装する。このライブラリが更新された後にエラーが発生しました。

これUserControlは、WinFormsツールボックスにリストされていました。おそらく、Visual Studioは古いバージョンのライブラリへの参照を保持していたか、古いバージョンをどこかにキャッシュしていました。

これが私がこの状況から回復した方法です：

1. WinFormsツールボックスを右クリックしてReset Toolbox、コンテキストメニューをクリックします。（これにより、ツールボックスからカスタムアイテムが削除されます）。
   私の場合、ツールボックスのアイテムはデフォルトの状態に復元されました。ただし、ポインタ矢印がツールボックスにありませんでした。
2. Visual Studioを閉じます。
   私の場合、Visual Studioは違反例外で終了し、中止されました。
3. Visual Studioを再起動します。
   これですべてがスムーズに実行されています。

FWIW、存在しないバージョンの参照されたアセンブリにリダイレクトされる構成ファイルがあると、これが発生しました。勝利のためのFusionログ！

フレームワークのバージョン4.5にあるアセンブリ 'C'にクラスがあり、フレームワークのバージョン4.5.1にあるアセンブリ 'A'にインターフェイスを実装し、アセンブリの基本クラスとして機能するため、このエラーが発生しましたフレームワークのバージョン4.5.1にもある「B」。アセンブリ「B」をロードしようとしたときに、システムが例外をスローしました。さらに、3つのアセンブリすべてに.net 4.5.1をターゲットとするいくつかのnugetパッケージをインストールしました。何らかの理由で、アセンブリ 'B'にnuget参照が表示されていなくても、正常にビルドされていました。

実際の問題は、アセンブリがインターフェイスを含むnugetパッケージの異なるバージョンを参照しており、バージョン間でインターフェイスの署名が変更されていたことであることが判明しました。

私の場合、以前mylibはリポジトリ外の兄弟フォルダにあるプロジェクトを参照していました-それを呼び出しましょうv1.0。

|-- myrepo
|    |-- consoleApp
|    |-- submodules
|         |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)

後で私はそれを適切に行い、gitサブモジュールを介してそれを使用しました-それを呼び出しましょうv2.0。consoleAppただし、1つのプロジェクトが適切に更新されませんでした。それはまだv1.0私のgitプロジェクトの外の古いプロジェクトを参照していました。

紛らわしいことに、*.csprojが明らかに間違っていて、を指していますv1.0が、Visual Studio IDEはv2.0プロジェクトとしてパスを示しました！インターフェースとクラスを検査するF12 v2.0もバージョンに移動しました。

コンパイラによってbinフォルダに配置されたアセンブリはv1.0バージョンであり、それが頭痛の種でした。

IDEが私に嘘をついていたという事実は、エラーを理解することをさらに難しくしました。

解決策：からプロジェクト参照を削除しConsoleApp、それらを再度追加しました。

一般的なヒント：すべてのアセンブリを最初から再コンパイルし（可能な場合は、もちろんnugetパッケージではできません）、bin\debugフォルダー内の日時スタンプを確認します。古い日付のアセンブリが問題です。

私はほとんど同じ問題に直面しました。このエラーの原因を頭を掻きました。私はクロスチェックし、すべてのメソッドが実装されました。

グーグルで私はとりわけこのリンクを得ました。@Paul McLinkのコメントに基づいて、この2つのステップで問題が解決されました。

1. Visual Studioを再起動します。
2. クリーン、ビルド（リビルド）

そしてエラーはなくなった。

VSプラグインを再起動します

ありがとうポール:)

これがこのエラーに遭遇した人を助けることを願っています:)

ユニットテストの実行中にもこの問題に遭遇しました。アプリケーションは正常に実行され、エラーは発生しませんでした。私の場合の問題の原因は、テストプロジェクトのビルドをオフにしたことです。テストプロジェクトのビルドを再度有効にすると、問題が解決しました。

2つのプロジェクトが同じ名前のアセンブリをビルドしたときにVisual Studio Pro 2008でこれを確認しました。1つはクラスlib SDF.dll、もう1つはアセンブリ名sdf.exeでlibを参照します。参照アセンブリの名前を変更すると、例外がなくなりました

これは単に、私の場合、実装プロジェクトが古いことを意味します。インターフェイスを含むDLLは再構築されましたが、実装DLLは古くなっています。

これがこのエラーに対する私の見解です。

externメソッドを追加しましたが、貼り付けに失敗しました。DllImportAttributeコメントアウト行に入れてしまいました。

/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")] 
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);

属性が実際にソースに含まれていることを確認すると、問題が修正されました。

x86ビルドタイプが選択されているため、WCFサービスでこれが発生し、ビンがbinではなくbin \ x86の下に存在するようになりました。Any CPUを選択すると、再コンパイルされたDLLが正しい場所に移動しました（これが最初にどのように発生したかについては詳しく説明しません）。

私も同じ問題を抱えていました。メインプログラムによって読み込まれたアセンブリに、「ローカルコピー」がtrueに設定された参照が含まれていることがわかりました。これらの参照のローカルコピーは、他の参照の「ローカルのコピー」がfalseに設定されていたために存在しなかった、同じフォルダー内の他の参照を探していました。「誤って」コピーされた参照を削除した後、メインプログラムが参照の正しい場所を探すように設定されていたため、エラーはなくなりました。どうやら、参照のローカルコピーは、メインプログラムに存在する元のコピーの代わりに使用されたため、呼び出しのシーケンスを台無しにしました。

持ち帰りメッセージは、必要なアセンブリをロードするためのリンクがないためにこのエラーが表示されることです。

私の場合、を使用TypeBuilderしてタイプを作成しようとしていました。TypeBuilder.CreateTypeこの例外を投げました。最終的に、インターフェースの実装に役立つメソッドをMethodAttributes.Virtual呼び出すときに属性に追加する必要があることに気付きTypeBuilder.DefineMethodました。これは、このフラグがないと、メソッドはインターフェイスを実装せず、代わりに同じシグネチャを持つ新しいメソッドを実装するためです（たとえを指定しなくてもMethodAttributes.NewSlot）。

補足として：これは、フェイクアセンブリの生成に使用されたnugetパッケージを更新した場合にも発生する可能性があります。nugetパッケージのV1.0をインストールして、フェイクアセンブリ「fakeLibrary.1.0.0.0.Fakes」を作成するとします。次に、nugetパッケージの最新バージョンに更新します。たとえば、インターフェースに新しいメソッドを追加したv1.1です。Fakesライブラリはまだライブラリのv1.0を探しています。単に偽のアセンブリを取り外し、それを再生します。それが問題であった場合、これでおそらく修正されます。

最近のWindowsの更新後にこのエラーを受け取りました。インターフェイスから継承するようにサービスクラスを設定しました。インターフェイスには、C＃のかなり新しい機能であるValueTupleを返す署名が含まれていました。

私が推測できるのは、Windows Updateが新しいものをインストールしたことですが、それを明示的に参照したり、バインディングリダイレクトを更新したりするなどです...最終的な結果は、メソッドのシグネチャを何か「標準」に変更しただけだと思います。