アセンブリエラーからタイプを読み込めませんでした

Castle WindsorのFluent Interfaceを学習するために、次の簡単なテストを作成しました。

using NUnit.Framework;
using Castle.Windsor;
using System.Collections;
using Castle.MicroKernel.Registration;

namespace WindsorSample {
    public class MyComponent : IMyComponent {
        public MyComponent(int start_at) {
            this.Value = start_at;
        }
        public int Value { get; private set; }
    } 
    public interface IMyComponent {
        int Value { get; }
    }

    [TestFixture]
    public class ConcreteImplFixture {
        [Test]
        public void ResolvingConcreteImplShouldInitialiseValue() {
            IWindsorContainer container = new WindsorContainer();
            container.Register(Component.For<IMyComponent>().ImplementedBy<MyComponent>().Parameters(Parameter.ForKey("start_at").Eq("1")));
            IMyComponent resolvedComp = container.Resolve<IMyComponent>();
            Assert.AreEqual(resolvedComp.Value, 1); 
        }
    }
}

TestDriven.NETを介してテストを実行すると、次のエラーが発生します。

System.TypeLoadException : Could not load type 'Castle.MicroKernel.Registration.IRegistration' from assembly 'Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'.
at WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue()

NUnit GUIを介してテストを実行すると、次のようになります。

WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue:
System.IO.FileNotFoundException : Could not load file or assembly 'Castle.Windsor, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The system cannot find the file specified.

リフレクターで参照しているアセンブリを開くと、その情報を確認できます。

Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc

そして、Castle.MicroKernel.Registration.IRegistrationが確実に含まれていること

何が起こっているのでしょうか？

バイナリはCastleの最新のビルドから取得されているので、nantを使用したことがないので、ソースから再コンパイルする必要はなく、binディレクトリのファイルを取得しただけです。また、私のプロジェクトは問題なくコンパイルできることも指摘しておきます。

アセンブリはグローバルアセンブリキャッシュ（GAC）ですか、それとも、読み込まれていると思われるアセンブリをオーバーライドする可能性のある場所ですか？これは通常、正しくないアセンブリがロードされた結果です。私にとっては、通常、GACに何かがあり、bin / Debugにあるバージョンを上書きしています。

1つのプロジェクトが別のプロジェクト（「クラスライブラリ」を参照する「Windowsアプリケーション」タイプなど）を参照していて、両方に同じアセンブリ名がある場合、このエラーが発生します。参照プロジェクトに厳密な名前を付けるか、（さらに優れた）参照プロジェクトのアセンブリの名前を変更できます（VSのプロジェクトプロパティの[アプリケーション]タブで）。

私に対するこれの解決策は上に述べられていなかったので、私はロングテールに私の答えを追加すると思いました...

HttpHandler使用されなくなった（そして有効な参照ではなくなった）web.configのクラス（an ）への古い参照ができてしまいました。何らかの理由で、スタジオで実行している間は無視されました（または、開発セットアップ内でそのクラスにまだアクセスできるのでしょうか？）。web.configでアセンブリ名を検索し、未使用のハンドラー参照を削除すると、このエラーはなくなり、すべてが正常に機能しました。これが他の誰かを助けることを願っています。

私は同じ問題を抱えていましたが、私にとっては名前空間やプロジェクトの命名とは何の関係もありませんでした。

しかし、何人かのユーザーがそれをほのめかしたように、まだ参照されている古いアセンブリと関係がありました。

すべてのプロジェクトのすべての「bin」/バイナリフォルダーを削除し、ソリューション全体を再構築することをお勧めします。これにより、古くなっている可能性のあるアセンブリがすべて洗い流され、その後、MEFはすべてのプラグインを問題なくエクスポートしました。

私はこのエラーを受け取り、StackOverflowや他の場所で何も見つけなかったが、この質問に対するbmoeskauの回答は、修正として正しい方向を示していましたが、まだ回答としては言及されていません。私の答えは元の質問とは厳密には関係ありませんが、この問題を抱えている誰かがGoogleまたは類似のものを検索することで、ここに道を見つけると仮定して、ここに投稿します（これから1か月後に再び私に噛まれたときのように） 、arg！）。

