「タイプまたは名前空間名が見つかりませんでした」を取得しても、すべてが問題ないように見えますか？

私は得ています：

タイプまたはネームスペース名が見つかりませんでした

VS2010のC＃WPFアプリのエラー。このコード領域は正常にコンパイルされていましたが、突然このエラーが発生します。プロジェクトリファレンスとusingステートメントを削除してVS2010をシャットダウンして再起動しようとしましたが、それでもこの問題が発生します。

なぜこれが起こっているのusingか、参照とステートメントについて私が正しいことをしているように見える理由はありますか？

また、VS2010で、その名前空間のインテリセンスは問題なく動作しているため、VS2010にはプロジェクト参照があり、一方で名前空間が表示されているようですが、コンパイル時に表示されません。

これは、2つのプロジェクト間の.Netフレームワークバージョンの非互換性の結果である可能性があります。

次の2つの方法で発生する可能性があります。

1. 完全なフレームワークプロジェクトを参照するクライアントプロファイルプロジェクト。または
2. 新しいフレームワークバージョンをターゲットとする古いフレームワークバージョン

たとえば、アプリケーションが.Net 4クライアントプロファイルフレームワークをターゲットにするように設定されており、それが参照するプロジェクトが完全な.Net 4フレームワークをターゲットにしている場合に発生します。

それを明確にするために：

• プロジェクトAはクライアントプロファイルフレームワークを対象としています
• プロジェクトAはプロジェクトBを参照
• プロジェクトBは完全なフレームワークを対象としています

この場合の解決策は、アプリケーションのフレームワークターゲット（プロジェクトA）をアップグレードするか、参照されるアセンブリのターゲット（プロジェクトB）をダウングレードすることです。完全なフレームワークアプリがクライアントプロファイルフレームワークアセンブリを参照/消費することは問題ありませんが、その逆はできません（クライアントプロファイルは完全なフレームワークターゲットアセンブリを参照できません）。

VS2012またはVS2013（デフォルトのフレームワークとして.Net 4.5を使用）で新しいプロジェクトを作成した場合にも、このエラーが発生する可能性があることに注意してください。

• 参照プロジェクトは.Net 4.0を使用します（これは、VS2010からVS2012またはVS2013に移行してから新しいプロジェクトを追加した場合に一般的です）

• 参照されるプロジェクトは、4.5.1または4.5.3というより新しいバージョンを使用します（既存のプロジェクトのターゲットを最新バージョンに変更しましたが、VSは引き続きv4.5をターゲットとする新しいプロジェクトを作成し、古いプロジェクトを新しいプロジェクト）

nugetパッケージを再インストールすることが私にとってはうまくいきました。すべてのプロジェクトで同期するように.NET Frameworkのバージョンを変更した後、一部のnugetパッケージ（特にEntity Framework）は以前のバージョンでまだインストールされていました。パッケージマネージャーコンソールのこのコマンドは、ソリューション全体のパッケージを再インストールします。

Update-Package –reinstall

なぜこれが機能したのかはわかりませんが、VS2015が検出できなかったと言っているプロジェクト参照を削除して、もう一度追加しました。問題を解決しました。VSのクリーンアップ、ビルド、再起動の両方を試してみましたが、役に立ちませんでした。

ソリューションを構築すると、同じエラーが発生しました（タイプまたは名前空間 ''が見つかりませんでした）。その下に警告が表示されました「参照を解決できませんでした」と「アセンブリがディスクに存在する」ことを確認するためのが表示されました。

私のDLLが参照が指している場所に非常に明確にあったので、私は非常に混乱しました。ソリューションを構築しようとするまで、VSはエラーを強調していなかったようです。

私はようやくその問題に気づきました（または少なくとも私が問題だと疑っています）。同じソリューションでライブラリファイルをビルドしていました。そのため、ディスク上に存在していたとしても、その場所で再構築されていました（ライブラリが何らかの方法で再構築される過程で、同じソリューションで、ライブラリを参照し、ライブラリが存在しないと判断したに違いありません）。

