web-dev-qa-db-ja.com

見つかった議会のマニフェスト定義が議会の参照と一致しません

C＃Windowsフォームアプリケーション（Visual Studio 2005）でいくつかの単体テストを実行しようとしていますが、次のようなエラーが表示されます。

System.IO.FileLoadException：ファイルまたはアセンブリ 'Utility、バージョン= 1.2.0.200、カルチャ=ニュートラル、PublicKeyToken = 764d581291d764f7'、またはその依存関係の1つをロードできませんでした。見つかった議会のマニフェスト定義が議会の参照と一致しません。 （HRESULTからの例外：0x80131040）**

x.Foo.FooGO（）で

foo.csのx.Foo.Foo2（String groupName_）：123行

fooTests.csのx.Foo.UnitTests.FooTests.TestFoo（）：98行目**

System.IO.FileLoadException：ファイルまたはアセンブリ 'Utility、バージョン= 1.2.0.203、カルチャ=ニュートラル、PublicKeyToken = 764d581291d764f7'、またはその依存関係の1つをロードできませんでした。見つかった議会のマニフェスト定義が議会の参照と一致しません。 （HRESULTからの例外：0x80131040）

私は自分の参照を調べ、私はUtility version 1.2.0.203への参照しか持っていません（もう片方は古いです）。

このDLLファイルのこの古いバージョンを参照しようとしているものを見つけ出す方法について何か提案はありますか？

その上、私は自分のハードドライブにこの古いアセンブリさえ持っているとは思わない。この古いバージョンのアセンブリを検索するためのツールはありますか？

c#referencecompiler-errorsdependenciesversion
671
leora

.NETアセンブリローダーは1.2.0.203を見つけることができませんが、1.2.0.200を見つけました。このアセンブリは要求されたものと一致しないため、このエラーが発生します。簡単に言うと、参照されているアセンブリが見つかりません。 GACまたはアプリケーションパスに配置して、正しいアセンブリが見つかることを確認してください。 http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx も参照してください。

425
Lars Truijens

あなたはこの問題を解決するためにいくつかのことをすることができます。まず、Windowsファイル検索を使用して、ハードドライブからアセンブリ（.dll）を検索します。結果の一覧が表示されたら、[表示] - > [詳細の選択]を選択して、[ファイルバージョン]を確認します。これは結果のリストにバージョン番号を表示するので、古いバージョンがどこから来たのかを見ることができます。

また、Larsが言ったように、あなたのGACをチェックして、そこにリストされているバージョンを確かめてください。 このMicrosoftの記事 では、GACで見つかったアセンブリはビルド中にローカルにコピーされないため、すべてのリビルドを行う前に古いバージョンを削除する必要があるかもしれません。 。 （これを行うためのバッチファイルを作成する際の注意点については、この質問に対する の回答 を参照してください）

それでも古いバージョンがどこから来ているのかわからない場合は、Visual Studioに付属のfuslogvw.exeアプリケーションを使用して、バインディングの失敗に関する詳細情報を入手できます。マイクロソフトはこのツール についての情報をここに持っています 。 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogレジストリキーを1に設定してログを有効にする必要があることに注意してください。

88
Seth Petry-Johnson

私は自分自身でこの問題に遭遇したところ、その問題は他の人が遭遇したものとは異なる何かであることがわかりました。

私のメインプロジェクトが参照している2つのDLLがありました：CompanyClasses.dllとCompanyControls.dll。次のようなランタイムエラーが発生しました。

ファイルまたはアセンブリ 'CompanyClasses、バージョン= 1.4.1.0、カルチャ=ニュートラル、PublicKeyToken = 045746ba8544160c'、またはその依存関係の1つをロードできませんでした。見つかった議会のマニフェスト定義が議会の参照と一致しません

問題は、私のシステムには1.4.1というバージョン番号のCompanyClasses.dllファイルが何もないことです。 GACにはなし、アプリフォルダにはありません...どこにもありません。ハードドライブ全体を検索しました。私が持っていたすべてのCompanyClasses.dllファイルは1.4.2でした。

