XAMLの名前空間エラーに名前が存在しません

VB.NET WPFアプリケーションで動作するVS2012の使用。WPFの学習に使用しているシンプルなMusicPlayerチュートリアルアプリがあります。チュートリアルのC＃バージョンをVB.NETに段階的に変換しています。

アプリには2つのクラスがあり、どちらも同じ名前空間の下にあります。XAMLで名前空間を参照できますが、XAMLでクラスオブジェクトを参照しようとすると、エラーが発生し、コンパイルできません。

奇妙なことに、IntelliSenseは、xmlns：c =タグを介して名前空間を参照する場合と、クラスオブジェクトを使用してクラスオブジェクトを入力する場合の両方で正常に機能し <c: ますが、オブジェクトに下線が引かれ、エラーが生成されてデザイナーでビルドまたは作業しようとします。

.vbクラスファイルは、\ Controlsというフォルダーにあります。メインプロジェクトのルート名前空間は、意図的に空白にされています。クラスは次のようにコーディングされています...

Namespace MusicPlayer.Controls
    Public Class UpdatingMediaElement
       .... code here
    End Public
End Namespace

xamlは次のようになります

（<Window >タグで定義された名前空間

xmlns:c="clr-namespace:MusicPlayer.Controls"

（で定義されたオブジェクト<Grid>）

  <c:UpdatingMediaElement Name="MyMediaElement" />

（エラー表示）名前 "UpdatingMediaElement"が名前空間 "clr-namespace：MusicPlayer.Controls"に存在しません。

何が悪いのか、それをどのように修正するのかわかりませんか？

wpfコードとVSを作成しているときに、「名前ABCDEが名前空間clr-namespace：ABCに存在しない」と伝えます。ただし、プロジェクトを完全に正常にビルドできます。UIの設計が表示されない（または単にコードをクリーンアップしたい）ため、わずかな不便があります。

これらを実行してみてください：

• VSで、ソリューション->プロパティ->構成プロパティを右クリックします。

• 新しいダイアログが開きます。プロジェクト構成をデバッグからリリースに、またはその逆に変更してみてください。

その後、ソリューションを再構築します。それはあなたの問題を解決することができます。

アセンブリがクラスが含まれている名前空間と異なる場合は、明示的に指定する必要があります。

例：-

xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"

この問題は、Xaml Design Shadow Cacheをクリアすることで解消されました。Visual Studio 2015 Update 1で問題が発生しました。

Visual Studio 2015では、キャッシュは次の場所にあります。

%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache

処理する：

1. ソリューションエクスプローラーでソリューションを右クリックし、[ソリューションのクリーン]を選択します
2. Visual Studioをシャットダウンする
3. ShadowCacheフォルダーを削除する
4. Visual Studioプロジェクトを再開
5. ソリューションを再構築する

また、名前空間エラーはなくなりました。

私の場合、他のコンパイルエラーが原因でした。他のエラーが解決されると、この一見関連のあるエラーもリストから削除されました。特に、エラーリストの下部と最近変更したページのエラー。

したがって、このエラーに直接注意を払い、最初は他のエラーに集中しないでください。

ビルドターゲットプラットフォームをx86に変更して、プロジェクトをビルドしてみてください。

Subversionを介して、プロジェクトのビルドプラットフォームターゲットをx64に変更したようです。これが私が行った唯一の変更でした。その変更を行った後、コードはあなたが経験したのと同じエラーを表示し始める前の少しの間機能していました。テストするためにプラットフォームターゲットをx86に変更したところ、突然デザイナーが再び作業を始めました。その後、x64に戻したところ、問題は完全になくなりました。デザイナーがx32でキャッシュされたある種のコードをビルドし、x64ビルドプラットフォームを変更すると、コードを変更したときにそれが壊れると思います。

これが他の人を助けるならDunno

