web-dev-qa-db-ja.com

「型または名前空間の名前が見つかりませんでした」と表示されますが、すべて問題ないようですか?

私は:

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

vS2010でのC#WPFアプリのエラー。この部分のコードは正常にコンパイルされていましたが、突然このエラーが発生します。プロジェクトリファレンスとusingステートメントを削除し、VS2010を閉じて再起動しようとしましたが、それでも私はこの問題を抱えています。

なぜこれが起きているのか、Reference&using文について正しいことをしているように思われる場合は、どのようなアイデアがありますか。

私はまたVS2010でその名前空間に対するインテリセンスはうまくいっていることに注意しました、それでそれはVS2010がプロジェクト参照を持ちそして一方で名前空間を見ているように思えます、しかしコンパイルの間それを見ない?

242
Greg

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

それは2つの方法で起こる可能性があります。

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

例えば、アプリケーションが.Net 4 Client Profileフレームワークをターゲットとするように設定されていて、それが参照するプロジェクトが完全な.Net 4フレームワークをターゲットとするように設定されている場合に起こります。

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

  • プロジェクトAはClient Profileフレームワークをターゲットにしています
  • プロジェクト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をターゲットにした新しいプロジェクトを作成します。新しいプロジェクト)

419
slugster

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

Update-Package –reinstall
35
saxorut

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

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

私はついにその問題に気づいた(あるいは少なくとも私がその問題であると疑ったもの)。私は同じ解決策でライブラリファイルを構築していました。ディスク上に存在していたとしても、それはその場所で再構築されていました(どういうわけか私の他のプロジェクトを再構築する過程で - 同じ解決策で - ライブラリを参照したライブラリは存在しないことを決定したに違いありません)

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

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

これをする:

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

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

27
ksun

なぜこれがうまくいったのか私にはわかりませんが、私はVS2015がそれを見つけることができないと言っていたというプロジェクト参照を削除し、それを再び追加しました。問題を解決しました。私は役に立ちませんでしたVSのクリーニング、構築、そして再起動の両方を試してみました。

22
Alexander Høst

まず、私はあなたのプロジェクトが生成した情報が破損していないことを確認します。ソリューションをクリーンにして再構築します。

それでも問題が解決しない場合は、デザイナーの問題に関して過去に作業を確認したことの1つは、Windowsフォームプロジェクトを開いてからもう一度閉じることです。これはちょっとチキン - 内臓風のようですが、息を止めないでください。

6
Greg D

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

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

5
Kim

私は同じような問題を抱えていました:コンパイラは同じプロジェクト内のフォルダを検出できませんでした、そのフォルダへのusingディレクティブリンクはエラーを生成しました。私の場合、問題はフォルダの名前変更に由来します。そのフォルダ内のすべてのクラスのネームスペースを更新したにもかかわらず、プロジェクト情報が更新されませんでした。私はすべてを試しました:.suoファイルとbinとobjフォルダを削除すること、解決策をきれいにすること、プロジェクトをリロードすること - 何も助けになりませんでした。 フォルダとその中のクラスを削除し、新しいフォルダを作成し、その新しいフォルダに新しいクラスを作成することで問題を解決しました。新しいフォルダは役に立ちませんでした)。

シモンズ:私の場合、私はWebアプリケーションに取り組んでいましたが、この問題はさまざまな種類のプロジェクトで発生する可能性があります。

4
Ilia Anastassov

これは私のために働いた。あなたのクラスでは、クラス名が定義されている場所、例えば:パブリッククラスABC、1文字を削除し、少し待ちます。名前を変更したため、エラーリストが増えます。入力した文字を元に戻します。これは私のために働きました、うまくいけばそれはあなたのためにもうまくいくでしょう。がんばろう!!!

4
Sandeep Goundar

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

2
Bill

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

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

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

ブームシャンカー。

2
user595447

私はただ解決策を見つけたという奇妙なケースがありました。メインプロジェクトの "using"ステートメントの前に隠れた/空白文字がありました。そのプロジェクトはうまく構築でき、Webサイトはうまく機能しましたが、それを参照した単体テストプロジェクトは構築できませんでした。

2
Henry Fieger

私の場合は、VisualStudioの参照に三角形と感嘆符がこの画像として含まれています。

その後、私はそれを右クリックして削除し、再びDLLの参照を正しく追加し、問題は解決しました。

2
yu yang Jian

私は議論されたのと同じ問題を抱えていました:VS 2017はエラーとして参照されたプロジェクトのクラスを強調します、しかし解決策はうまくいっていてもインテリセンス作品さえ構築します。

これが私がどうやってこの問題を解決したかです:

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

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

実際には、Entity Version 6を使用していたエンドポイントのインターフェイスでWCFを使用してサービスにアクセスし、残りのプロジェクトはVersion 5を使用していました。NuGetを使用する代わりにそれらを異なってリストした。

例えばEntityFramework6.dllEntityFramework.dll.

私はそれからクライアントプロジェクトとプーフへの参照を追加しました、私のエラーは消えました。ほとんどの人がEntity Frameworkのバージョンを混在させることはないので、私はこれがEdgeのケースであることを認識しています。

1
djangojazz

私の場合、適切なソースフォルダにリストされていたが、ソリューションエクスプローラに登録されていなかったクラスがありました。私はプロジェクト> Add Existing itemを右クリックして手動でそれが見つからなかったと言ったそのクラスを選択しなければなりませんでした。それからすべてがうまくいった!

1
MPJ567

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

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

私の解決策をミックスに追加するのは少し違うので、理解するのにしばらく時間がかかりました。