私のアセンブリはGACにあるので、理論的には1つのバージョンのアセンブリしか使用できません。 IISが古いバージョンを効果的にキャッシュしていて、このエラーが発生している場合を除きます。GACでアセンブリを変更、再構築、再インストールしたところです。1つの考えられる解決策は、タスクマネージャーを使用してw3wp.exeを強制終了することです。これにより、IISはGACからアセンブリを再読み込みする必要があり、問題は解決しました。

バージョン= 1.0.3.0はCastle RC3を示しますが、流暢なインターフェイスはRC3のリリースから数か月後に開発されました。したがって、バージョン管理の問題があるようです。たぶん、あなたはGACにCastle RC3を登録していて、それを使用しています...

私は時々これを受け取り、GACにアセンブリを置くことは常にダウンしています

名前空間の変更が原因でこのエラーが発生した場合は、そのプロジェクトのフォルダーの名前が同じ名前に変更されていることを確認し、VS.NETを閉じます。メモ帳で問題のあるプロジェクトを編集し、ノードを置き換えます

"RootNamespace> New_Name_Of_Folder_Of_Your_Project_Namespace" RootNamespace> "AssemblyName> New_Name_Of_Folder_Of_Your_Project_Namespace" AssemblyName>

DLLの.pdbファイルを削除すると、この問題は解決しました。dllがILMergeを使用して作成されたという事実と関係があると思います。

このような問題に遭遇したとき、FUSLOGVWツールは非常に役立ちます。アセンブリバインディング情報をチェックしてログに記録します。ライブラリが見つからない場合や、GACに読み込まれているバージョンが異なる場合があります。参照されるライブラリのプラットフォームが問題を引き起こしている場合があります。このツールは、依存関係のバインディングがどのように解決されているかを明確にします。これは、問題の調査/デバッグに本当に役立つ場合があります。

Fusion Log Viewer / fuslogvw / Assembly Binding Log Viewer。詳細/ダウンロードはこちらをご覧ください：http : //msdn.microsoft.com/en-us/library/e74a18c4.aspx。

クラス名を因数分解した後、私はこの問題を抱えていました：
Could not load type 'Namspace.OldClassName' from assembly 'Assembly name...'.

IISを停止して内容を削除すると、Temporary ASP.NET Files修正されました。

あなたのプロジェクト（32/64ビット、.netバージョンなど）に依存して正しいことTemporary ASP.NET Filesが異なります：

• 64ビット
  %systemroot%\Microsoft.NET\Framework64\{.netversion}\Temporary ASP.NET Files\
• 32ビット
  %systemroot%\Microsoft.NET\Framework\{.netversion}\Temporary ASP.NET Files\
• 私の開発マシンではそれがありました（おそらくそのIIS Expressが原因ですか？）
  %temp%\Temporary ASP.NET Files

おそらくそうではないかもしれませんが、私にとっては、アプリケーションが同じアセンブリ名（xxx.exeがxxx.dllをロード）でライブラリをロードしようとしたことが原因でした。

別の原因でこれに遭遇するだけです：

リリースモードで単体テストを実行していますが、読み込まれているライブラリは、更新されていないデバッグモードのバージョンでした

さらに別のソリューション：古いDLLが相互にポイントし、Visual Studioによってキャッシュされます。

C:\Users\[yourname]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

VSを終了し、このフォルダ内のすべてを削除し、Bobはあなたの叔父です。

同じ問題がありました。GAC経由でアセンブリを更新することで、これを解決しました。

開発マシンでgacutilを使用するには、次の場所に移動します Start -> programs -> Microsoft Visual studio 2010 -> Visual Studio Tools -> Visual Studio Command Prompt (2010)。

これらのコマンドを使用して、それぞれアンインストールと再インストールを行いました。

gacutil /u myDLL

gacutil /i "C:\Program Files\Custom\mydllname.dll"

注：私の場合、dllをアンインストールしていません。現在のパスでdllを更新したばかりです。

このエラーが発生したアプリケーションに共通する参照の異なるバージョンに対してビルドされたアセンブリに（リフレクションを介して）タイプをロードしようとしたときに、このシナリオに遭遇しました。