プロジェクトを右クリックしてビルドしただけで、ソリューション全体ではなく、エラーは発生しませんでした。

この問題を修正するために、ライブラリを、それを使用していたプロジェクトへの依存関係として追加しました。

これをする：

1. ソリューションエクスプローラーで自分のソリューションを右クリックし、[プロパティ]を選択しました
2. 次に、「共通のプロパティ」で「プロジェクトの依存関係」を選択しました。
3. 次に、[プロジェクト]ドロップダウンメニューで、ライブラリに依存するプロジェクトを選択し、
4. [依存]の下にあるライブラリの横のチェックボックスをオンにしました

これにより、ライブラリプロジェクトが最初にビルドされます。

まず、プロジェクトで生成された情報が破損していないことを確認します。クリーンアップを行い、ソリューションを再構築します。

それでも問題が解決しない場合、過去にデザイナーの問題で機能していたのは、windowsフォームプロジェクトを開いてからもう一度閉じることです。これは少し鶏の内臓っぽいので、息を止めないでください。

私が遭遇したよりトリッキーな状況は次のとおりです。プロジェクト1は、Microsoft.Bcl.Asyncパッケージがインストールされた4.0の完全なフレームワークをターゲットにしています。プロジェクト2は4.0の完全なフレームワークをターゲットにしていますが、プロジェクト1のクラスを参照するとコンパイルされません。

2つ目のプロジェクトにAsync NuGetパッケージをインストールすると、問題なくコンパイルされました。

私の場合、VisualStudioの参照には三角形があり、この画像のように感嘆符があります。

次に、右クリックして削除し、dll参照をもう一度正しく追加すると、問題は解決しました。

これは私のために働いた。クラスで、クラス名が定義されている場合（例：パブリッククラスABC）、1文字を削除して少し待ちます。名前を変更したため、エラーリストが増加します。次に、入力した文字を元に戻します。これは私にとってはうまくいきましたが、うまくいけばあなたにとってもうまくいくでしょう。幸運を！！！

同様の問題がありました：コンパイラーが同じプロジェクト内のフォルダーを検出できなかったため、そのフォルダーにリンクするusingディレクティブがエラーを生成しました。私の場合、問題の原因はフォルダの名前を変更したことです。そのフォルダー内のすべてのクラスの名前空間を更新しましたが、プロジェクト情報はどういうわけか更新できませんでした。私はすべてを試しました：.suoファイルとbinとobjフォルダーの削除、ソリューションのクリーニング、プロジェクトのリロード-何の助けにもなりませんでした。フォルダーと内部のクラスを削除し、新しいフォルダーを作成し、その新しいフォルダーに新しいクラスを作成することで問題を解決しました（単に新しいフォルダー内にクラスを移動しても役に立たなかった）。

PS：私の場合、私はWebアプリケーションで作業していましたが、この問題はさまざまなタイプのプロジェクトで発生する可能性があります。

[Facepalm]私の問題は、C ++の方法で依存関係を追加したことです。

ビルドされないプロジェクトに移動し、ソリューションエクスプローラーで「参照」フォルダーを開き、依存関係がリストされているかどうかを確認します。

そうでない場合は、「参照を追加」して、「プロジェクト」タブで依存関係を選択できます。

ブームシャンカール。

奇妙なケースがありましたが、ソリューションで修正しました。メインプロジェクトの「using」ステートメントの前に隠し文字/空白文字がありました。そのプロジェクトは正常に構築され、Webサイトは正常に機能しましたが、それを参照する単体テストプロジェクトは構築できませんでした。

既存のプロジェクトをVS2008からVS2012にアップグレードするときにこの問題が発生しました。2つのプロジェクト（作成した2つだけ）が異なる.Net Frameworks（3.5と4.0）をターゲットにしていることがわかりました。プロジェクトの[アプリケーション]タブで、両方のプロジェクトの[ターゲットフレームワーク]ボックスに「.NET Framework 4」が含まれていることを確認して、これを解決しました。