私はWPFの初心者であり、まだVB.netの初心者です。つまり、このエラーが発生するのは、私がサミットをばかげたことによって引き起こされたものだと思っていました。プロジェクトを共有ドライブからローカルドライブの1つに移動することで、なんとかそれを取り除くことができました。エラーはなくなり、プロジェクトは完全にコンパイルされますが、それ以上の問題はありません。VS2015では、共有ドライブに保持されているプロジェクトにまだ問題があるようです。

プロジェクトがコンパイルされてもXAMLエラーが表示される場合の別の解決策：

1. ソリューションエクスプローラーで、xamlを含むプロジェクトノード
2. プロジェクトを右クリックし、「プロジェクトのアンロード」を選択します
3. プロジェクトを右クリックして[プロジェクトの再読み込み]を選択します。プロジェクトが「スタートアッププロジェクト」として選択されていることを確認してください。そうでない場合：
4. プロジェクトを右クリックし、「スタートアッププロジェクトとして設定」を選択します。

再構築したり、ビジュアルスタジオを閉じたりする必要はありません。

イエス様...これはVisual Studio 2017で5年経ってもまだ問題です。WPFを初めて使用したので、問題はどういうわけか私にあると確信していましたが、すべてが正しくコンパイルおよび実行されました。

再構築、クリーニング、再構築、x86 / x64出力の切り替え、Windowsの再起動、ShadowCacheフォルダーのクリーニング、XML名前空間宣言への「; assembly = {メインアセンブリ名}」の追加を試みましたが、何も機能しませんでした。行った唯一のこと：

私の静的クラスのコマンド（私の場合、デザインは私のWPFコマンドを検出させることでした）を別のアセンブリに入れ、代わりにアセンブリ名を変更します。

同じ問題がありました。私の場合、マークアップデザインビューでソリューションを再構築するように求められ、フォームレイアウトが次のメッセージとともに表示されませんでした： Design view is unavailable for x64 and ARM target platformsまたはBuild the Project to update Design view。

ソリューションを再構築しても解決されません（デザインビューも「名前が名前空間に存在しません」エラーも）

私はソリューション->プロパティ>構成プロパティの設定で遊んだためだと思います

私は最終的に2つのジョブで問題を解決しました：

1. ページの[Build Column]ですべてのチェックボックスをオンにする：ソリューション->プロパティ->構成プロパティ
2. ソリューション構成をデバッグからリリースに、またはその逆に変更します。

Visual Studio2012 Update 2のバグだと思います。

同じ問題がVisual Studios 2013、Service Pack 4を悩ませています。VisualStudios 2015 Previewでも同じ結果で試してみました。

これは、Visual Studioチームが修正していないWPFビジュアライザーの制限にすぎません。証明として、x86モードでビルドするとビジュアライザーが有効になり、x64モードでビルドすると無効になります。

奇妙なことに、IntelliSenseはVisual Studios 2013、Service Pack 4で動作します。

最近、.NET 4.6.2のWPFプロジェクトにVS 2015 Update 3を使用してこの問題が発生しました。プロジェクトのコピーはネットワークフォルダにありましたにありました。ローカルに移動し、問題を解決しました。

これは、VS 2015がネットワークパスを好まないように見えるため、他の種類の問題を解決する可能性があります。彼らにとって大きな問題であるもう1つの問題は、プロジェクトがネットワークパスにある場合にgitリポジトリを同期することです。これもローカルに移動することで解決します。

この問題はさまざまな「トリック」によって解決できるようです。

私の場合、ソリューション内で作業していたプロジェクトだけでなく、ソリューション全体をビルド/再構築/クリーンアップしていました。[Build [my project]]をクリックすると、エラーメッセージが消えました。

アセンブリ参照を確認してください。プロジェクト参照に黄色の感嘆符がある場合、そこに問題があり、あらゆる種類のエラーが発生します。

プロジェクト参照が正しいことがわかっている場合は、ターゲットフレームワークを確認してください。たとえば、4.5フレームワークを使用するプロジェクトが4.5.2フレームワークのプロジェクトを参照することは、適切な組み合わせではありません。