アセンブリの両方のバージョンでタイプが変更されていないことを確信しているので、不足しているアセンブリをアプリケーションが既にロードしたものにマップするカスタムアセンブリリゾルバーを作成しました。最も簡単な方法は、次のようにプログラムクラスに静的コンストラクタを追加することです。

using System.Reflection
static Program()
{
    AppDomain.CurrentDomain.AssemblyResolve += (sender, e) => {
        AssemblyName requestedName = new AssemblyName(e.Name);

        if (requestedName.Name == "<AssemblyName>")
        {
            // Load assembly from startup path
            return Assembly.LoadFile($"{Application.StartupPath}\\<AssemblyName>.dll");
        }
        else
        {
            return null;
        }
    };
}

もちろん、これはアセンブリがアプリケーションの起動パスにあり、簡単に調整できることを前提としています。

別の原因でこれに遭遇するだけです：

ILRepackで作成したマージ済みアセンブリを使用していました。タイプを照会するアセンブリは、ILRepackに渡される最初のアセンブリでなければなりません。そうでない場合、そのタイプは使用できません。

* .configのバインディングリダイレクトでこれを解決できる場合があります。http://blogs.msdn.com/b/dougste/archive/2006/09/05/741329.aspxは、新しいフレームワークで古い.netコンポーネントを使用することについての良い議論があります。 http://msdn.microsoft.com/en-us/library/eftw1fys(vs.71).aspx

これは通常、GACにデプロイされたアセンブリの1つのバージョンがあり、IDEのアセンブリに追加した可能性のある新しいクラスで更新されていない場合に発生します。したがって、GACのアセンブリがプロジェクトで行った変更で更新されていることを確認してください。

たとえば、共通のクラスライブラリがあり、そのクラスライブラリにCommon.ClassAタイプがあり、これを厳密な名前のGACにデプロイする場合などです。後で来て、Common.ClassBと呼ばれる別のタイプを追加し、新しく追加されたCommon.ClassBタイプでCommonのGACに加えた変更を最初にデプロイせずに、IDEでコードを実行します。

デスクトップの実行可能プロジェクトで参照されているdllを更新した後、同じエラーが発生しました。ここで言及された問題は古い参照に関連していて修正が簡単でしたが、ここでは言及されていないため、他の人の時間を節約できると思いました。

とにかく、私はdll Aを更新し、別の参照されたdllからエラーを取得しました。dllAがdll Bへの参照を持っているここでBと呼びましょう。

dll Bを更新すると、問題が修正されました。

DLLをGAC（グローバルアセンブリキャッシュ）に追加する

Visual Studioコマンドプロンプト=>管理者として実行

gacutil / i "dllファイルパス"

追加されたアセンブリC：\ Windows \ system32 \を確認できます

また、SSISスクリプトタスクで欠落しているdllまたは「ファイルまたはアセンブリをロードできませんでした」を解決します

テストフレームワークとしてMSTestを使用しているVisual Studio 2017でも同様の問題が発生しました。一部（すべてではない）の単体テストを実行しているときにSystem.TypeLoadException例外を受け取りましたが、それらの単体テストはデバッグ時に合格しました。私は最終的には問題を解決する次のことをしました：

1. ソリューションでLocal.testsettingsファイルを開きます
2. 「単体テスト」設定に移動します
3. 「テストディレクトリのアセンブリにロードコンテキストを使用する」のチェックを外します。チェックボックス

これらの手順を実行した後、すべての単体テストは実行時に合格し始めました。

ソリューションでアセンブリの署名を削除した後、私は上記と同じことを経験しました。プロジェクトは構築されません。

プロジェクトの1つが、ビルドプロセスを変更し、署名されていないNugetパッケージに署名しようとするStrongNamer NuGetパッケージを参照していることがわかりました。

StrongNamerパッケージを削除した後、アセンブリに署名したり、厳密な名前を付けたりせずにプロジェクトを再度ビルドできました。

コマンドプロンプトを使用してiisresetコマンドを実行することで、これを解決しました...このようなエラーが発生した場合は、常に最初に実行します。