エラー「メタデータファイル '... \ Release \ project.dll'がVisual Studioで見つかりませんでした」
最近、私はこのメッセージをランダムに取得し始めました：
メタデータファイル '...\Release\project.dll'がVisual Studioで見つかりませんでした
いくつかのプロジェクトを含むソリューションがあります。現在のビルドモードはデバッグで、すべてのプロジェクトの構成はデバッグに設定されています。しかし、メインプロジェクトを実行しようとすると-いくつかのエラーが発生することがありますが、そのすべてが「メタデータファイル '...\Release\projectX.dll'が見つかりませんでした」-そして、見て、リリースについて現在のモードはデバッグですが、フォルダ。どうして？すべてのソリューションファイル内で「Release\projectX.dll」への参照を検索しようとしましたが、ResolveAssemblyReference.cacheファイルで1つ見つかりました。
インターネットでよく検索して、同様の問題を抱えている人を数人見つけましたが、解決策はありませんでした。少なくとも実用的な解決策はありませんでした。
それらのプロジェクトへの参照を削除して読み込もうとしましたが、しばらくしてから再びこれらのエラーが発生し始めました。
バグのようです。常にデバッグモードを使用すると、リリースフォルダーで参照プロジェクトが検索されるのはなぜですか？
PS。この問題に遭遇した人のために：簡単な方法で解決できませんでした。 Windowsを再インストールした後にのみ消えました:(
誰もが正しい...すべてを試してみてください...（少しの時間から多くの時間の無駄に）
- 悪いコードはありますか？最初に修正してください。
- クリーンソリューションとVisual Studioの再起動
- 参照の削除/追加
- 大規模なプロジェクトでビルド順序を確認し、検証します
- サブプロジェクトを手動で再構築する
- プロジェクト間でDLLを関連付けられたbinフォルダーに手動でコピーする
- コーヒーを飲みに行き、ピンボールをして明日戻ってきてください...その間、何か他のことを考えるかもしれません。
私はまったく同じ問題を抱えていました。 50以上のプロジェクトを備えた大きなビジュアルスタジオソリューション。
すべての参照はプロジェクトとして追加されました。プロジェクトのビルド順序は正しいです（プロジェクトを右クリックしてビルド順序を選択します）。
ただし、いくつかの上位レベルのプロジェクトをビルドするときに、それらが依存する「ルート」プロジェクトはビルドされませんでした。
問題は、これらのプロジェクトが現在の構成でビルドするように選択されていないことでした（これがどのように発生したかわかりません）。
これを確認するには、[構成マネージャー]（ビルドメニュー）を選択し、問題のあるプロジェクトがビルドに設定されているかどうかを確認します。
それらのプロジェクトへの参照を削除して再度追加したと言うとき、正確にどのように追加しましたか？ Visual Studioの[参照の追加]ダイアログの[参照]タブを使用しましたか？または、「プロジェクト」タブ（ソリューション内の隣接プロジェクトを一覧表示）を使用しましたか？
編集：[参照]タブを使用して、/ Releaseフォルダーにある.dllへの参照を手動で追加すると、Visual Studioは常にその場所で.dllを探します。現在のモード（デバッグまたはリリース）に関係なく。
（手動または「Clean Solution」を実行して）Releaseフォルダから実際の.dllファイルを削除した場合、.dllが存在しないため、参照が破損します。
ProjectX.dllへの参照を削除して再度追加することをお勧めしますが、今回は[参照の追加]ダイアログの[プロジェクト]タブを使用します。この方法で参照を追加すると、Visual Studioは適切な.dllを取得する場所を認識します。デバッグモードの場合は、/ Debugフォルダーから取得します。リリースモードの場合は、/ Releaseフォルダー。ビルドエラーはなくなり、デバッグモードでリリース.dllを（不適切に）参照することもなくなります。
まあ、私の答えはすべてのソリューションの要約だけでなく、それ以上のものを提供しています。
セクション（1）：
一般的な解決策では：
この種のエラー（「メタデータファイルが見つかりませんでした」）が4つあり、「ソースファイルを開けませんでした（「不特定のエラー」）」という1つのエラーがありました。
「メタデータファイルが見つかりませんでした」というエラーを取り除きました。そのために、私は多くの投稿、ブログなどを読んで、これらのソリューションが効果的であるかもしれないことを見つけました（ここでそれらを要約します）：
VSを再起動して、もう一度ビルドしてみてください。
'Solution Explorer'に移動します。ソリューションを右クリックします。 プロパティに移動します。 'Configuration Manager'に移動します。 'Build'の下のチェックボックスがチェックされているかどうかを確認します。それらのいずれかまたはすべてのチェックが外されている場合は、それらをチェックして、再度ビルドを試みます。
上記の解決策が機能しない場合は、上記の手順2で説明した手順に従います。すべてのチェックボックスがオンになっている場合でも、チェックを外し、もう一度チェックしてからビルドを再試行します。
ビルド順序とプロジェクトの依存関係：
'Solution Explorer'に移動します。ソリューションを右クリックします。 'Project Dependencies ...'に移動します。 2つのタブが表示されます： 'Dependencies'および 'Build Order' 。このビルド順序は、ソリューションがビルドされる順序です。プロジェクトの依存関係とビルド順序を確認して、他のプロジェクト（たとえば 'project2'）に依存しているプロジェクト（たとえば 'project1'）がそのプロジェクト（project2）の前にビルドしようとしていることを確認します。これがエラーの原因である可能性があります。
不足している.dllのパスを確認してください：
不足している.dllのパスを確認します。パスにスペースまたはその他の無効なパス文字が含まれている場合は、それを削除して、もう一度ビルドしてみてください。
これが原因である場合は、ビルド順序を調整してください。
セクション（2）：
私の特定のケース：
VSを数回再起動して、さまざまな組み合わせと組み合わせで上記のすべての手順を試しました。しかし、それは私を助けませんでした。
そこで、私が遭遇した他のエラー（「ソースファイルを開くことができませんでした（「不特定のエラー」））を取り除くことにしました。
私はブログに出くわしました： http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539
私はそのブログで言及されている手順を試しましたが、エラーを取り除きました「ソースファイルを開けませんでした（「不特定のエラー」）」他のエラー（「メタデータファイルが見つかりませんでした」）も取り除きました。
セクション（3）：
ストーリーのモラル：
エラーを取り除くために、上記のセクション（1）に記載されているすべてのソリューション（およびその他のソリューション）を試してください。上記のセクション（2）で述べたブログのように何も解決しない場合、ソース管理に存在しないすべてのソースファイルのエントリを削除し、 .csprojファイルのファイルシステム。
私は以前にこの問題を抱えていましたが、それを解決する唯一の方法は、Clean Solutionを実行してからVisual Studioを再起動することです。
私にとっては、通常はターゲットフレームワークがオフになっています（4.6ではなく4.5.2）ソリューションのターゲットフレームワークに合わせてプロジェクトのターゲットフレームワークを修正してビルドすると、新しい.dllが作成されます。
Visual Studioを管理者として再度開きます。
ほとんどの回答者は、ソリューションのライブラリを削除する必要があると言っていますが、これは事実ですが、ライブラリを再度追加するとエラーが再び表示されます。 参照されているすべてのライブラリに、ソリューションの.netフレームワークと互換性のある.netフレームワークがあるかどうかを確認する必要があります。次に、コード内のすべてのエラーを修正し、ソリューションを再構築します。
構成マネージャーの設定を確認しましたか？プロジェクト設定ダイアログの右上隅。
すべてのリリースエントリの間にデバッグエントリが入ることがあります。その場合、ソリューションの依存関係グラフによって作成された自動依存関係がすべて混乱します。
私自身も同じ問題を抱えていました。
Visual Studio 2013は、それを参照できず、メタデータを見つけることができないとだけ言った。ソリューション（複数のプロジェクトを含む）を開いたとき、プロジェクトのフレームワークバージョンよりも低いプロジェクトを使用していると言われました。
だから、私はすべてをバージョン4.5に切り替えて、再び機能した。
この問題は非常に頻繁に発生しますが、C＃プロジェクトからC++/CLIプロジェクトへの参照のみがあります。 Microsoftが修正しなかったのは明らかにVisual Studioの奥深くにあるバグです。これは「複雑すぎる」ため、Visual Studio 2010をターゲットとするC++ビルドシステムのオーバーホールを約束したためです。
それは少し前のことであり、たぶん修正はVisual Studio into2008でも行われました。もうフォローアップしませんでした。ただし、一般的な回避策は
- スイッチ構成
- Visual Studioを再起動します
- ソリューションを構築する
この問題は、pdbファイルまたはCodeContractsが原因です。
解決するには：
出力フォルダーをクリーンアップし、ソリューションを再構築します。
CodeContractsを再構成するか、一時ビルド用に無効にします。
私はこの問題を抱えていて、それを理解するのに長い時間がかかりました。ソリューションからプロジェクトを削除し、nugetパッケージに置き換えたときに問題が発生しました。
解決策は問題ないように見えましたが、.csprojファイルには参照としてこれらのプロジェクトが複数回含まれています。
VSはそのファイルを適切にクリーニングしないようです。削除されたプロジェクトを内部で参照していました。 csprojファイルから参照を手動で削除すると、すべてが再び機能します！わー
私の場合、コードにいくつかのエラーがありました。 Visual Studioは、構文エラーや不明なクラス名など、実際のエラーの代わりに発生したエラーを表示しました。プロジェクトの後にソリューションのクリーニングとプロジェクトの構築を試してください。これにより、実際のエラーを発見できます。
繰り返しますが、これがmeのエラーの原因です。
私の場合は、2つのことが原因でした（VS.2012）。
1）プロジェクトの1つがx86ではなくAnyCPU用に構成されました
2）参照されたプロジェクトは、何らかの形で「ビルド」チェックボックスがオフになっています。
ビルドを確認してください|構成マネージャーは、構築されているものとプラットフォームの概要を取得します。また、デバッグとリリースの設定が異なる可能性があるため、必ずデバッグとリリースの両方を確認してください。
最近、Office 2007からOffice 2010にアップグレードした後にこの問題に遭遇しました。プロジェクトの参照を一部のプロジェクトで使用するOffice Interopsのバージョン14に手動で変更する必要がありました。
それが役に立てば幸いです-それを理解するのに数日かかりました。
また、複数のプロジェクトがあるソリューション（通常、4.0フレームワークをターゲットとするために1つ以上のサブプロジェクトを更新したnetTiersプロジェクト）でこのエラーを見ました。削除するのに問題がある場合があります。ただし、多くの場合、最初にサブプロジェクトの他のすべてのエラー（不足している参照など）を修正し、それらのサブプロジェクトを個別に再構築してから、Visual Studioでそれらのサブプロジェクトへの参照を削除/追加することで解決できます。個人的には、ソリューションだけをクリーニングしてこのエラーを解決することはほとんどできませんでした。
参照を削除することになりました（プロジェクトタブを使用して適切に追加し、以前はうまく構築されていました）。csprojファイルを手作業で編集し、属していなかった奇妙なエントリを削除し、出力をデバッグ用に設定し、リリース、x86とx64、およびすべてのCPUをすべて「\ bin」にします-一度構築してから、（プロジェクトタブを使用して）参照を再度追加すると、すべてが再び動作し始めました。 Visual Studioを再起動する必要はまったくありませんでした。
数ヶ月前に同様の問題があったことを思い出すようです。参照されたDLLをReleaseフォルダーにコピーすることで一時的に解決し、Visual Studioの期待に応えました。後で、実際のコードでRelease DLLへの参照を発見しました。\release\project.dllのプロジェクト全体を検索してみてください。
また、Visual Studioの単体テストプロジェクトでは、ターゲットDLLを指す各テストメソッドに「DeploymentItem」属性が設定されることがあり、デバッグとリリースを切り替えると、DLLは、予想される場所にありません。私の経験では、これらの属性は、「単一展開」シナリオの一部として自分で配置しなかった場合、安全に削除できます。
私にとってこれは、dllを出力しないように書き換えられたビルドターゲットが原因でした。これを削除してデフォルトのビルドターゲットにフォールバックすると、問題が修正されました。
時々、VS2010は私のCPUから任意のCPUから混合プラットフォームに構成を切り替えます。これが発生すると、このエラーメッセージが表示されます。
それを解決するには、任意のCPUに切り替えます。
1。ソリューションを右クリックして、プロパティを選択します。
2。 [構成プロパティ]をクリックし、[構成マネージャー...]ボタンをクリックします。
3。 [アクティブソリューションプラットフォーム]で[任意のCPU]を選択します
これは通常、クラスが実装するインターフェイスにメソッド宣言がある場合に発生しますが、後で削除し、インターフェイスからも削除するのを忘れていました。私は通常、30分ごとにソリューション全体を保存し、エラーが見つからない場合は以前のバージョンに戻します。
私はこの問題を抱えていましたが、それは値を返さない問題のあるライブラリ（dll）の無効なメソッドが原因でした.
public bool DoSomething()
{
//I never bothered putting code here....
}
私がこれをコメントアウトすると、すべてがコンパイルされました:)
プロジェクト参照を追加しようとしたときにこの問題が発生し、上記の多くのことを検索して試行した後、ビルド構成と出力が正しくなりました。
最後に、ソースおよび参照プロジェクトから\ binおよび\ objフォルダーを削除しました。
正直に言って、それはobjフォルダーに正しいメタデータまたは破損したメタデータが含まれていなかったと思います。
すべてが修正されました。
これは、Visual Studio 2015-.NET 4.6プロジェクトで行われました。
更新：
上記は最初のビルドで機能しましたが、その後のビルドでは失敗したため、ソリューションファイルを再作成し、プロジェクトファイルで誤って参照されたNuGetパッケージを削除して読み取り、誤ったヒントパスを指していました。
これまでのビルドでは、これで修正されたようです。
.csprojファイル内のサンプル参照
<ItemGroup>
<Reference Include="Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll</HintPath>
</Reference>
</ItemGroup>
今日も同じ問題がありました。
私のアプリケーションであるWindows Formsアプリケーションは、誤って自分自身への参照を持っていました。奇妙な。
削除すると、エラーはなくなりました。
Windows Formsプロジェクト自体にあるユーザーコントロールをフォームにドラッグするたびに、参照が追加されました。
〜30番目の回答:-)
VS2015の場合：
- ソリューションを右クリック
- プロジェクトのビルド順序を選択
- Project Build Orderのプロジェクトのリストを見てください
- 各プロジェクトをこの順序でビルドします
- 出力を検査する
私の場合、ステップバイステップでそれを行うことで、これらのエラーがすべて左右に投げ出されることなく、私の問題が何であるかを発見することができました。
知っておく必要がある場合は、プロジェクトが.NET 4.5.2用に設定されたときに、NuGetを介してEntity Framework（EF）6.1.3を追加しました。後で.NET Frameworkを4にダウングレードすると、エラーはより明白になりました。 NuGetを使用して、EFをアンインストールし、再度追加しました。
プロジェクトのパスを確認してください。カンマやスペースなどの不規則な文字は使用しないでください
たとえば、これは間違ったパスです：d：\ my applications\Project1
これは真のパスd：\ my_applications\Project1です
Visual Studioは、ディスク内のパスにアルファベットと数字以外の文字が含まれている場合、プロジェクトをビルドできず、このエラーに対するメッセージは表示されません！
また、一部のインストールツールでは、インストールを開始するときに同じ問題が発生し、抽出できません。
プロジェクトルートの.vsフォルダーが非表示になっているかどうかを確認します。私は別のPCからコピー/貼り付けを行ったので、私はそうではありませんでした（そうすべきです）。それを削除することで問題が解決し、Visual Studio 2015で再作成されました。
私は同じ問題を抱えていましたが、この問題の背後にある理由は、参照プロジェクトのdllファイルが他のプロセスで使用されていることです。私の場合、アプリケーションをデバッグしていて、アプリケーションにVisual Studioデバッガーがアタッチされていました。同じプロジェクトを使用している別のアプリケーションを再構築しているときに、このエラーが発生していました。接続を解除した後、2番目のアプリケーションを正常にビルドできました。
この問題は解決されました。パッケージマネージャーの設定を開き、[NuGetに不足しているパッケージのダウンロードを許可する]をクリックしました。プロジェクトがビルドされます。
私の場合、マージ中に、ソリューションファイルにいくつかのプロジェクト参照が欠けていたようです。プロジェクトをソリューションに手動で再追加すると修正されました。ソリューションファイルを手動で編集することもできますが、注意して、何をしているのかを知る必要があります。
同じ問題がありました。プロジェクトdllにあるdbコンテキスト（EF4）が何らかの理由で認識されないことに気付きました。私はそれを削除し、代わりに別のものを作成しました。そしてそれは私のためにそれを解決しました。
プロジェクトでSQLMETALなどのデータベースコード生成ツールを使用していますか？
その場合、複数化から複数化への移行の問題に直面している可能性があります。
私の場合、古い複数形（*）のテーブル名（SQLMETALはデフォルトで「s」文字を末尾に追加します） SQLMETALによって生成されます。
以来、私は最近無効にした名前の複数化、いくつかのデータベース関連クラスを繰り返した後、それらのいくつかは「s」プレフィックスを失いました。したがって、影響を受けるテーブルクラスへの参照はすべて無効になりました。このため、次のようないくつかのコンパイルエラーがあります。
「xxxx」には「TableNames」の定義が含まれておらず、タイプ「yyyy」の最初の引数を受け入れる拡張メソッド「TableNames」が見つかりませんでした（usingディレクティブまたはアセンブリ参照がありませんか？）
ご存知のように、私はアセンブリのコンパイルを防ぐためにエラーのみを取ります。そして、それは不足しているアセンブリが依存アセンブリにリンク可能であり、元の「メタデータファイル 'XYZ'が見つかりませんでした」
影響を受けたクラステーブルの参照を現在の名前（複数化されていない）に手動で修正した後、プロジェクトを生き返らせることができました！
（*）オプションVisual Studio>Toolsメニュー>Options>Database Tools>O/R Designer>名前の複数化が有効になっている場合、一部のSQLMETALlコードジェネレーターは「s "生成されたいくつかのテーブルクラスの末尾の文字。ただし、テーブルにはターゲットデータベース上に" s "サフィックスがありません。詳細については、 http://msdn.Microsoft.com/en-us/library/bb386987（v = vs.110）.aspx を参照してください。
この投稿には多くの良いアドバイスがあります。もう1つ追加しました。
私は同じ問題を抱えていましたが、提供された答えのどれもそれを前に修正しませんでした。明らかに、これは.csprojファイルの問題である可能性があります。何らかの理由で、コードのどこにも作成されていないファイルへの参照は、まだ「欠落」していました。
テキストエディタで.csprojファイルを開き、不足しているファイルを探し、削除し、保存し、満足します。
今日もこの問題がありました。私の原因は循環依存です。プロジェクトAはプロジェクトBを参照し、その逆も同様です。
同じ問題がありました。 dllを手動で削除および追加しても解決しませんでした。 ClassLibrariesはすべてのプロジェクトに対してコンパイルされず、プロジェクトの...\bin\Debugフォルダーにありませんでした（誤ってソリューションを削除したため）。 クラスライブラリがコンパイルされなかったため、これらのサブプロジェクトのどこかにエラーがある可能性があることを意味します。
解決策： dllが...\bin\Releaseフォルダーにあったため、リリースモードで再構築しようとしましたが、いずれかの行でエラーが見つかりましたサブプロジェクト。エラーを解決し、ソリューションを再構築すると、ビルドエラーがなくなりました。
私の場合、私はマスターオフブランチで働いていました。マスターブランチをチェックアウトし、ビルドを実行してから、ブランチをチェックアウトしました。問題を修正しました。すでにマスター上にいる場合は、以前のコミットをチェックアウトしてからビルドすることをお勧めします。
VS 2015では、「参照」の下の「分析器」を削除すると問題が解決しました
vidarが説明したように、今日も同じことが起こりました。
ヘルパーライブラリ（他のプロジェクトで参照される）にビルドエラーがあり、ヘルパーライブラリにエラーがあることを伝える代わりに、コンパイラはMetaFile-not-foundタイプエラーのリストを出します。ヘルパーライブラリのビルドエラーを修正した後、メタファイルエラーはなくなりました。
これを改善するためのVSの設定はありますか？
相互に参照を持つ複数のプロジェクトでソリューションをチェックアウトし、それを以前に構築したことがない場合に発生するようです。プロジェクトを参照するのではなく、dllを直接参照している場合、このメッセージが表示されます。 [参照の追加]ダイアログの[プロジェクト]タブを使用して、同じソリューション内のプロジェクトに参照を追加する必要があります。これにより、VSはソリューションを構築する正しい順序を知ることができます
同様の問題がありました。クラスとインターフェースを削除した後、ビルドが失敗し始めました。
- すべてのビルドを削除して、プロジェクトがビルドされないようにします（構成マネージャー）
- ビルドの順序を確認します（スクリーンショットを撮り、ペイントに入れます：D）
- 1つずつ有効にし、クリーン＆リビルドとビルドのたびに実行します。
- これで、失敗したプロジェクトがわかりました。 :-)
私の状況では、内部に1つのインターフェースを持つフォルダーがありました。例えばFooSolution.StupidProject.Interfaces起こったことは、インターフェースIUnicorns（FooSolution.StupidProject.Interfaces.IUnicorns）をコメントアウトして、それが使用されなくなったことです。 IUnicornを使用しているプロジェクトは他にありません。すべてが大丈夫でした。
ただし...他のプロジェクトでは、そのフォルダーに対してステートメントを使用している場合があります。
using FooSolution.StupidProject.Interfaces
解決策：
インターフェースのようにコメントする代わりに、
//パブリックインターフェイスIUnicorn {
次のように、インターフェイスの上にある名前空間についてもコメントしました。
// namespace FooSolution.StupidProject.Interfaces
//{
// public interface IUnicorn {
- 私は他のプロジェクトを検索し、その名前空間を使用しないようにしました！
- きれいにして再構築し、おいしいコーヒー;-)
結論：他のプロジェクトの使用状況を確認してください。
私にとって、Visual Studioは「Visual Studioソリューションユーザーオプション」タイプのprojectname.v11を作成していました。このファイルを削除して再起動しましたが、すべて正常でした。
私にとっては、.vsフォルダ全体（それは見えないフォルダ）を削除/削除してから：
- Build
- Rebuild
完了しました。