私の解決策は、アセンブリDLLのブロックを解除することでした。表示されるエラーメッセージはこれを示していませんが、XAMLデザイナーは「サンドボックス化された」アセンブリと呼ばれるものの読み込みを拒否しています。これは、ビルド時に出力ウィンドウに表示されます。DLLは、インターネットからダウンロードされるとブロックされます。サードパーティのアセンブリDLLのブロックを解除するには：

1. WindowsエクスプローラーでDLLファイルを右クリックし、[プロパティ]を選択します。
2. [全般]タブの下部にある[ブロックを解除]ボタンまたはチェックボックスをクリックします。

注：DLLが安全であると確信している場合のみ、DLLのブロックを解除してください。

私の場合、ユーザーコントロールはメインプロジェクトに追加されました。上記のさまざまな解決策を試しても無駄になりました。無効なマークアップが表示されてもソリューションがコンパイルされて機能するか、xmlns：c = "clr-namespace：MyProject; assembly = MyProject"を追加してマークアップが表示されますが、コンパイルエラーが発生します。タグはXML名前空間に存在しません。

最後に、新しいWPFユーザーコントロールライブラリプロジェクトをソリューションに追加し、ユーザーコントロールをメインプロジェクトからそのプロジェクトに移動しました。参照を追加し、新しいライブラリを指すようにアセンブリを変更し、最後にマークアップが機能し、プロジェクトがエラーなしでコンパイルされました。

私はすべての答えを調べましたが、どれも助けになりませんでした。ようやく自分で解決できたので、他の人の役に立つかもしれないので答えを提示しました。

私の場合、ソリューションには2つのプロジェクトがあり、1つはモデルを含み（たとえば、プロジェクトとアセンブリの名前はModelsでした）、もう1つはビューとビューモデルを含みます（規則に従って：プロジェクト、アセンブリ名、デフォルトの名前空間はModels.Monitorでした）） 。Models.MonitorはModelsプロジェクトを参照しました。

Models.Monitorプロジェクトで、いずれかのxamlに次の名前空間を含めました：xmlns：monitor = "clr-namespace：Models.Monitor"

私はと思われる、彼らはアセンブリ「モデル」の「モニタ」タイプを見つけるしようとしていたとしてMSBuildのとVisual Studioが続いてerroringました。解決するには、次のことを試しました。

1. xmlns：monitor = "clr-namespace：Models.Monitor; assembly ="-名前空間がhttps://msdn.microsoft.com/en-us/library/ms747086(v=vsと同じアセンブリにある場合に有効です。 .110）.aspx
2. 明示的な名前空間宣言も試しました：xmlns：monitor = "clr-namespace：Models.Monitor; assembly = Models.Monitor"

上記のどちらも機能しませんでした。

最後に私はあきらめ、回避策としてUserControlを別の名前空間 'ModelsMonitor'に使用しようとしていました。その後は問題なくコンパイルできました。

私の場合、名前空間とクラスのスペルはまったく同じでした。たとえば、私の名前空間の1つは

firstDepth.secondDepth.Fubar

独自のクラスが含まれています（例：firstDepth.secondDepth.Fubar.someclass）

しかし、私もありました名前空間に Fubar 'クラスもありました

firstDepth.secondDepth

上記のFubar名前空間と同じテキストに解決されます。

これをしないでください

私の場合、問題はプロジェクトのobjディレクトリにあるいくつかのファントムファイルが原因でした。次は私のために問題を修正しました：

• クリーンプロジェクト
• VSを終了
• rm -rf / obj / *
• VSを起動して再構築

私もこれで大変です！Intellisenseは、名前空間とすべてを完成させるのに役立ちますが、コンパイラは泣きます。私はこれと他のスレッドで見つけたすべてを試しました。しかし私の場合、結局助けになったのは次のようなものを書くことでした：

xmlns:util="clr-namespace:LiveSpielTool.Utils;assembly="

アセンブリ名を空のままにします。なぜだかわかりません。しかし、それはここで言及されました。アセンブリを開発していることを追加する必要があるため、アセンブリ属性が意味をなす場合があります。しかし、アセンブリ名を入力しても機能しませんでした。とても奇妙。