本当の問題は、CompanyControls.dllがCompanyClasses.dllのバージョン1.4.1を参照していることです。 （CompanyClasses.dll 1.4.2を参照した後で）CompanyControls.dllを再コンパイルしたところ、このエラーが解決しました。

54
Nathan Bedford

以下は、アセンブリのバージョンをバージョン3.1.0.0にリダイレクトします。 App.configで常にこの参照を更新するスクリプトがあるので、この問題に対処する必要はありません。

リフレクションを介して、アセンブリpublicKeyTokenを取得し、.dllファイル自体からこのブロックを生成できます。

<assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

XML名前空間属性（xmlns）がないと、これは機能しません。

50
Yaniv.H

Visual Studioを使用している場合は、 "clean solution"を試してからプロジェクトを再ビルドしてください。

38
Tad

他の答えは私にはうまくいかないでしょう。バージョンを気にせず、単にアプリケーションを実行したい場合は、参照を右クリックして「特定のバージョン」をfalseに設定してください。 enter image description here

30
RayLoveless

私はこの問題に遭遇したばかりで、問題は私のアプリケーションのデバッグディレクトリに.dllの古いコピーがあることでした。あなたがそれを見るかどうか見るために（GACの代わりに）そこもチェックしたいかもしれません。

21
Neal Tibrewala

私はNuGetパッケージを追加しましたが、私のアプリケーションのブラックボックス部分が古いバージョンのライブラリを参照していることだけを認識していました。

パッケージを削除し、古いバージョンの静的DLLファイルを参照しましたが、web.configファイルが次の場所から更新されることはありませんでした。

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

パッケージをアンインストールしたときの状態に戻ります。

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>
20
frattaro

私の場合、このエラーはASP.NETアプリケーションの実行中に発生しました。解決策は以下のとおりです。

  1. プロジェクトフォルダ内のobjおよびbinフォルダを削除します。

クリーンはうまくいきませんでした。それらのディレクトリを削除した後、すべてが完璧に機能しました。

15
Levi Fuller

私の場合は、C：\ WINDOWS\Microsoft.NET\Framework \〜\ Temporary ASP.NET Files \ディレクトリにあるDLLの古いバージョンでした。古いバージョンを削除または置き換えることも、プロジェクト内のDLLへの参照を削除して追加することもできます。基本的に、どちらの方法でも一時ASP.NETファイルへの新しいポインタが作成されます。

14
Glade Mellor

私は今、みんなの心を打つつもりです。 。 。

.configファイルからすべての<assemblyBinding>参照を削除してから、NuGet Package Managerコンソールからこのコマンドを実行します。

Get-Project -All | Add-BindingRedirect
11
codeMonkey

私たちにとって、問題は他の何かが原因でした。 DevExpressコンポーネントのライセンスファイルには2行が含まれていました。1行は、この特定のコンピュータにインストールされていなかった古いバージョンのコンポーネント用です。ライセンスファイルから古いバージョンを削除することで問題は解決しました。

厄介な部分は、エラーメッセージがどの参照が問題を引き起こしていたかについての指示を与えなかったということです。

8
Sire

私の物はNathan Bedfordによる記事と非常によく似た状況でしたが、少しねじれていました。私のプロジェクトも2つの方法で変更されたDLLを参照しました。 1）直接および2）それ自身が変更されたDLLへの参照を持っていたコンポーネント（クラスライブラリ）を参照することによって間接的に。今度は私のコンポーネント（2）のためのVisual Studioプロジェクトは変更されたdllの正しいバージョンを参照しました。ただし、コンポーネント自体のバージョン番号は変更されていません。そして結果として、プロジェクトの新しいバージョンのインストールは、クライアントマシン上のそのコンポーネントを置き換えることができませんでした。

最終結果：直接参照（1）と間接参照（2）は、クライアントマシンで変更されたDLLの異なるバージョンを参照していました。私の開発者のマシンではうまくいきました。

解決策：アプリケーションを削除してください。アプリケーションフォルダからすべてのDLLを削除します。私の場合はその通りです。

5
Bijimon

リフレクションを使用して遅延バインドする場合、バインド先のアセンブリに厳密な名前が付けられている場合、またはその公開鍵トークンが変更されている場合は、まったく同じエラーがスローされます。指定された公開鍵トークンを持つアセンブリが実際に見つからない場合でも、エラーは同じです。

