メタデータファイル '.dll'が見つかりませんでした
私はWPF、C＃3.0プロジェクトに取り組んでいます、そして、私はこのエラーを得ます：
Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem
これが私が自分のユーザーコントロールを参照する方法です：
xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>
ビルドが失敗するたびに起こります。私が解決策をコンパイルすることができる唯一の方法は私のすべてのユーザーコントロールをコメントアウトしてプロジェクトを再構築することです、そして次に私はユーザーコントロールのコメントを外し、そしてすべてが大丈夫です。
ビルド順序と依存関係の設定を確認しました。
ご覧のとおり、DLLファイルの絶対パスが切り捨てられたようです...長さにバグがあることを私は読みました。これは考えられる問題ですか？
それは非常に厄介で、コメントし、構築し、そしてコメント解除しなければならない、構築は非常に面倒になりつつあります。
私はちょうど同じ問題を抱えていました。 Visual Studioは、参照されているプロジェクトを構築していません。
- ソリューションを右クリックして[プロパティ]をクリックします。
- 左側にある「構成」をクリックします。
- 見つからないプロジェクトの[ビルド]の下にあるチェックボックスがオンになっていることを確認します。すでにチェックされている場合は、チェックを外して適用をクリックし、もう一度ボックスをチェックします。
- （オプション）ソリューションプロパティのリリースモードとデバッグモードの両方でこれを実行する必要がありました。
これは、新しいバージョンのVisual Studioでも発生する可能性があります（Visual Studio 2013で発生したことがあります）。
もう1つ試すことは、Visual Studioを閉じて、.suoファイルの横にある.slnファイルを削除することです。 （次回にSave all（またはVisual Studioを終了）したときに再生成されます）。
別のマシンのソリューションに新しいプロジェクトを追加してからリビジョンを引き込むときにこの問題が発生しましたが、.suoファイルは他の場合にも破損し、非常に奇妙なVisual Studioの動作につながるためいつもやっていること。
.suoファイルを削除すると、ソリューションのスタートアッププロジェクトがリセットされることに注意してください。
.suoファイルの詳細は here です。
提案された答えは私のために働かなかった。エラーは別の問題のおとりです。
私は少し異なるバージョンの.NETをターゲットにしていて、これはコンパイラによって警告としてフラグが立てられていることを知りました、しかしそれは構築を失敗させていました。これは警告ではなくエラーとしてフラグが立てられているはずです。
まあ、私の答えはすべての解決策の要約だけではありませんが、それはそれ以上のものを提供しています。
セクション（1）：
一般的な解決策では：
この種のエラーが4つあり（「メタデータファイルが見つかりませんでした」）、「ソースファイルを開けませんでした（不明なエラーです）」というエラーが1つありました。
私は「メタデータファイルが見つかりませんでした」というエラーを取り除こうとしました。そのために、私は多くの投稿、ブログなどを読んで、これらの解決策が効果的であるかもしれないことを見つけました（それらをここにまとめます）：
Visual Studioを再起動して、もう一度ビルドしてください。
'Solution Explorer' に移動します。 Solutionを右クリックします。 プロパティ に移動します。 'Configuration Manager' に移動します。 'Build' の下にあるチェックボックスがチェックされているかどうかを確認します。それらのいずれかまたはすべてのチェックが外れている場合は、それらを確認してもう一度ビルドしてみてください。
上記の解決策がうまくいかない場合は、上記のステップ2で述べた手順に従ってください。たとえすべてのチェックボックスがチェックされていても、チェックを外してもう一度チェックしてから、もう一度ビルドしてください。
ビルドの順番とプロジェクトの依存関係：
'Solution Explorer' に移動します。 Solutionを右クリックします。 'プロジェクトの依存関係...' に移動します。 2つのタブが表示されます： '依存関係' と 'ビルド順' 。このビルド順序は、ソリューションがビルドする順序です。プロジェクトの依存関係とビルド順序を確認して、他のプロジェクト（たとえば「project2」）に依存しているプロジェクト（「project1」など）がそのプロジェクト（project2）の前にビルドを試行しているかどうかを確認します。これがエラーの原因である可能性があります。
見つからない.dllのパスを確認します。
見つからない.dllのパスを確認してください。パスにスペースやその他の無効なパス文字が含まれている場合は、それを削除してもう一度ビルドしてください。
これが原因である場合は、構築順序を調整してください。
セクション（2）：
私の場合：
上記のすべての手順を、Visual Studioを再起動してさまざまな組み合わせや組み合わせで試してみました。しかし、それは私を助けませんでした。
そこで、私は私が遭遇していた他のエラーを取り除くことにしました（ 'ソースファイルを開くことができませんでした（' Unspecified error '））。
私はブログ記事に出会いました：TFSエラー - ソースファイルを開けませんでした（ '未指定エラー'）
私はそのブログ記事で言及されたステップを試みました、そして、私はエラーを取り除きました 'ソースファイルは開けられませんでした（'未指定エラー '）' そして驚くべきことに他のエラーを取り除きました （ 'メタデータファイルが見つかりませんでした '） 同様に。
セクション（3）：
物語の道徳：
エラーを取り除くために上のセクション（1）で述べたすべての解決策（およびその他の解決策）を試してください。上記のセクション（2）で説明したブログに従って、何もうまくいかない場合は、ソース管理とファイルシステムに存在しなくなったすべてのソースファイルのエントリを.csprojファイルから削除する。
私の場合は、.NET Frameworkのバージョンの不一致が原因でした。
一方のプロジェクトは3.5で、もう一方のプロジェクトは4.6.1でした。
Visual Studio 2013を閉じて再度開くとうまくいきました。
さて、これまでの答えでは何もうまくいきませんでした。開発者としてここで何が起こっているのかを本当に理解しようとするとき、なぜクリックして期待しているのかということについて考えさせられました。
この不正なメタデータファイルの参照はどこかに保持しなければならないことは私には明らかに思えました。
.csprojファイルをすばやく検索したところ、罪を犯した行が判明しました。私は<itemGroup>というセクションを持っていましたが、それは古い間違ったファイルパスにぶら下がっているようです。
<ItemGroup>
<ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
<Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
<Name>Beeyp.Entities</Name>
</ProjectReference>
...
だから、本当に簡単な修正：
- .csprojファイルをバックアップしてください。
- .csprojファイルで誤ったパスを見つけて、適切な名前に変更します。
いじる前に古い.csprojを必ずバックアップしてください 。
私もこの問題に出会った。まず右クリックしてビルドするDLLプロジェクトを手動でビルドしなければなりません。それでうまくいきます。
同じエラー「メタデータファイル '.dll'が見つかりませんでした」を受け取り、上記のいくつかのことを試しましたが、エラーの原因は、サードパーティのDLLファイルを参照していたためです。私のプロジェクトのターゲット.NETバージョンよりも高い.NETバージョンをターゲットにしています。だから解決策は私のプロジェクトのターゲットフレームワークを変更することでした。
私の場合は、インストールしたディレクトリが間違っています。
あなたの解決策のパスが "マイプロジェクト％2c非常に人気のある％2c単体テスト％2cソフトウェアとハードウェア.Zip"のようなものである場合、それはメタデータファイルを解決できません.
パスを通常の名前に変更すると、問題が解決しました。
私は自分のソリューションに新しいプロジェクトを追加し、これを手に入れました。
理由？私がもたらしたプロジェクトは、異なる.NETフレームワークをターゲットにしていました（4.6と私の他の2つは4.5.2でした）。
私にとっては、新しいプロジェクトをソリューションに含めたときに起こりました。
Visual Studioは自動的に.NET Framework 4.5を選択します。
私は他のライブラリのようにバージョン.NET 4.5.2に変更しました、そして、それは働きました。
私にとっては、プロジェクトを含むために使用されていたパスでDLLを見つけようとしていましたが、新しいディレクトリに移動しました。ソリューションにはプロジェクトへの正しいパスがありましたが、Visual Studioはどういうわけか古い場所を見続けました。
解決策：それぞれの問題のあるプロジェクトの名前を変更してください - 単に文字か何かを追加してください - それから元の名前に戻してください。
これにより、Visual Studioで何らかのグローバルキャッシュをリセットする必要があります。これは、この問題とそれに似た問題の両方を解決するためです。一方、Cleanなどの問題は解決しません。
私もこの問題に頭を悩ませていましたが、前の答えを試した後に私にとってうまくいった唯一のことは私のソリューションの各プロジェクトを1つずつ開いて個別にビルドすることでした。
それから私はVisual Studio 2013を閉じて、私の解決策を再開しました、そして、それはうまくコンパイルしました。
ソリューションエクスプローラーで各プロジェクトをクリックしてそのようにビルドしようとすると、すべて失敗したため、奇妙なことです。私は彼ら自身の解決策で彼らを一人で開かなければなりませんでした。
私にとっては、次のステップがうまくいった：
- 構築されていないプロジェクトを探す
- ソリューション内のプロジェクトへの参照を削除/追加します。
私の問題は、クラス名が重複している（別のファイル名で）一般的なプロジェクトが原因です。 Visual Studioがそれを検出できず、代わりにビルドプロセスを失敗させたのは不思議です。
私は多くのプロジェクトを持っていたソリューションで、Visual Studio 2012でこの問題を抱えていました。プロジェクトビルドの順序（ソリューションエクスプローラーで右クリックして再構築）と同じ順序で手動でソリューション内の各プロジェクトを再構築したところ、問題は解決しました。
やがて私はコンパイルエラーを起こしたものにたどり着きました。私はエラーを修正しました、そしてその後ソリューションは正しく構築されるでしょう。
私の場合、問題は単純なビルドエラーが原因でした。
エラーCS0067：イベント 'XYZ'は使用されていません
それは、何らかの理由で、エラーウィンドウに表示されませんでした。
そのため、Visual Studioビルドシステムはエラーを見逃しているようで、依存プロジェクトをビルドしようとしましたが、それが煩わしいメタデータメッセージで失敗しました。
お勧めは - それが聞こえるかもしれないのでばかげて -
最初にあなたの 出力ウィンドウを見てください ！
このアイデアが私に打撃を与えるまでに30分かかりました...
私の場合、問題は、 "missing"とマークされている非コンパイルファイルを手動で削除することでした。私は今行方不明のファイルへの参照を削除し、再コンパイルしたら - すべてが順調だった。
数年後にこの問題に戻ると、この問題はWindowsの最大パス制限に関連している可能性があります。
私も同じエラーがありました。以下のように隠れます。 DLLファイルで参照したパスは、 "D：\ Assemblies Folder\Assembly1.dll"のようになっています。
しかし、アセンブリが参照していた元のパスは "D：\ Assemblies％20Folder\Assembly1.dll"でした。
このパス名のバリエーションのため、アセンブリは元のパスから取得できず、したがって「メタデータが見つかりません」というエラーがスローされます。
解決策は、スタックオーバーフローの質問にあります。C＃ですべてのスペースを％20に置き換えるにはどうすればよいですか。。
私は同じ問題に直面したでしょう。私の場合、私は自分のプロジェクトよりも高い .Netバージョン のクラスライブラリプロジェクトを参照していましたが、VSがプロジェクトの構築に失敗し、あなたが投稿したのと同じエラーが発生しました。
クラスライブラリプロジェクト（ビルドを壊したもの）の .Netバージョン を参照しているプロジェクトの.Netバージョンと同一に設定して問題を解決しただけです。
これは、Visual Studioがエラーに関する正しい情報を提供していないという事実に関連するエラーのようなものです。開発者は、失敗したビルドの理由さえ理解できません。それは構文エラーか何か他のものかもしれません。一般に、このような問題を解決するには、問題の根本を見つける必要があります（たとえば、ビルドログを調べてください）。
私の場合、問題は実際にはError Listウィンドウにエラーが表示されていなかったことです。しかし、本当に構文エラーがありました。私はOutputウィンドウでこれらのエラーを見つけ、それらを修正した後、問題は解決しました。
偽のアセンブリを使用している場合、このエラーが表示されることがあります。偽物を削除すると、プロジェクトが正常に構築されます。
エラーメッセージに基づいて、ファイルパスが切り捨てられているとは思わない。それはただ間違っているようです。メッセージを正しく読んでいれば、DLLファイルを探しているようです...
WORK = - \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug\BusinessLogicLayer.dll
これは有効なパスではありません。ビルドプロセスのマクロ定義が無効な値に設定されている可能性はありますか？
Visual Studio 2013を実行しています。
ビルドの依存関係が正しくないようです。 * .suoファイルを削除しても問題は解決しました。
私の場合は、特定の（空の）名前空間のクラスをコメントアウトしたことです。
namespace X.Y.Z.W
{
// Class code
}
名前空間のコードとそのインポート（使用）コマンドを削除したところ、問題は解決しました。
ビルドでそれはまた言っていた - プロジェクトの足りないDLLファイルと一緒に：
エラーCS0234：型または名前空間名 'W'が名前空間 'X.Y.Z'に存在しません（アセンブリ参照がありませんか？）
Webアプリケーションを公開しようとしたときにこのエラーが発生しました。クラスプロパティの1つがラップされていることがわかりました
#if DEBUG
public int SomeProperty { get; set; }
#endif
しかし、財産の使い方はそうではありませんでした。明らかに、公開はDEBUGシンボルなしでリリース設定で行われました。
ソリューション名にスペースがあると、これも問題の原因になります。ソリューション名からスペースを削除して、パスに％20が含まれないようにすると、これを解決できます。
明らかに明白なことを指摘してください： "ビルド開始時に出力ウィンドウを表示する"が有効になっていない場合は、ビルドが失敗したかどうかを確認してください（左下の小さな "ビルド失敗"エラー）。
Entity Frameworkが参照されているプロジェクトを開いた後にこのエラーが発生したため、そのような参照を削除し、acketマネージャーを介してEntity Frameworkバージョン6.0.0.0を次のように再インストールしました。
install-package entityframework -version 6.0.0.0
エラーはまだ表示されていたので、これらの参照はプロジェクトに "プレインストール"されていると思われるEntity Frameworkの古いバージョンがあったためにそこにあると思いましたが、実際には機能していませんでした。
それで私はファイルpackages.configに行き、そして別の参照があることに気づきました：
<packages>
**<package id="EntityFramework" version="5.0.0" targetFramework="net45" />**
<package id="EntityFramework" version="6.0.0" targetFramework="net45" />
</packages>
それから私はその行を削除し、プロジェクトとコンテナソリューションをきれいにして再構築し、そしてそれはついにうまくいきました。
私の場合、これらのエラーはNuGetパッケージマネージャの破損によって引き起こされました。このソリューションのサブプロジェクトは構築されていませんでしたが、メタデータエラーのためにエラーは発生していませんでした。
すべてのNuGetパッケージが修正されると、プロジェクトは再び正しくビルドされます。
私は同じ問題を抱えていました。私の場合、プロジェクトはまだリリースモードでビルドされていましたが、デバッグでビルドしようとしたときに失敗しました。
私が問題を解決するためにしたのは、単にすべてのdll（および自分のreleaseフォルダの他のファイル）を自分のdebugフォルダにコピーすることでした。すべてのプロジェクトに対してこれを実行した後、エラーは解消されました。
ソリューションフォルダにあるNuGetを含むpackagesフォルダを削除するとうまくいきました。再建後、すべてがまたうまくいった。ソリューション内のReferencesを確認し、黄色の三角形のある参照を確認してください。
写真の例：
私の場合、このエラーが発生したのは、私のプロジェクトの1つが他のソリューションとは異なる.NET Frameworkバージョンを使用していたためです。私はNLogをインストールするためにNuGetパッケージマネージャを使ったので、私はそれがこのプロジェクトの.NET版のためにインストールされたと思う。
私はこの記事からすべての解決策を試しましたが、どれもうまくいきませんでした。私はNLogを削除し、解決策をきれいにし、コンパイルするために試しました。同じこと、CS006エラー。
ソリューションがコンパイルしたのは、このプロジェクトからobj\Debug内のすべてのファイルを削除したときでした。
実稼働環境にデプロイされた非常に古いライブラリーを逆コンパイルしたときにも同じような問題がありましたが、ソースコードは失われました。
私は.dllを取り、逆コンパイルしてプロジェクトとソリューションを生成しました。私はこの種のいくつかのエラーのためにソリューションを構築することができませんでした。
前回の回答のヒントは役に立ちませんでしたが、しばらくして、System.dllのようないくつかのアセンブリに対するいくつかのプロジェクトで参照が欠けていることに気付きました。
プロジェクトBに依存するプロジェクトAがあるとします。プロジェクトBにSystem.dllへの参照はありませんでしたが、ビルド後のエラーは "メタデータファイル 'B.dll'が見つかりませんでした"のようなものでした。
プロジェクトBにSystem.dllが見つからないことに関するエラーはありませんでした。
プロジェクトBのSystem.dllのようなライブラリへの参照を追加することで問題は解決しました。 （System.Data、System.DirectoryServicesなど）
.nuget\NuGet.exeが私のリポジトリに含まれていなかったので、私はこの問題を抱えていました。 NuGet.targetsでDownloadNuGetExeを有効にしましたが、ダウンロードしようとするとプロキシエラーが報告されました。これにより、残りのプロジェクトビルドが失敗しました。
私は4.6.2のクラスを参照していた4.6.2のクラスを参照していました。クラスを462にアップグレードすると修正されました。
私の場合、ソリューション内のプロジェクトのいくつかは Any CPU をターゲットにしていました。それらのいくつかはx86をターゲットにしていました。ソリューション全体でプラットフォームターゲットを統一すると、コンパイルエラーがなくなりました。
ユーザー@burzhuyが指摘するように、Error ListウィンドウだけでなくOutputwindowを見ることが重要です。
私の場合は、 Roslyn コンパイラを修正する作業をしていました。そのビルドプロジェクトは、パブリックフィールドがコンパイラのパブリックインターフェイスとして定義されているものと一致しているかどうかを確認するための追加のチェックを実行します。そうでなければ、RS0016またはRS0017エラーを生成します。私はいくつかのパブリックフィールドを追加し、エラーの上にマウスを置いて「Add to public API」を選択することによってRS0016エラーを修正しました。
後で私は考えを変え、パブリックフィールドを別のクラスに移動しました。何らかの理由で、これにより「メタデータファイルが見つかりませんでした」エラーが表示され、それをいじるほどエラーが増えました。
正しいPublicAPI.Unshipped.txtファイル（私の場合はE:\Roslyn\32414\src\Compilers\Core\Portableに入っています）を見つけて、それを手動で編集して、関連性がなくなった行を削除する必要があります。
私の個人的なケースでは、私はソリューションのプロジェクトの1つへの参照を追加することに失敗しました、そしてこれは私のためにエラーを引き起こしていたものです。
私の問題は私がC＃7コードを書いたときに来たが、プロジェクトは。NETフレームワークのために古いバージョンを使用していた
私の場合、それは ReSharper でした。そして、私のプロジェクトはC＃6をターゲットにしていますが、C＃7だけの機能を使うためのリファクタリングを提供されていました。
このため、私はこのコードを変更しました。
private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
get { return _joinedDate ?? DateTime.Now; }
set { _joinedDate = value; }
}
このコードに：
private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
get => _joinedDate ?? DateTime.Now;
set => _joinedDate = value;
}
何らかの理由で、ゲッターとセッターに式本体を使用させると、コンパイラーは構文エラーではなくそのメタデータ・エラーを思い付きました。
aaaaaと6年後のVisual Studio 2015へのアップグレード中に同じ問題が発生しました。この特定の解決策はこのリストには含まれていないため、追加します。
2つの参照されたdllはc：\ windows\system32 ...フォルダにありました。それらをシステムフォルダ以外のフォルダに移動し、新しいフォルダへの参照を追加することで最終的に修正されました。その他の問題は、実際に他の人がすでにここで言っていることです。
問題の原因は、ソリューション内のDLLファイルおよびプロジェクトへの参照の追加が混在していることです。
プロジェクトA、B、Cがあるとします。
- AはソリューションのプロジェクトとしてBとCを参照します。
- BはCをDLLファイルとして参照します（ファイルへの参照）
各プロジェクトを個別にビルドすることはできますが、次のもので終わるソリューションを再構築することはできません。
ソリューション内のファイルからプロジェクトへの参照を変更すると役立ちます。
私の場合、このエラーメッセージが出たのは、TFSからプロジェクトの最新バージョンを入手した後で、ソリューション内の間違ったプロジェクトがスタートアッププロジェクトとしてマークされていたためです。スタートアッププロジェクトとして正しいプロジェクトを選択することでこれが解決しました。
うわー、それはこのエラーが至る所から来ることができるようです。
とにかく、私は私のMVCアプリケーションに新しいWebAPIコントローラを追加しました、そしてそれは自動的にNuGetからすべての参照を得ました。少し後に、NuGet UIから参照を削除しましたが、それらを使用してファイルを削除するのを忘れました（つまりSystem.Http）。
何らかの理由で、私が受け取っていたエラーはこれであり、変数が使用されていないという簡単な警告もあります。
少なくとも警告を取り除き、再構築するために変数をコメントアウトして、存在しない参照を使用していたすべてのファイルから私を指摘しました。これらのファイルを削除した後、すべてうまくいった。
私はこの問題に直面しました。私の場合、複数のC＃プロジェクトがDLLファイルとして参照されていました。他のプロジェクトでDLLファイルとして使用されているプロジェクトでコンパイル時エラーが発生すると、大量のエラーが発生します。その理由は、コンパイル時エラーにより、対応するDLLファイルの作成が妨げられ、プロジェクト内で不足しているDLLファイルを参照する一連のエラーが発生するためです。
そのため、ソリューションエクスプローラで再構築すると（単純なコンパイル時のエラーは無視されます）、 "メタデータファイル.dllが見つかりませんでした"というエラーが発生します（単純な再構築以外に何をしたのかを考えます）。
あなたがこの問題に直面しているなら、最良の解決策は解決策をきれいにして、どのプロジェクトがエラーを起こしているかを把握するために一つずつ各プロジェクトを構築することです。
この問題は、メタデータエラーのために表示されない可能性があるコード内の構文エラーが原因で発生する可能性があります。そのため、前の回答のアクションを実行する前にソースファイルを確認してください。
プロジェクトの参照としてMicrosoft.CSharpアセンブリを削除すると、このエラーが発生することがわかりました。
Visual Studio 2015でこのエラーに遭遇したのは、拡張メソッドの呼び出しから型注釈を削除したときで、空の山括弧だけが残っていました。
obj.extensionMethod<Type>()の代わりに私はobj.extensionMethod<>()を持っていました。
この間違いがどのようにしてそのエラーを引き起こす可能性があるのかわからないので、私はこれをVisual Studioのバグとして分類します。
私にとって問題は、2つのVisual Studioウィンドウを開き、1つのウィンドウでプロジェクトをデバッグ中に実行し、別のウィンドウでそれを構築しようとしたことです。
私はデバッグをやめなければなりませんでしたそしてそれはそれから私がうまく構築することを可能にしました。
私は上記のすべてに違いがあることに同意します。私の場合：私はVisual Studio 2019を使用しています。私はVS-2019を閉じ、VS-2017で開きました。プロジェクトを再構築し、すべてがうまくいったことを確認してください。私のポジションにいる人は誰ですか：4/19/2019
- 解決策を右クリックして[クリーン]をクリックします。
- ソリューションを右クリックして[再構築]をクリックします。
私の場合は、.Net Framework 4.7プロジェクトを.Net Framework 4.6.1プロジェクトへの依存として参照したことに気付いた後、この問題を解決しました。プロジェクト4.7を4.6.1に移行した後、アプリケーションが正常にコンパイルされました
メインプロジェクトの.csprojファイルを確認してください。プロジェクトを削除したり、ソリューション内の参照を変更した場合、Visual Studioはそれをクリーンアップしません。
.csprojファイルで3回参照されている古いプロジェクトがあり、それらの削除されたプロジェクトにコンパイルエラーが表示されました。
コードに次の行があるため、このエラーが発生しました（まだSQLモードで考えていたようです）。
if(myVar is null)
DoSomething();
Visual Studio（2017）は、設計時またはコンパイル時にエラーを報告しませんでしたが、プロジェクトはビルドされず、 "missing .dll"エラーが発生しました。誤った行を次のように変更すると：
if(myVar == null)
問題は解決しました。
私の場合、私はこれと一緒にたくさんの他の構築エラー（いくつかの単純な型変換）を持っていました、私はこれを解決しようとして私の頭をかいていました、そして私は他のエラーに焦点を合わせませんでした。
最後に私が抱えていた問題を解決したのは、他のすべてのビルドエラーを修正してから、もう一度ビルドして、正常にビルドされたことです。
したがって、DLLファイルの欠落エラーとともに他のビルドエラーが発生した場合、他には何も機能しないので、最初に他のエラーを修正してからソリューションを再度ビルドします。
これまでのところ何十もの答えのどれも私のために働きませんでした。私の場合は、エラーも出ました。
タプル要素名 'Value'が推測されます。推論名で要素にアクセスするには、言語バージョン7.1以降を使用してください
これはビルド時に「メタデータファイル '.dll'が見つかりませんでした」エラーの横に表示されていましたが、IDEが追いついてエラーが発生することがあるため、間もなく消えました。
エラーをダブルクリックして見つけ、問題のあるコードを削除して修正します。
それ以外の場合は、Visual Studioでこれを試すことができます。
メニュー プロジェクト →<プロジェクト名> プロパティ → ビルド →ボタン 詳細 → 言語バージョン → C＃ <最新のマイナーバージョン>（例： " C＃5.0 "）
そしてそれもそれを修正します。
「メタデータファイル '.dll'が見つかりませんでした」という問題は、他の根本的な問題の症状であることが多いため、他の解決策がうまくいかない場合は、他のエラーや警告を確認し、問題を見つけてください。
同じ問題と別の解決策がありました。
問題：1つの解決策、複数のプロジェクト。他のいくつかの結果を使用するメインアプリケーションは失敗し、次のように述べています。
CSC：エラーCS0006：メタデータファイル 'C：\ Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplication.dll'が見つかりませんでした
しかし実際にはこのプロジェクトはC:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplicationCommon.dllを生成しました同じDLLを使用する別のプロジェクトも完璧にコンパイルされました。
PostSharp 3.x.x.xを使用し、PostSharp 4.x.x.xを使用する内部NuGetパッケージをアップデートする前に。そして私の解決策はこれを私の* .csprojファイルに追加することでした。
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="...">
<Import Project="..." Condition="..." />
<PropertyGroup>
...
<AssemblyName>TheApplication</AssemblyName>
...
<SkipPostSharp>True</SkipPostSharp> <!-- This line -->
</PropertyGroup>
...
別の解決策 - >クリーン、別の解決策 - >再構築すれば、ローカルでもビルドサーバーでも動作します。
誰かに役立つことを願っています。スレッドは古くて非常に長いですが、この問題は頻繁に発生し、私はこの解決策をまだ見ていません。ところでVisual Studio 2017（15.8.x）を使用して。
Bin/objフォルダーを削除してから、プロジェクトを再構築するとうまくいきました。
私の場合、最初にプロジェクトをビルドしたときにランタイムエラーが発生し、dllファイルが生成されなかったと考えられます。
これは、プロジェクトを別のプロジェクトから参照するときに発生しました。私が参照していたプロジェクトは、問題のあるプロジェクトでした。
これらの答えの多くは、試行錯誤のように聞こえます。私の場合、それは簡単でした。参照されたdllがその特定の場所で見つかりませんでした。
ビルドエラーが表示される場合（通常この場合）、ビルドは多くのdllについて文句を言います。重要なのは、不足している正しいdllを見つけることです。私の場合、ソリューションのプロジェクトの1つに、プロジェクト参照ではなく直接DLL参照がありました。そのため、失敗したソリューションがその特定の場所で見つからないdllを見つけることを確認するために、失敗したソリューションをビルドする前にそのDLLを出力するプロジェクトをビルドする必要がありました。
うわー..それは簡単でしたが、言葉で表現するのは非常に困難でした。
私の場合はWeb.configファイルの中でこれを変更しています
<?xml version="1.0" encoding="utf-8"?>
これに
<?xml version="1.0"?>
私の問題を修正しました
私の場合、NuGetパッケージをローカルに参照してディレクトリを別の場所に移動したときに、NuGet.Config内のパスを変更しましたが、残念ながら.csprojectファイルを手動で変更して更新する必要があることがわかりました参照パスですが、エラーメッセージCS0006は、この問題の説明にはほど遠いものでした。一般に、見つからないDLLへの参照がある場合にも発生します。問題を特定するために、プロジェクト内の参照検索で問題を見つけられるように、警告アイコンが付いた参照を見つけます。 、それらを修正してみてください。期待どおりに動作するはずです。
私はgetting latest（Team Foundation Server（TFS）コマンド）の後にこの問題に直面しました。
衝突を解決した後、私はnamespace that does not exist in the projectのステートメントを使用して見つけました。
それで私はそのusingステートメントを削除してからclean and rebuildを削除しました、そしてすべてはOKでした。
私がビルドしたとき、それは通常Visual Studio 2017でこのようなエラーを表示するでしょう：
Error CS0006 Metadata file 'C:\src\ProjectDir\MyApp\bin\x64\Debug\Inspection.exe' could not be found MyApp C:\src\ProjectDir\MyApp\CSC 1 Active
しかし、時にはこのようなエラーが数秒間表示され、それから消えて上記のメッセージに戻るでしょう。
Error CS1503 Argument 1: cannot convert from 'MyApp.Model.Entities.Asset' to 'MyApp.Model.Model.Entities.Inspection' MyApp C:\src\ProjectDir\MyApp\ViewModels\AssetDetailsViewModel.cs 1453 Active
だから私は最初のエラーのトラブルシューティングに時間を費やしたが、本当の問題は2番目のエラーが原因であることがわかった。最初にすべての/ binディレクトリと/ objディレクトリを削除する必要があり、次に上記のように.suoファイルも削除しました。これにより、問題をインターフェースの問題に絞り込むことができました。
私のインターフェースで私はこれを持っていました：
Task<IList<Defect>> LoadDefects(Asset asset);
しかし、私の実際の実装では、私はこのコードを持っていました：
public virtual async Task<IList<Defect>> LoadDefects(Inspection inspection)
{
var results ...
// ....
return results;
}
私がこれにインターフェイスを更新した後に構築は正常に完了しました：
Task<IList<Defect>> LoadDefects(Inspection inspection);
そのため、実際の問題がCS1503エラーであった場合、VSのキャッシュによってCS0006エラーが表示され続けたようです。
以前の解決策はどれも私には効果がなかったので、私はしたことを共有します。
互いに参照し合う別のブランチからの新しいクラスライブラリをいくつかマージした後に、この問題が発生しました。プロジェクト内の参照を削除し、それらを再作成することでようやく問題が解決しました。どうやらVisual Studioは間違ったファイルパスをマージしました。
私にとって問題は、ビルドの出力に出てこなかったエラーでした。つまり、最初は異なる名前空間にあった2つのユーティリティクラスがありました。 2番目の名前空間を最初の名前空間と一致するように変更しました（最初のものに別のユーティリティクラスがあることを知らなくても）、それがこのエラーが発生し始めたときです。
Logic LayerライブラリDLLファイルをビルドできず、メインアプリケーションでも見つからないため、ビルド出力エラーが表面化したと思います。
解決策は、2番目のユーティリティクラスを別の名前空間に変更することでした。実際のビルドエラーが発生し始めたときです。それらを整理した後、ビルドはうまくいきました。
概要として、以前の解決策のいずれかがうまくいかない場合は、Visual Studioが表示していないコード内のエラーを抑制した可能性があるので、コーディング手順を見直し、不規則性がないか確認します。
シモンズ：これはVisual Studio 2015 Community Editionにありました
私は解決策をたくさん変更し、変更を保留して元に戻すことでこの問題を抱え始めました。
それを解決する唯一の方法は、TFSからローカルフォルダへのマッピングを削除して再度追加することでした。
この問題は、プロジェクトで選択されている。netのバージョンでサポートされていない機能を使用しているために発生する可能性があります。
私の場合、理由は??演算子を使用してnullをチェックし、例外をスローしたことです。
VSがビルドエラーのリストで問題の実際の理由を通知しないほど奇妙です。
ただし、ビルドのOutputログでこの情報を見つけることができます。
非常に奇妙な！私は以前の答えをすべて試しましたが、残念ながら私の場合はうまくいきませんでした。
2つのエラーが発生しました。
- .dllファイルが見つかりません
- 同じパラメータで別の場所でメソッドがすでに定義されています
私は最初に2番目のエラーを別の場所で複製された機能を削除することによってクリアしました。
私の最初のエラー - それは.dllファイルが欠けているということですそれ自身でそれを解決しました。
私は言いたいのですが、.dllファイルが見つからないというエラーとともに複数のエラーがある場合は、まず他のエラーを解決してみてください。たぶん.dllエラーがそれを自分で解決します！
私の場合は、ターゲットフレームワークを設定することで問題が解決しました。
プロジェクトを右クリックして[ プロパティ] を選択します。
Application 、 Target framework をメインプロジェクトと同じものに変更します（例： ".NET Framework 4.5"）。
Visual Studio IDEは舞台裏では何も構築しませんが、Msbuildアプリケーションは構築しません。 VS IDEは基本的にMsbuildで使用されるプロジェクトファイルを作成するだけで、自分で問題を解決するためにIDEに任せてしまうと間違いを犯しがちです。 Metadata file '.dll' could not be foundエラーが発生した場合は、正しい/予期されるアセンブリが見つからないことが原因である可能性があります。そのため、おそらく、Visual Studioが4.5フレームワークアプリケーション用のプロジェクトファイルを作成し、4,5のアセンブリを期待している一方で、4.0のアセンブリを参照している可能性があります。そのため、Visual Studioの設定で互換性がないかどうかを調べるか、プロジェクトファイルを自分で調べて、正しいパス<Reference Include="C:\\correct path to Assembly\\yourAssembly.dll" />を指定して手動で修正してください。