VB.NETは、C＃の場合のように、フォルダー構造に基づいて名前空間情報を自動的に追加しません。私はあなたと同じチュートリアル（Teach Yourself WPF in 24 Hours）を行っており、VBへの同じ変換を行っていると思います。

本の説明に従って名前空間を使用できるようにするには、名前空間情報をXAMLクラスとXAML.VBコードビハインドの両方に手動で追加する必要があることがわかりました。それでも、VBはVBの場合のように、名前空間をアセンブリに自動的に割り当てません。

これをプロジェクトテンプレートに含める方法を示す別の記事がここにあります。これにより、名前空間情報が自動的に構築されます- 新しいアイテムを追加するときに名前空間を自動的に追加します

ソリューションのプロパティページで、「UpdatingMediaElement」を含むアセンブリのプラットフォームと、「UpdatingMediaElement」がサブクラス化または実装するスーパークラスとインターフェイスを含むアセンブリを確認します。これらすべてのアセンブリのプラットフォームは「AnyCPU」でなければならないようです。

別の考えられる原因：ビルド後のイベントは、ビルドDLLからプロジェクトDLLを削除しています。

明確にするために：WPFデザイナーは、名前XXXが名前空間に存在しない場合でも報告することがあります。名前が名前空間に存在し、ビルド後のイベントによってプロジェクトDLLが削除された場合、プロジェクトは正常にビルドおよび実行されます。ビルドフォルダー（bin \ Debug、bin \ Releaseなど）。私はVisual Studio 2015でこれを個人的に経験しています。

はい、残念ながら、これらのヒントはどれもうまくいきませんでした。私は最終的に問題を解決することができました。Visual Studioはネットワークドライブでうまく機能しないようです。プロジェクトを共有ドライブからローカルに移動してこの問題を解決し、再コンパイルしました。エラーはもうありません。

パイルに追加します。

私のWPFアプリケーションのアセンブリ名は、参照されたdllと同じアセンブリ名でした。したがって、どのプロジェクトでもアセンブリ名が重複していないことを確認してください。

ソリューションをネットワーク共有に保存し、それを開くたびに信頼できないソースに関する警告が表示されました。ローカルドライブに移動したところ、「名前空間が存在しません」というエラーも消えました。

また、プロジェクト->プロパティを右クリックして、プラットフォームターゲットを任意のCPUに変更して再構築すると、機能します。これは私のために働いた

この問題は、参照しているアセンブリが実際にビルドされていない場合にも発生する可能性があります。たとえば、xamlがAssembly1にあり、Assembly1でもクラスを参照しているが、そのアセンブリにエラーがあり、ビルドしていない場合、このエラーが表示されます。

私はそれについてばかげていると思いますが、私の場合、ユーザーコントロールを引き裂き、結果として関連するクラスにあらゆる種類のエラーがありました。私がそれらすべてを修正しようとしていたとき、問題のエラーから始めましたが、xamlがこれらの参照を見つけるためにビルドされたアセンブリに依存していることを認識していませんでした（ビルドする前でも機能するc＃/ vbコードとは異なります）。

私はアセンブリをプロジェクトとして追加しました-最初に具体的にdllへの参照に追加されたddlを削除しました-それを行いました。

私はいつもこの問題を抱えています。私のビューは、WPFカスタムコントロールライブラリプロジェクト（クラスライブラリのバリアント）にあります。ビルド済みのアセンブリを参照できますが、同じソリューションの別のプロジェクトのコードを参照できません。コードをxamlと同じプロジェクトに移動するとすぐに、コードが認識されます。

私の場合、この問題は、wpfプログラムのアーキテクチャが依存関係とまったく同じでない場合に発生します。x64である依存関係が1つあり、もう1つはAnyCPUであるとします。次に、x64を選択すると、AnyCPU dllのタイプは「存在しません」、そうでなければ、x64 dllのタイプは「存在しません」。両方をエミレートすることはできません。