エラーを解決するには、正しい公開鍵トークンを追加する必要があります（dllのsn -Tを使用して取得できます）。お役に立てれば。

5
Guy Starbuck

私は基本的なASP.NET MVC 4プロジェクトを作成していて、NuGet経由でDotNetOpenAuth.AspNetを追加したことを付け加えたいと思います。 Microsoft.Web.WebPages.OAuthの不一致のDLLファイルを参照した後も、これと同じエラーが発生しました。

それを直すために私はUpdate-Packageをしてそして完全な再構築のために解決策をきれいにしました。

それは私のために働いたし、ちょっと怠惰な方法ですが、時は金なりです:-P

4
Ben Pretorius

私の問題は、参照されているアセンブリを引っ張らずに、ソースコードを新しいマシンにコピーすることでした。

エラーを修正したことは何もないので、急いで、BINディレクトリを完全に削除しました。私のソースコードを再構築し、そしてそれはそれ以来うまくいきました。

4
AEON Blue Software

私は誰かが私の愚かさから恩恵を受けるでしょう。私は完全に別のアプリケーションに依存しています（これをApp1と呼びましょう）。そのApp1からのdllは私の新しいアプリケーション（App2）に取り込まれます。私がAPP1で更新をする時はいつでも、私は新しいdllを作成しそしてそれらをApp2にコピーしなければなりません。そうですね。 。 2つの異なるApp1バージョン間でのコピーと貼り付けにうんざりしたので、dllに 'NEW_'という接頭辞を追加しました。

そうですね。 。 。私は、ビルドプロセスが/ binフォルダーをスキャンし、それが何かを誤って一致させたときに、上記と同じエラーメッセージを表示していると推測しています。私は "new_"バージョンを削除しました、そしてそれはただダンディを構築しました。

4
Mike Murphy

Team Foundation Serverのビルドサービスを構築しているときにこのエラーが発生しました。 NuGetで追加された同じライブラリの異なるバージョンを使用したソリューションに複数のプロジェクトがあることがわかりました。私はNuGetを使って古いバージョンをすべて削除し、新しいバージョンをすべての参照として追加しました。

Team Foundation Serverは、すべてのDLLファイルを1つのディレクトリに入れます。もちろん、特定の名前のDLLファイルは1つだけです。

4
cederlof

私のapp.configには

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

npgsqlの場合どういうわけか、ユーザーのマシン上で、私のapp.exe.configが見つからない行きました。私はそれが愚かなユーザー、インストーラーの不具合、あるいはまだウイルス対策ソフトであるかどうかわからない。ファイルを置き換えることで問題は解決しました。

4
Thomas

私はちょうどこのエラーを取得する別の理由を見つけました。特定のライブラリのすべてのバージョンからGACをクリーンアップし、実行可能ファイルと一緒に展開された特定のバージョンを参照してプロジェクトを構築しました。プロジェクトを実行すると、この例外が発生し、新しいバージョンのライブラリが検索されました。

その理由は、 媒体社のポリシー です。 GACからライブラリのバージョンをアンインストールしたときに、ローカルに配置されたアセンブリを使用する代わりに、発行者ポリシーアセンブリもアンインストールするのを忘れていました。アセンブリローダーがGACで新しいバージョンを検索するように指示しました。

3
Ladislav Mrnka

私にとっては、 "Local.testtesttings"ファイルのコードカバレッジ設定が問題を引き起こしていました。そこで参照されていたファイルを更新するのを忘れました。

3
uli78

プロジェクトのbinフォルダの内容を削除してソリューションを再構築するだけで、私の問題は解決しました。

2
dhiraj1mumbai

解決策をきれいにして再構築しても、出力ディレクトリのすべてのdllが置き換えられるわけではありません。

私が提案するのは "bin"から "oldbin"へ、または "obj"から "oldobj"へフォルダの名前を変更してみることです。

それからもう一度あなたのsilutionを構築してみてください。

もしあなたがサードパーティ製のdllを使っているのなら、ビルドが成功した後に新しく作られた "bin"や "obj"フォルダにコピーする必要があるでしょう。