同じエラーが発生した場合、私の話は次のようになりました：（gitを介した）悪いマージの後、私の.csprojファイルの1つに次のcompileような重複したエントリがありました：

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate

大きな解決策があり、エラーウィンドウに300を超えるメッセージがある場合、この問題を検出するのは困難です。そこで、破損した.csprojファイルをメモ帳で開き、重複したエントリを削除しました。私の場合は働いた。

私は議論されたのと同じ問題を抱えていました：VS 2017はエラーとして参照プロジェクトのクラスに下線を引いていますが、ソリューションは問題なく構築され、インテリセンスさえも機能します。

これが私がこの問題をどのように解決したかです：

1. 参照プロジェクトをアンロードします
2. VSで.projファイルを開きます（誰かがここで提案したように私は重複を探していました）
3. プロジェクトを再度リロードします（重複がなかったため、projファイルを変更または保存しませんでした）

問題が発生していると思われるコードを削除し、そのコードへの参照なしでコンパイルされるかどうかを確認することもできます。そうでない場合は、再度コンパイルされるまで修正してから、疑わしい問題のコードを元に戻します。コンパイラが他のものが気に入らないときに、正しいとわかっているクラスまたはメソッドに関する奇妙なエラーが発生することがあります。実際にハングアップしている問題を修正すると、これらの「ファントム」エラーは消えます。

私はこれが死んだ馬を蹴っているのを知っていますが、私にはこのエラーとフレームワークがありました。私の問題は基本的に、インターフェイスが見つからないことを述べていましたが、それでも問題なく構築され、アクセスできました。それで、「他の人がうまく機能しているのに、なぜこのインターフェースだけなのか」と考えました。

最終的に、エンティティバージョン6を使用しているエンドポイントのインターフェイスでWCFを使用してサービスに実際にアクセスしていて、残りのプロジェクトはバージョン5を使用していたことがわかりました。それらを異なってリストした。

たとえば、EntityFramework6.dllとEntityFramework.dllの比較。

次に、クライアントプロジェクトへの参照を追加し、エラーを解消しました。ほとんどの人がEntity Frameworkのバージョンを混在させないため、これはエッジケースであることに気づきました。

私のソリューションをミックスに追加したのは、それが少し異なっていて、理解するのにしばらくかかったからです。

私の場合、新しいクラスを1つのプロジェクトに追加しましたが、バージョンコントロールバインディングが設定されていないため、ファイルをVisual Studioの外部（VC経由）で書き込み可能にする必要がありました。Visual Studioで保存をキャンセルしましたが、VS外でファイルを書き込み可能にした後、VSでもう一度[すべて保存]をクリックしました。これにより、誤って新しいクラスファイルがプロジェクトに保存されませんでした。ただし、ファイルを再コンパイルしようとしても見つからず、タイプが見つかりませんエラー。Visual Studioを閉じて開いても問題が発生しました（ただし、メモを取っていた場合、再度開いたときにクラスファイルが失われていました）。

これに気づいたら、修正は簡単でした。プロジェクトファイルを書き込み可能に設定して、不足しているファイルをプロジェクトに読み取りました。すべてが正常にビルドされます。

同じ問題がありました。ある夜、私のプロジェクトは翌朝コンパイルされますERRORS!。

私は最終的に、ビジュアルスタジオが私の参照の一部を「微調整」し、それらを別の場所に向けることにしたことを知りました。例えば：

System.ComponentModel.ISupportInitializeが何らかの形で「blahblah.System.ComponentModel.ISupportInitialize」になりました

あなたが私であるなら、vsをするのはかなり失礼なこと

このイベントはVisual Studio 2017で発生します。

1. Visual Studioを再起動します。
2. ビルドに失敗したクリーンなプロジェクト。
3. プロジェクトをリビルドします。