私の場合は1つのプロジェクトに新しいクラスを追加しましたが、バージョン管理バインディングが設定されていないため、ファイルをVisual Studioの外部で(VCを介して)書き込み可能にする必要がありました。 Visual Studioで保存をキャンセルしましたが、VSの外部でファイルを書き込み可能にした後、VSでもう一度Save Allを押しました。これにより、誤って新しいクラスファイルがプロジェクトに保存されませんでした。ただし、ファイルを再コンパイルしようとしても見つからなかったにもかかわらず、参照元のプロジェクトでは有効であることがわかりました。タイプが見つかりませんエラー。 Visual Studioを閉じて開くと、まだ問題が発生していました(ただし、注意した場合、クラスファイルは再度開くと失われていました)。

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

1
Nick Gotch

同じエラーが発生した場合、私の話は次のようになりました。(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ファイルを開き、重複したエントリを削除しました。私の場合はうまくいきました。

1
Andrew Kotov

あなたはあなたが問題を抱えていると思っているコードを取り除き、それがそのコードへの参照なしでコンパイルされるかどうか見ることを試みるかもしれません。そうでなければ、それが再びコンパイルされるまで物事を修正し、そしてあなたの疑わしい問題コードを元に戻してください。他の何かが好きです。それが本当にハングアップしていることを修正すれば、これらの「ファントム」エラーは消えます。

1
user164226

私は同じ問題を抱えていました。ある晩、私のプロジェクトは翌朝のエラーをコンパイルします。

私は結局、そのビジュアルスタジオが私の参考文献のいくつかを「微調整」してそれらを他の場所に向けることにしたことを知りました。例えば:

System.ComponentModel.ISupportInitializeがどういうわけか "blahblah.System.ComponentModel.ISupportInitialize"になりました

あなたが私としての場合、vsがするべきかなり失礼なこと

1
user3784340

私の場合は、名前空間を別のプロジェクトとまったく同じに(意図的に)変更した後に、アセンブリ名もVSによって変更されたため、同じ名前のアセンブリが2つあり、一方が他方を上書きしています

1
user1121956

この問題を解決するには、関連する解決策の*.sln.DotSettingsファイルを削除して再作成するのも役立ちます。

私のケースはここで議論したのと同じですが、私が参照リストからSystem.Core参照を削除するまでそれを解決しませんでした(それなしでもすべてうまくいきました)

この問題はかなりイライラするのでそれが誰かに役立つことを願っています

0
yossico

ローカルマシン上で実行されている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 Assemblyであれば、DLLがmsbuildのアクセス可能な場所にあることを確認してください。

私はだまされてConsidered "Reference\bin\xxx.dll"と言うメッセージを見つけ、代わりにそこにdllをコピーしました。

0
Simon_Weaver

数年後、VS 2017 .NET Core 2.2 Razor Pagesを使用して、この答えが誰かを助けるかもしれないと感じています。それが蛇だったら、それは私を噛んでいたでしょう。物を投げたり、名前を変更したり、モデルの名前を変更したりすると、突然このエラーが発生しました。

エラーCS0246型または名前空間名 'UploadFileModel'が見つかりませんでした(usingディレクティブまたはアセンブリ参照がありませんか?)

これは、.chstml Razor Pageで赤の下線が引かれました。 (修正後に下線が引かれません):

@page
@model UploadFileModel

だから、最後に、そして幸運なことに、私は元々使用していた他の誰かからコードを見つけました、そして控えめに言っても、名前空間には.cshtmlファイル名が含まれていません!!!

ここに、名前空間にあるページ名を使った自分の悪いダミーエラーがあります。

namespace OESAC.Pages.UploadFile
{
    public class UploadFileModel : PageModel
    {

私の元のコードが持っていて、やらなければならなかったことは、名前空間UploadFileからページ名を削除することだけでした。

namespace OESAC.Pages
{
    public class UploadFileModel : PageModel
    {

そして、見よ、すべてのエラーが消えました!!愚かな私。しかし、ご存知のように、MSはこの.NET C#MVCをコンピューター以外の科学者にとって非常に混乱させています。モデル名、ページ名、およびそれらを使用する構文を把握しようとして、常に靴ひもにつまずいています。これは難しいことではありません。しかたがない。エラーと解決策が誰かを助けることを願っています。エラーは正しかった、「UploadFileModel」という名前空間はありません。

0
JustJohn

私はVS 2017コミュニティ版に取り組んでいて、CefSharp nugetパッケージについても同じ問題を抱えていました。

パッケージは正常にダウンロードされ、復元されました。プロジェクトは正常に構築され、実行されました - マークアップだけが名前空間が認識されなかったことを示しました。

私がしなければならなかったのはReferencesセクションを開いて黄色い感嘆符の1つをクリックすることだけでした。

enter image description here

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

enter image description here

0
Janis S.

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

0
Albert221

私の場合は、ソリューションのプロパティを調べ、両方のプロジェクトの[構成]で[ビルド]がチェックされていることを確認しました。私のメインプロジェクトはそれをチェックしていませんでした。

enter image description here

0
Trevor

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

なぜこれがうまくいったのかわかりません。

0
ZerosAndOnes

私はこのスレッドが古くなっていることを知っていますが、とにかく私が共有しているのですが、インポートされたアセンブリはNugetパッケージとして含まれていなかったのでその依存関係が欠けていたので.

このヘルプを飛ばす:)

0
Samih A

私の場合、外部の依存関係(xsd2code)でビルドされたファイルがあり、どういうわけかそのdesigner.csファイルはVSによって正しく処理されませんでした。 Visual Studioで新しいファイルを作成し、その中にコードを貼り付けることは私にとってはトリックでした。

0
Tanuki

AzureにWebサイトを公開しようとしたときにこのエラーが発生している人には、上記の有望な解決策のどれもが役に立ちませんでした。私は同じ船に乗っていた - 私の解決策はそれだけでうまく構築された。私はやらなければならなかった

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

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

0
Dan