これがあなたのために働くことを願っています。

2
Ganesh Londhe

フォルダの場所から古いアセンブリを手動で削除してから、新しいアセンブリへの参照を追加すると解決する場合があります。

1
rjain

私の場合、問題は椅子とキーボードの間にありました:-)

Could not load file or Assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located Assembly's manifest definition does not match the Assembly reference.
(Exception from HRESULT: 0x80131040)

2つ以上の異なるアセンブリが異なるバージョンのDotNetOpenAuthライブラリを使用することを望んでいたので、それは問題になりません。さらに、私のローカルコンピュータでは、web.configはNuGetによって自動的に更新されました。

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

それから私は私がプロダクションサーバに新しいweb.configをコピー/デプロイするのを忘れていたことに気づきました。 web.configを手動でデプロイする方法がある場合は、それが更新されていることを確認してください。本番サーバー用にまったく異なるweb.configがある場合は、NuGetを使用した後にこれらのdependentAssemblyセクションを同期させてマージする必要があります。

1
Tomas Kubes

「見つかったアセンブリのマニフェスト定義がアセンブリ参照と一致しない」というエラーが表示された場合、および「プロジェクト」>「NuGetパッケージの管理と更新」で更新した場合VSのタブで、最初にできることは、 NuGet Galleryページ からバージョンをチェックして実行した後に、別のバージョンのパッケージをインストールしてみることです。 Package Managerコンソールから次のコマンドを入力します。

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

答えは問題のパッケージに直接関連しているわけではなく、戻ってきた方法ですが、一般的なものであり、関連性があり、誰かに役立つことを願っています。

1
Jaggan_j

私は同じエラーを得ました...私の場合、それは以下のように解決されました：

  • 最初にアプリケーションがインストールされたときに、ここの人々はアプリケーションでMicrosoft Enterprise Library 4.1を使用していました。
  • 先週、私のマシンはフォーマットされていましたが、今日そのアプリケーションをビルドしたときには、Enterprise Library Assemblyが見つからないというエラーが表示されました。
  • それから私は最初の検索エントリとしてグーグルに乗ったMicrosoft Enterprise Library 5.0をインストールしました。
  • それから私がアプリケーションを構築したとき、それはそれから私に上記のエラーを与えましたすなわち見つけられたアセンブリのマニフェスト定義はアセンブリ参照と一致しません。
  • 多くの検索作業と分析の後、アプリケーションが4.1.0.0を参照していたこと、そしてbinフォルダー内のDLLはバージョン5.0.0.0であることがわかりました
  • その後、Microsoft Enterprise Library 4.1をインストールしました。
  • 以前の参照（5.0）を削除し、4.0の参照を追加しました。
  • アプリケーションを構築し、出来上がりました...それはうまくいきました。
1
user4846550

これは私がこの問題を解決する方法です。

  1. 例外メッセージから、 "問題のある"ライブラリの名前と "予想される"バージョン番号を取得します。

enter image description here

  1. ソリューション内でその.dllのall copiesを見つけて右クリックし、その.dllのバージョンを確認します。

enter image description here

さて、この例では、私の.dllは間違いなく2.0.5022.0です（だから例外のバージョン番号は間違っています）。

  1. ソリューション内のすべての.csprojファイルで、例外メッセージに表示されたバージョン番号を検索してください。このバージョン番号をdllの実際の番号に置き換えます。

したがって、この例では、これを置き換えます。

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... これとともに...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

仕事は終わった！

1
Mike Gledhill

私のユニットテストケースを実行している間、私は同じ問題に直面しました。

このエラーは、アセンブリをロードしようとすると、.NETアセンブリローダが、そのマニフェストデータ（アセンブリ名、公開キートークン、バージョンと呼ばれる）に基づいてその参照アセンブリをロードしようとしていることを明確に示しています。

