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
処理する：
- ソリューションエクスプローラーでソリューションを右クリックし、[クリーンソリューション]を選択します。
- Visual Studioをシャットダウンする
- ShadowCacheフォルダーを削除する
- Visual Studioプロジェクトを再度開きました
- ソリューションを再構築する
そして、これ以上名前空間エラーはありません。
ビルドターゲットプラットフォームをx86に変更して、プロジェクトをビルドしてみてください。
Subversionを介して、明らかにプロジェクトビルドプラットフォームターゲットをx64に変更したことに気付きました。これが私が行った唯一の変更でした。その変更を行った後、コードはあなたが経験したのと同じエラーを表示し始める前に少しの間働いていました。プラットフォームターゲットをx86に変更してテストしましたが、突然デザイナーが作業を再開しました。その後、x64に戻したところ、問題は完全に解消されました。デザイナーが何らかのキャッシュコードをx32でビルドし、コードを変更するとx64ビルドプラットフォームを変更すると壊れるのではないかと思います。
私の場合、それはその他のコンパイルエラーが原因でした。他のエラーが解決されると、この一見関連するエラーもリストから削除されました。特に、エラーリストの下部および最近変更したページのエラー。
したがって、このエラーに直接注意を払うことはせず、最初はその他のエラーに注目してください。
これが誰にも役立つならダンノ
私はWPFを初めて使いますが、まだVB.netの初心者です。したがって、このエラーが発生するのは、サミットで愚かなことをしていることが原因であると考えていました。プロジェクトを共有ドライブからローカルドライブの1つに移動することで、それを取り除くことができました。エラーは消え、プロジェクトは問題なくコンパイルされます-まだ。 VS2015には、共有ドライブで保持されているプロジェクトにまだ問題があるようです。
プロジェクトがコンパイルされてもXAMLエラーが表示される場合の別の解決策かもしれません：
- ソリューションエクスプローラーで、xamlを含むプロジェクトノードで
- プロジェクトを右クリックして、「プロジェクトのアンロード」を選択します
- プロジェクトを右クリックして、「プロジェクトの再読み込み」を選択します。プロジェクトがまだ「スタートアッププロジェクト」として選択されていることを確認します。そうでない場合：
- プロジェクトを右クリックして、「スタートアッププロジェクトとして設定」を選択します
再構築する必要も、Visual Studioを閉じる必要もありません。
イエス...これは5年後のVisual Studio 2017でもまだ問題です。私はWPFを初めて使用しているので、問題はどういうわけか自分であると確信しましたが、すべてが正しくコンパイルされ実行されました。
再構築、クリーニング、再構築、x86/x64出力の切り替え、Windowsの再起動、ShadowCacheフォルダーのクリーニング、XML名前空間宣言への "; Assembly = {my main Assembly name}"の追加を試みましたが、何も機能しませんでした！したことはただ一つ：
静的なクラスのコマンド（私の場合、設計でWPFコマンドを検出することに関するものでした）を別のアセンブリに配置し、代わりにアセンブリ名をその名前に変更します。
.NET 4.6.2のWPFプロジェクトにVS 2015 Update 3を使用して、この問題が最近発生しました。プロジェクトのコピーはネットワークフォルダーにあり、ローカルに移動して問題を解決しました。
これは、VS 2015がネットワークパスを好まないように見えるため、他の種類の問題を解決する可能性があります。彼らにとって大きな問題である別の問題は、私のプロジェクトがネットワークパスにある場合にgitリポジトリを同期することであり、これもローカルに移動することで解決されます。
同じ問題がVisual Studios 2013、Service Pack 4を悩ませています。VisualStudios 2015 Previewでも同じ結果が得られました。
これは、Visual Studiosチームが修正していないWPFビジュアライザーの制限です。証明として、x86モードでビルドするとビジュアライザーが有効になり、x64モードでビルドすると無効になります。
奇妙なことに、インテリセンスはVisual Studio 2013、Service Pack 4で機能します。
私も同じ問題を抱えていました。私の場合、マークアップデザインビューからソリューションを再構築するように求められましたが、フォームレイアウトはDesign view is unavailable for x64 and ARM target platformsまたはBuild the Project to update Design viewで表示されませんでした。
ソリューションを再構築しても解決しません（デザインビューも「名前が名前空間に存在しません」エラーもありません）
ソリューション->プロパティ>構成プロパティの設定で遊んだからだと思います
私は最終的に2つの仕事で問題を解決しました：
- ページのビルド列のすべてのチェックボックスをオンにします：ソリューション->プロパティ->構成プロパティ
- ソリューション構成をDebugからReleaseに、またはその逆に変更します。
Visual Studio2012 Update 2のバグだと思います。
この問題は、さまざまな「トリック」によって解決されるようです。
私の場合、ソリューション内で取り組んでいたプロジェクトだけでなく、ソリューション全体を構築/再構築/クリーニングしていました。 [Build [my project]]をクリックすると、エラーメッセージが消えました。
私にとっての解決策は、アセンブリDLLのブロックを解除することでした。表示されるエラーメッセージはこれを示すものではありませんが、XAMLデザイナーは「サンドボックス」アセンブリと呼ばれるものの読み込みを拒否します。これは、ビルド時に出力ウィンドウで確認できます。インターネットからダウンロードされたDLLはブロックされます。サードパーティのアセンブリDLLのブロックを解除するには：
- WindowsエクスプローラーでDLLファイルを右クリックし、[プロパティ]を選択します。
- [全般]タブの下部にある[ブロック解除]ボタンまたはチェックボックスをクリックします。
注：DLLのブロックを解除するのは、安全であることが確実な場合のみ
アセンブリ参照を確認してください。プロジェクト参照に黄色の感嘆符がある場合、そこに問題があり、あらゆる種類のエラーが発生します。
プロジェクト参照が正しいことがわかっている場合は、ターゲットフレームワークを確認してください。たとえば、4.5フレームワークを使用するプロジェクトが4.5.2フレームワークを使用するプロジェクトを参照することは、適切な組み合わせではありません。
私の場合、問題はプロジェクトのobjディレクトリの下にあるいくつかのファントムファイルが原因でした。以下は私のために問題を修正しました：
- クリーンプロジェクト
- VSを終了
- rm -rf/obj/*
- VSを呼び出して再構築する
私の場合、ユーザーコントロールはメインプロジェクトに追加されました。上記のさまざまなソリューションを試してみましたが、役に立ちませんでした。無効なマークアップを取得しますが、ソリューションはコンパイルして動作するか、xmlns：c = "clr-namespace：MyProject; Assembly = MyProject"を追加してマークアップが表示されますが、コンパイルエラーが表示されます。タグはXML名前空間に存在しません。
最後に、新しいWPFユーザーコントロールライブラリプロジェクトをソリューションに追加し、ユーザーコントロールをメインプロジェクトからそのプロジェクトに移動しました。参照を追加し、新しいライブラリを指すようにアセンブリを変更し、最終的にマークアップが機能し、プロジェクトがエラーなしでコンパイルされました。
私はすべての答えを調べましたが、誰も助けてくれませんでした。最終的に自分で解決できたので、他の人に役立つかもしれないので答えを提示しました。
私の場合、ソリューションには2つのプロジェクトがあり、1つはモデルを含み（プロジェクトとアセンブリ名はModelsでした）、もう1つはビューとビューモデルを含んでいます（慣習に従って、プロジェクト、アセンブリ名、デフォルトの名前空間はModels.Monitor）でした。 Models.MonitorはModelsプロジェクトを参照しました。
Models.Monitorプロジェクトで、xamlの1つに次のネームスペースを含めました。xmlns：monitor = "clr-namespace：Models.Monitor"
MsBuildとVisual Studioは、アセンブリ 'Models'で 'Monitor'タイプを見つけようとしてエラーになっていたと思われます。解決するために、私は次のことを試しました：
- xmlns：monitor = "clr-namespace：Models.Monitor; Assembly ="-名前空間が https://msdn.Microsoft.com/en-us/library/ms747086と同じアセンブリにある場合に有効です（v = vs.110）.aspx
- 明示的な名前空間宣言も試みました：xmlns：monitor = "clr-namespace：Models.Monitor; Assembly = Models.Monitor"
上記のどちらも機能しませんでした。
最後に私はあきらめ、回避策として使用しようとしていたUserControlを別のネームスペースに移動しました： 'ModelsMonitor'。その後、問題なくコンパイルできました。
私は常にこの問題を抱えています。私のビューは、WPFカスタムコントロールライブラリプロジェクト（クラスライブラリのバリアント）にあります。ビルド済みのアセンブリを参照できますが、同じソリューションの別のプロジェクトのコードを参照できません。コードをxamlと同じプロジェクトに移動するとすぐに、認識されます。
私の場合、名前空間とクラスのスペルはまったく同じでした。たとえば、私の名前空間の1つは
firstDepth.secondDepth.Fubar
独自のクラス（例：firstDepth.secondDepth.Fubar.someclass）を含む
しかし、名前空間に 'Fubar'クラスもありました
firstDepth.secondDepth
上記のFubar名前空間と同じテキストに解決されます。
これをしないでください
ソリューションプロパティページで、「UpdatingMediaElement」を含むアセンブリのプラットフォームと、「UpdatingMediaElement」がサブクラス化または実装するスーパークラスとインターフェイスのいずれかを含むアセンブリを確認します。これらすべてのアセンブリのプラットフォームは「AnyCPU」でなければならないようです。
VB.NETは、C＃のようにフォルダー構造に基づいて名前空間情報を自動的に追加しません。私はあなたと同じチュートリアル（Teach Yourself WPFを24時間で）を経て、VBへの同じ変換を行っていると思います。
名前空間を使用するには、名前空間情報をBothXAMLクラスとXAML.VBコードビハインドに手動で追加する必要があることがわかりました本。それでも、VBは、VBのように名前空間をアセンブリに自動的に割り当てません。
ここにプロジェクトテンプレートにこれを含める方法を示す別の記事があり、名前空間情報を自動的に構築します- 新しいアイテムを追加するときに名前空間を自動的に追加する
別の考えられる原因：ビルド後のイベントがプロジェクトDLLをビルドフォルダーから削除しています。
明確にするために、WPFデザイナーは、名前が名前空間に存在し、プロジェクトが正常にビルドおよび実行される場合でも、「名前XXXは名前空間に存在しません...」と報告する場合がありますif a post-ビルドイベントは、プロジェクトDLLをビルドフォルダー（bin\Debug、bin\Releaseなど）から削除します。 Visual Studio 2015でこれを個人的に経験しています。
また、プロジェクト->プロパティを右クリックし、プラットフォームターゲットを任意のCPUに変更して再構築してみてください。これは私のために働いた
この問題は、参照しているアセンブリが実際にビルドされていない場合にも発生する可能性があります。たとえば、xamlがAssembly1にあり、Assembly1のクラスも参照しているが、そのAssemblyにエラーがあり、ビルドしていない場合、このエラーが表示されます。
私はそれについて馬鹿げていると感じますが、私の場合、ユーザーコントロールをばらばらに引き裂いて、結果として関連するクラスであらゆる種類のエラーが発生しました。それらをすべて修正しようとしていたので、xamlがこれらの参照を見つけるためにビルドされたアセンブリに依存していることに気づかずに、問題のエラーから始めました（ビルドする前でも解決できるc＃/ vbコードとは異なります）。
私もこれで多くの問題を抱えています！ Intellisenseは名前空間とすべてを完成させるのに役立ちますが、コンパイラは泣き叫びます。このスレッドや他のスレッドで見つけたものをすべて試しました。しかし、私の場合、最後に役立ったのは次のようなものを書くことでした：xmlns：util = "clr-namespace：LiveSpielTool.Utils; Assembly ="
アセンブリ名を空のままにします。理由はわかりません。しかし、それはここで言及されました。アセンブリを開発しているので、アセンブリ属性が意味をなさないように追加する必要があります。しかし、アセンブリ名の入力は機能しませんでした。とても奇妙。
私の場合、wpfプログラムのアーキテクチャが依存関係とまったく同じではない場合に、この問題が発生します。 x64の依存関係と、AnyCPUの依存関係があるとします。次に、x64を選択した場合、AnyCPU dllのタイプは「存在しません」、そうでない場合、x64 dllのタイプは「存在しません」。両方をエミレートすることはできません。
私はアセンブリをプロジェクトとして追加しました-最初にdllへの参照に特に追加されたddlを削除しました-それをしました。
このスレッドの2つのアイデアの組み合わせが役立ったので、この問題が続く5年間で他の人に役立つことを期待して、私がやったことを投稿します。私はVS2017コミュニティを使用しています）
- Dllへの参照を削除します
- クリーン、リビルド、ビルド
- VSを閉じ、dllのブロックを解除します（下記の注を参照）、シャドウキャッシュを削除します
- VSを開き、クリーン、リビルド、ビルド
- Dllへの参照を復元する
- クリーン、リビルド、ビルド
ステップ2、4、および6で注文が正確に正しくない場合がありますが、この問題で2時間近く費やした後、ストローを把握していました。私にとっての鍵は、参照の削除、dllのブロック解除、シャドウキャッシュの削除の組み合わせだったと思います。
（ステップ3の注-使用しているDLLは私の同僚/メンターによって作成されたため、安全であることがわかっています。DLLのソースがわからない場合はこのステップに注意してください） =
MSはこのようなものをクリーンアップする意欲がないように見えるので、このスレッドを後世にブックマークします。 WPFはそれ自体で学習するのに十分困難であり、すべてを正しく行ったときにこのようなものをハックしなければならないのは腹立たしいことです。 ????????????
ソリューションをネットワーク共有に保存し、それを開くたびに、信頼できないソースに関する警告が表示されました。ローカルドライブに移動すると、「名前空間が存在しません」というエラーもなくなりました。
山に追加します。
私のWPFアプリケーションのアセンブリ名は、参照されたdllと同じアセンブリ名でした。したがって、どのプロジェクトにもアセンブリ名が重複していないことを確認してください。
残念ながら、これらのヒントはどれも役に立たなかった。私は最終的に問題を解決することができました。 Visual Studioはネットワークドライブとうまく連携していないようです。プロジェクトを共有ドライブからローカルに移動して再コンパイルすることで、この問題を解決しました。これ以上のエラーはありません。