私の場合はここで説明したものと同じでしたがSystem.Core、参照リストから参照を削除するまでは何も解決しませんでした（すべてが正常に機能しました）

この問題はかなりイライラするので、それが誰かを助けることを願っています

この問題を解決するに*.sln.DotSettingsは、関連するソリューションのファイルを削除して再作成することもできます。

私の場合、適切なソースフォルダーにリストされているクラスがありましたが、ソリューションエクスプローラーに登録していませんでした。プロジェクトを右クリックして[既存の項目を追加]を選択し、不足しているクラスを手動で選択する必要がありました。その後、すべてがうまくいきました！

私の場合、問題は別のプロジェクトの名前空間を（意図的に）まったく同じに変更した後、アセンブリの名前もVSによって変更されたため、同じ名前のアセンブリが2つあり、一方が他方をオーバーライドしていた

私の場合、外部の依存関係（xsd2code）によって構築されたファイルがあり、どういうわけかそのデザイナ.csファイルはVSによって正しく処理されませんでした。Visual Studioで新しいファイルを作成し、そこにコードを貼り付けると、うまくいきました。

WebサイトをAzureに公開しようとしたときにこのエラーが発生する人にとって、上記の有望なソリューションはどれも役に立ちませんでした。私は同じボートにいました-私のソリューションはそれ自体でうまく構築されました。私はしなければならなくなった

1. 私のソリューションのすべてのnugetパッケージを削除します。
2. ソリューションを閉じて再度開きます。
3. すべてのnugetパッケージを再度追加します。

少し苦痛でしたが、WebサイトをAzureに公開する唯一の方法でした。

ローカルコンピューターでエージェントとして実行されているVisual Studio Team Servicesビルドを使用してビルドしようとすると、このエラーが発生しました。

それは私の通常のワークスペースでうまく機能し、エージェントフォルダー内のSLNファイルをローカルで開くことができ、すべてが正常にコンパイルされました。

問題のDLLはプロジェクト内に保存さLib/MyDLL.DLLれ、csprojファイルでこれを参照します。

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

ヒントパスにもかかわらず、文字通り、ファイルが見つからなかったことがわかりました。msbuildはプロジェクトファイルではなく、SLNファイルを基準にしていたと思います。

いずれの場合でも、表示されるメッセージがCould not resolve this reference. Could not locate the assemblyDLLがmsbuildにアクセスできる場所にあることを確認してください。

私は一種の不正をConsidered "Reference\bin\xxx.dll"して、代わりにdllをそこにコピーしたというメッセージを見つけました。

私の場合、DLLを参照として追加するとtype or namespace name could not be foundエラーが発生しました。ただし、binフォルダーに直接dllファイルをコピーして貼り付けると、エラーが解決しました。

これがうまくいった理由はわかりません。

私はこのスレッドが古いことを知っていますが、いずれにしても、インポートしたアセンブリの3番目の部分の依存関係をすべてインストールする必要があります。インポートしたアセンブリはNugetパッケージとして含まれていなかったため、依存関係がありませんでした。

このヘルプをホップ:)

私の場合、ソリューションに2つのプロジェクトがあり、参照されたプロジェクトにサブ名前空間を追加しましたが、ビルド時に、参照されたプロジェクトのビルドが失敗し、最後に正常にビルドされなかったバージョンを使用していることに気付きませんでしたこの新しい名前空間があるため、エラーは正しかったので、見つかりませんでした。存在しないため、解決策は、参照されたプロジェクトのエラーを修正することでした。

私はVS 2017コミュニティエディションで作業しており、CefSharp nugetパッケージで同じ問題がありました。

パッケージは正常にダウンロードおよび復元され、プロジェクトは正常にビルドおよび実行できました-ネームスペースが認識されなかったことを示すのはマークアップのみです。

Referencesセクションを開いて、黄色の感嘆符の1つをクリックするだけで済みました。

数秒後、マークアップエラーは解消されました。