マニフェストデータを確認するには

  1. Visual Studioのコマンドプロンプトを開きます。
  2. 'ildasm'と入力して必要なアセンブリをILDASMウィンドウにドラッグし、MANIFESTビューを開きます。 MANIFESTには、旧バージョンと新バージョンの2つのバージョンを持つ1つのアセンブリが含まれることがあります（Utility, Version=1.2.0.200およびUtility, Version=1.2.0.203など）。実際には、参照されるアセンブリはUtility, Version=1.2.0.203(new version)ですが、マニフェストにはUtility, Version=1.2.0.200(old version)も含まれているため、.NETアセンブリローダーはこのバージョン管理されたDLLファイルを見つけようとし、見つけられず例外をスローします。

これを解決するには、各プロジェクト依存アセンブリを個別にILDASMウィンドウにドラッグし、どの依存アセンブリが古いアセンブリバージョンのマニフェストデータを保持しているかを確認します。この依存アセンブリを再構築してプロジェクトに参照してください。

0
shan

私は今日同じ問題を抱えていたため、Entity Frameworkに変更を加えた後は追加移行を実行できませんでした。

私のソリューションには2つのプロジェクトがありました。それらを「クライアント」と「データ」と呼びましょう - 私のEFモデルとコンテキストを保持するクラスライブラリプロジェクトです。クライアントはデータプロジェクトを参照しました。

私は両方のプロジェクトに署名し、その後EFモデルに変更を加えました。署名を削除した後、私は移行を追加することができました、そしてそれから、再びプロジェクトに署名することができました。

私はこれが長期の欲求不満からそれらを節約して、誰かに役立つことを願っています..

0
Thomas Fauskanger

私と一緒に問題は、新しいビルドで削除された古いdllのdployedがあったということでした。それを修正するために、私はちょうど公開時に宛先で追加のファイルを削除するためにボックスをチェックしました。 保存先で追加のファイルを削除します

0
Bellatorius

私が構築していたアセンブリと同じ名前のアセンブリを参照しているため、このエラーメッセージが表示されました。

これはコンパイルされましたが、参照されているアセンブリを現在のプロジェクトのアセンブリで上書きしたため、エラーが発生しました。

これを修正するために、プロジェクトの名前を変更し、プロジェクトを右クリックして[プロパティ]を選択してアセンブリのプロパティを表示しました。

0
dan

InstallShieldを使用し始めた後、私はこの問題を抱えていました。ビルド順序はインストールプロジェクトが最後であることを示していましたが、それは順不同で構築されていました。

他のすべてのプロジェクトをそれに依存させることによってこれを修正しました - これはインストールを最後に構築することを強制し、それによって私のアセンブリの不一致を取り除きました。これが役に立つことを願っています。

0
Tim

これと同じエラーが私のUnit Testsプロジェクトで浮上していて、テストに失敗することがありました。私はAssembly ExplorerでどのバージョンのAssemblyを使用しているかをダブルチェックし、runtime/dependent assemblyアセンブリタグの内容を確認したところ、使用していたAssemblyの異なるバージョンがまだ参照されていることがわかりました。これが私のテストプロジェクトapp.configの唯一のディレクティブだったので、私はちょうど全体のapp.configファイルを削除してソリューションを再構築しようとしました、そしてそれはトリックをしました！私のためのこれ以上の参照エラー:)

0
Ryan

解決策はありませんでした。クリーンなプロジェクトソリューションを試し、ビンを削除し、パッケージを更新し、パッケージをダウングレードするなど... 2時間後、アセンブリを使用してプロジェクトからデフォルトのApp.configを読み込み、そこから間違った参照バージョンを変更しました。

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

に：

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

この後、プロジェクトをクリーンアップし、再度ビルドし、動作しました。警告は問題ありません。

0
Mi1anovic

OK、もう一つ答え。以前にアプリを64ビットとして作成し、それに応じて出力パス（プロジェクト/プロパティ/ビルド/出力/出力パス）を変更しました。最近、アプリを32ビット（x86）に変更し、新しい出力パスを作成しました。私は、コンパイルされた.exeが行くthoughtへのショートカットを作成しました。ソースについて何を変更しても、マニフェストが一致しないというエラーが発生しました。約1時間のフラストレーションの後、たまたま.exeファイルの日付/時刻を確認しましたが、明らかに古い.dllを参照していることがわかりました。 アプリを古いディレクトリにコンパイルし、ショートカットは新しいディレクトリを参照していました。出力パスを.exeshouldが行く場所に変更し、ショートカットとエラーはなくなりました。 （額をたたく）

