私は:
タイプまたはネームスペース名が見つかりませんでした
vS2010でのC#WPFアプリのエラー。この部分のコードは正常にコンパイルされていましたが、突然このエラーが発生します。プロジェクトリファレンスとusing
ステートメントを削除し、VS2010を閉じて再起動しようとしましたが、それでも私はこの問題を抱えています。
なぜこれが起きているのか、Reference&using
文について正しいことをしているように思われる場合は、どのようなアイデアがありますか。
私はまたVS2010でその名前空間に対するインテリセンスはうまくいっていることに注意しました、それでそれはVS2010がプロジェクト参照を持ちそして一方で名前空間を見ているように思えます、しかしコンパイルの間それを見ない?
これは、2つのプロジェクト間の.NET Frameworkバージョンの非互換性の結果である可能性があります。
それは2つの方法で起こる可能性があります。
例えば、アプリケーションが.Net 4 Client Profileフレームワークをターゲットとするように設定されていて、それが参照するプロジェクトが完全な.Net 4フレームワークをターゲットとするように設定されている場合に起こります。
それを明確にするために:
この場合の解決策は、アプリケーションのフレームワークターゲットをアップグレードするか(プロジェクト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
ソリューションを構築するとき、私は同じエラーを受けていました(タイプまたは名前空間 ''が見つかりませんでした)。その下「参照を解決できませんでした」と「アセンブリがディスク上に存在する」ことを確認するための警告が表示されました。
私のDLLは、参照が指している場所にはっきりと表示されていたので、私は非常に混乱しました。ソリューションを構築しようとするまで、VSはエラーを強調していないようでした。
私はついにその問題に気づいた(あるいは少なくとも私がその問題であると疑ったもの)。私は同じ解決策でライブラリファイルを構築していました。ディスク上に存在していたとしても、それはその場所で再構築されていました(どういうわけか私の他のプロジェクトを再構築する過程で - 同じ解決策で - ライブラリを参照したライブラリは存在しないことを決定したに違いありません)
プロジェクト全体を右クリックして、ソリューション全体ではなくそれだけをビルドしても、エラーにはなりませんでした。
この問題を解決するために、ライブラリをそれを使用していたプロジェクトへの依存関係として追加しました。
これをする:
これにより、ライブラリプロジェクトが最初に構築されます。
なぜこれがうまくいったのか私にはわかりませんが、私はVS2015がそれを見つけることができないと言っていたというプロジェクト参照を削除し、それを再び追加しました。問題を解決しました。私は役に立ちませんでしたVSのクリーニング、構築、そして再起動の両方を試してみました。
まず、私はあなたのプロジェクトが生成した情報が破損していないことを確認します。ソリューションをクリーンにして再構築します。
それでも問題が解決しない場合は、デザイナーの問題に関して過去に作業を確認したことの1つは、Windowsフォームプロジェクトを開いてからもう一度閉じることです。これはちょっとチキン - 内臓風のようですが、息を止めないでください。
私が遭遇したよりトリッキーな状況は、次のとおりです。プロジェクト1は、Microsoft.Bcl.Async
パッケージがインストールされた4.0フルフレームワークをターゲットとしています。プロジェクト2は、4.0フルフレームワークを対象としていますが、プロジェクト1クラスを参照するときにコンパイルされません。
2番目のプロジェクトにAsync NuGetパッケージをインストールすると、それはうまくコンパイルされました。
私は同じような問題を抱えていました:コンパイラは同じプロジェクト内のフォルダを検出できませんでした、そのフォルダへのusingディレクティブリンクはエラーを生成しました。私の場合、問題はフォルダの名前変更に由来します。そのフォルダ内のすべてのクラスのネームスペースを更新したにもかかわらず、プロジェクト情報が更新されませんでした。私はすべてを試しました:.suoファイルとbinとobjフォルダを削除すること、解決策をきれいにすること、プロジェクトをリロードすること - 何も助けになりませんでした。 フォルダとその中のクラスを削除し、新しいフォルダを作成し、その新しいフォルダに新しいクラスを作成することで問題を解決しました。新しいフォルダは役に立ちませんでした)。
シモンズ:私の場合、私はWebアプリケーションに取り組んでいましたが、この問題はさまざまな種類のプロジェクトで発生する可能性があります。
これは私のために働いた。あなたのクラスでは、クラス名が定義されている場所、例えば:パブリッククラスABC、1文字を削除し、少し待ちます。名前を変更したため、エラーリストが増えます。入力した文字を元に戻します。これは私のために働きました、うまくいけばそれはあなたのためにもうまくいくでしょう。がんばろう!!!
既存のプロジェクトをVS2008からVS2012にアップグレードするときにこの問題が発生しました。 2つのプロジェクト(私が作成した2つのプロジェクトのみ)が異なる.Net Framework(3.5と4.0)をターゲットにしていることがわかりました。両方のプロジェクトの[ターゲットフレームワーク]ボックスに「.NET Framework 4」が表示されていることを確認して、プロジェクトの[アプリケーション]タブでこれを解決しました。
[Facepalm]私の問題は、C++の方法で依存関係を追加したことです。
ビルドしないプロジェクトに移動し、ソリューションエクスプローラーで[参照設定]フォルダーを開き、依存関係が一覧に含まれているかどうかを確認します。
そうでない場合は、[参照を追加]をクリックして[プロジェクト]タブで依存関係を選択できます。
ブームシャンカー。
私はただ解決策を見つけたという奇妙なケースがありました。メインプロジェクトの "using"ステートメントの前に隠れた/空白文字がありました。そのプロジェクトはうまく構築でき、Webサイトはうまく機能しましたが、それを参照した単体テストプロジェクトは構築できませんでした。
私は議論されたのと同じ問題を抱えていました:VS 2017はエラーとして参照されたプロジェクトのクラスを強調します、しかし解決策はうまくいっていてもインテリセンス作品さえ構築します。
これが私がどうやってこの問題を解決したかです:
私はこれが死んだ馬を蹴っていることを知っていますが、私はこのエラーとどこで問題ないフレームワークを持っていました。私の問題は基本的にインターフェースが見つからないことを述べていましたが、それでも構築とアクセスは問題ありません。それで、私は「他の人がうまく働いているのに、どうしてこのインターフェースだけなのか」と考え始めました。
実際には、Entity Version 6を使用していたエンドポイントのインターフェイスでWCFを使用してサービスにアクセスし、残りのプロジェクトはVersion 5を使用していました。NuGetを使用する代わりにそれらを異なってリストした。
例えばEntityFramework6.dllとEntityFramework.dll.
私はそれからクライアントプロジェクトとプーフへの参照を追加しました、私のエラーは消えました。ほとんどの人がEntity Frameworkのバージョンを混在させることはないので、私はこれがEdgeのケースであることを認識しています。
私の場合、適切なソースフォルダにリストされていたが、ソリューションエクスプローラに登録されていなかったクラスがありました。私はプロジェクト> Add Existing itemを右クリックして手動でそれが見つからなかったと言ったそのクラスを選択しなければなりませんでした。それからすべてがうまくいった!
このイベントはVisual Studio 2017で発生します。
私の解決策をミックスに追加するのは少し違うので、理解するのにしばらく時間がかかりました。
私の場合は1つのプロジェクトに新しいクラスを追加しましたが、バージョン管理バインディングが設定されていないため、ファイルをVisual Studioの外部で(VCを介して)書き込み可能にする必要がありました。 Visual Studioで保存をキャンセルしましたが、VSの外部でファイルを書き込み可能にした後、VSでもう一度Save Allを押しました。これにより、誤って新しいクラスファイルがプロジェクトに保存されませんでした。ただし、ファイルを再コンパイルしようとしても見つからなかったにもかかわらず、参照元のプロジェクトでは有効であることがわかりました。タイプが見つかりませんエラー。 Visual Studioを閉じて開くと、まだ問題が発生していました(ただし、注意した場合、クラスファイルは再度開くと失われていました)。
これに気付いたら、修正は簡単でした。プロジェクトファイルを書き込み可能に設定し、足りないファイルをプロジェクトに追加しました。すべて正常にビルドされました。
同じエラーが発生した場合、私の話は次のようになりました。(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ファイルを開き、重複したエントリを削除しました。私の場合はうまくいきました。
あなたはあなたが問題を抱えていると思っているコードを取り除き、それがそのコードへの参照なしでコンパイルされるかどうか見ることを試みるかもしれません。そうでなければ、それが再びコンパイルされるまで物事を修正し、そしてあなたの疑わしい問題コードを元に戻してください。他の何かが好きです。それが本当にハングアップしていることを修正すれば、これらの「ファントム」エラーは消えます。
私は同じ問題を抱えていました。ある晩、私のプロジェクトは翌朝のエラーをコンパイルします。
私は結局、そのビジュアルスタジオが私の参考文献のいくつかを「微調整」してそれらを他の場所に向けることにしたことを知りました。例えば:
System.ComponentModel.ISupportInitializeがどういうわけか "blahblah.System.ComponentModel.ISupportInitialize"になりました
あなたが私としての場合、vsがするべきかなり失礼なこと
私の場合は、名前空間を別のプロジェクトとまったく同じに(意図的に)変更した後に、アセンブリ名もVSによって変更されたため、同じ名前のアセンブリが2つあり、一方が他方を上書きしています
この問題を解決するには、関連する解決策の*.sln.DotSettings
ファイルを削除して再作成するのも役立ちます。
私のケースはここで議論したのと同じですが、私が参照リストからSystem.Core
参照を削除するまでそれを解決しませんでした(それなしでもすべてうまくいきました)
この問題はかなりイライラするのでそれが誰かに役立つことを願っています
ローカルマシン上で実行されている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をコピーしました。
数年後、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」という名前空間はありません。
私の場合は、ソリューションに2つのプロジェクトがあり、参照プロジェクトにサブ名前空間を追加しましたが、ビルド時に参照プロジェクトのビルドが失敗したことに気付かず、最後のビルドに成功この新しい名前空間を持っているので、エラーは正しかった、存在しなかったので見つけることができなかった。解決策は明らかに参照されたプロジェクトのエラーを修正することだった。
私の場合、参照としてdllを追加するとtype or namespace name could not be found
エラーが発生しました。ただし、dllファイルを直接binフォルダにコピーして貼り付けると、エラーが解決しました。
なぜこれがうまくいったのかわかりません。
私はこのスレッドが古くなっていることを知っていますが、とにかく私が共有しているのですが、インポートされたアセンブリはNugetパッケージとして含まれていなかったのでその依存関係が欠けていたので.
このヘルプを飛ばす:)
私の場合、外部の依存関係(xsd2code)でビルドされたファイルがあり、どういうわけかそのdesigner.csファイルはVSによって正しく処理されませんでした。 Visual Studioで新しいファイルを作成し、その中にコードを貼り付けることは私にとってはトリックでした。
AzureにWebサイトを公開しようとしたときにこのエラーが発生している人には、上記の有望な解決策のどれもが役に立ちませんでした。私は同じ船に乗っていた - 私の解決策はそれだけでうまく構築された。私はやらなければならなかった
少し痛いですが、私のWebサイトをAzureに公開できる唯一の方法でした。