0
OldDog

私は得ていました：

ファイルまたはアセンブリ 'XXX-new'またはその依存関係の1つをロードできませんでした。見つかった議会のマニフェスト定義が議会の参照と一致しません。 （HRESULTからの例外：0x80131040）

アセンブリの名前をXXX.dllからXXX-new.dllに変更したからです。元の名前に戻すとエラーが修正されました。

0
mimo

プロジェクトのプロパティでlicenses.licxを確認してください。そこに間違ったバージョンがあることがわかります。

0
Marzie Keshavarz

AssemblyInfo.csファイルのAssemblyVersionで、*を指定する代わりに固定バージョン番号を使用してください。 *はコンパイルごとにバージョン番号を変更します。私の場合、それがこの例外の問題でした。

0
DevXP

この質問にはすでに答えがありますが、同じソリューション内の異なるバージョンのNuGetパッケージで問題が発生した場合は、次のことを試すことができます。

あなたが私のサービスプロジェクトのバージョンが他のものと違うのを見るので、NuGet Package Managerを開いてください。

それからあなたのパッケージの古いバージョンを含むプロジェクトを更新してください。

Enter image description here

0
erhan355

Visual Studioの「詳細」をお読みください。詳細については、私のプロジェクトの1つ（メインプロジェクトを参照していたものが、Microsoft.IdentityModel.Clients.ActiveDirectoryの異なるバージョンを持っていること）を教えてくれました。私の場合、ユニットテストプロジェクトは私のプロジェクトを呼び出していました。ユニットテストプロジェクトとプロジェクトには、Microsoft.IdentityModel.Clients.ActiveDirectoryの異なるバージョンがあります。単体テストの実行中に実行時エラーが発生します。

ユニットテストプロジェクトのバージョンを、メインプロジェクトの同じバージョンに更新しました。それは私のために働いた。

0
Vikrant

私のウェブサイトの一つのDLLファイルを更新しようとしたとき私は同様の問題を抱えていました。

このDLLファイルをFTP経由でbinフォルダにコピーしたときに、このエラーが発生していました。

私はこの問題を解決しました：

  1. webサイトを停止します。
  2. 必要なDLLファイル/ DLLファイルのコピー。
  3. ウェブサイトを始める
0
magicmanam

この記事で同様の問題が言及されていました。「このDLLファイルの古いバージョンを参照しようとしているものを見つけ出す方法についての提案はありますか。」

どのアセンブリがまだ古いODATAクライアント6.15.0を参照している必要があったので、ildasmは私のために絞り込むのに役立ちました（基本コードへのアクセスなしで、サーバーにデプロイされたpkgを通してのみ）。

下のスクリーンショットは簡単な要約です。

Ildasm.exeがない場合はDeveloperPackge https://www.Microsoft.com/net/download/visual-studio-sdks

ildasm usage to resolve Assembly mismatch issue

0
Nara

AssemblyInfo.csとAssemblyVersionタグの両方を使用していて、.csprojファイルの値が異なる場合にも、これが発生する可能性があります。 AssemblyInfoを一致させるか、セクションをすべて削除することで、問題は解決します。

0
netniV

System.ValueTupleのために私に起こった

予期しないエラーファイルまたはアセンブリ 'System.ValueTuple、バージョン= 4.0.1.0、カルチャ=ニュートラル、PublicKeyToken = cc7b13ffcd2ddd51'、またはその依存関係の1つをロードできませんでした。システムは、指定されたファイルを見つけることができません。

エラーが発生したマシンに.NET Framework 4.7.2 Runtimeをインストールすることで解決しました。シンプルでbindingRedirectを追加する必要がない、GACを変更する、またはNuGetパッケージをダウングレードするなど.

https://dotnet.Microsoft.com/download/dotnet-framework/net472

0
Ogglas

内部パッケージリポジトリを使用しているときにこの問題に遭遇しました。メインパッケージを内部リポジトリに追加しましたが、パッケージの依存関係は追加しませんでした。あなたの内部リポジトリにも、すべての依存関係、依存関係の依存関係、再帰的なものなどを必ず追加してください。

0
ScubaSteve