使用VS2012在VB.NET WPF应用程序上工作。我有一个简单的MusicPlayer教程应用程序，我用来学习WPF。我正在逐步将C＃版本的教程转换为VB.NET。
它在应用程序中有两个类，它们都在同一名称空间下。我能够在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设计（或者只是想清理代码）。
尝试这样做：
之后，重新构建您的解决方案。它可以解决您的问题。
同样的问题困扰着Visual Studios 2013，Service Pack 4.我也尝试使用Visual Studios 2015 Preview获得相同的结果。
这只是Visual Studio团队尚未修复的WPF可视化工具的限制。作为证据，在x86模式下构建可视化器并在x64模式下构建会禁用它。
奇怪的是，intellisense适用于Visual Studios 2013 Service Pack 4。
我最近在.NET 4.6.2中使用VS 2015 Update 3来解决我的WPF项目。我的项目副本位于网络文件夹中，我在本地移动它，这解决了问题。
这可能会解决其他类型的问题，因为看起来VS 2015不喜欢网络路径。另一个对他们来说是一个大问题的问题是如果我的项目在网络路径中同步git存储库，也可以通过在本地移动它来解决。
看起来这个问题可以通过各种“技巧”来解决。
就我而言，我一直在构建/重建/清理整个解决方案，而不仅仅是我在解决方案中工作的项目。一旦我点击“Build [my project]”，错误消息便消失了。
我的解决方案是解除阻塞程序集DLL。您获得的错误消息并未表明这一点，但XAML设计器拒绝加载它所谓的“沙盒”程序集。您可以在构建时在输出窗口中看到这一点。如果从Internet下载DLL，则会阻止它们。要取消阻止您的第三方程序集DLL：
注意：如果您确定它们是安全的，则只能解除阻止。
在我的例子中，用户控件已添加到主项目中。我尝试了上面的各种解决方案无济于事。要么我会得到无效标记，但解决方案将编译和工作，或者我将添加xmlns：c =“clr-namespace：MyProject; assembly = MyProject”然后标记将显示，但我会得到一个编译错误， XML命名空间中不存在标记。
最后，我在解决方案中添加了一个新的WPF用户控件库项目，并将我的用户控件从主项目移到了那个项目中。添加了引用并更改了程序集以指向新库，最后标记工作并且项目编译时没有错误。
我经历了所有的答案，没有人帮助过我。最后能够自己解决，所以提出答案，因为它可能会帮助其他人。
在我的例子中，解决方案有两个项目，一个包含模型（比如项目和程序集名称是Models），另一个包含视图和视图模型（根据我们的约定：项目，程序集名称和默认名称空间是Models.Monitor） 。 Models.Monitor引用了Models项目。
在Models.Monitor项目中，在其中一个xaml中包含以下命名空间：xmlns：monitor =“clr-namespace：Models.Monitor”
我怀疑MsBuild和Visual Studio是错误的，因为他们试图在程序集“模型”中找到“监视器”类型。为了解决我尝试了以下内容：
以上都没有奏效。
最后我放弃了，并且随着工作的推移移动了UserControl，我试图使用另一个命名空间：'ModelsMonitor'。之后我就能编好了。
在我的情况下，问题是由于项目的obj目录下的一些幻像文件。以下为我解决了这个问题：
VB.NET不会像在C＃中那样自动添加基于文件夹结构的命名空间信息。我想我正在和你一样学习（24小时内自学WPF），并进行相同的VB转换。
我发现您必须手动将命名空间信息添加到XAML类和后面的XAML.VB代码中，以便能够使用本书中所述的命名空间。即使这样，VB也不会像在VB中那样自动将命名空间分配给程序集。
这里有另一篇文章展示了如何在项目模板中包含它，以便它自动构建命名空间信息 - Automatically add namespace when adding new item
在解决方案属性页面中，检查包含“UpdatingMediaElement”的程序集的平台以及包含“UpdatingMediaElement”子类或实现的任何超类和接口的assmeblies。似乎所有这些组件的平台必须是“AnyCPU”。
另一个可能的原因：构建后事件是从构建文件夹中删除项目DLL。
为了澄清：WPF设计器可能会报告“名称XXX在命名空间中不存在...”，即使名称确实存在于命名空间中，如果后期构建事件从后期构建事件中删除项目DLL，项目也会正常运行build文件夹（bin \ Debug，bin \ Release等）。我在Visual Studio 2015中有这方面的经验。
如果程序集与包含类的命名空间不同，则必须明确指定它。
例如： -
xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"
好吧，不幸的是，这些提示都没有对我有用。我最终能够解决这个问题。似乎Visual Studio不能很好地与网络驱动器配合使用。我通过将项目从共享驱动器移动到本地并重新编译来解决了这个问题。没有更多的错误。
尝试验证您的装配参考。如果你在项目引用上有一个黄色感叹号那里有一个问题，你会得到各种错误。
如果您知道项目引用是正确的，请检查Target框架。例如，使用4.5框架的项目引用具有4.5.2框架的项目不是一个很好的组合。
添加到桩。
我是WPF应用程序的程序集名称是与引用的dll相同的程序集名称。因此，请确保您的任何项目中没有重复的程序集名称。
我将解决方案存储在网络共享上，每次打开它时都会收到有关不受信任来源的警告。我将它移动到本地驱动器，“命名空间不存在”错误也消失了。
还尝试右键单击您的项目 - >属性并将平台目标更改为任何CPU并重建，然后它将工作。这对我有用
在我的情况下，我有一个名称空间和类拼写完全相同，所以例如，我的一个名称空间是
firstDepth.secondDepth.Fubar
它包含自己的类（例如firstDepth.secondDepth.Fubar.someclass）
但我在命名空间中也有一个'Fubar'类
firstDepth.secondDepth
它在文本上解析为与上面的Fubar命名空间相同。
不要这样做
这个问题我也遇到了很多麻烦！ Intellisense帮助我完成命名空间和一切，但编译器哭了。我已经尝试过在这个和其他线程中找到的所有内容。但是在我的情况下，最终帮助的是写了这样的东西：xmlns：util =“clr-namespace：LiveSpielTool.Utils; assembly =”
将程序集名称留空。不知道为什么。但这里提到了。我必须添加我正在开发一个程序集，所以assembly属性可能有意义。但输入程序集名称不起作用。太奇怪了。
如果您实际引用的程序集未实际构建，也可能导致此问题。例如，如果您的xaml在Assembly1中，并且您也在Assembly1中引用了一个类，但该程序集有错误且未构建，则会显示此错误。
我对此感到愚蠢，但在我的情况下，我正在撕毁用户控件并因此在相关类中出现各种错误。当我试图修复它们时，我开始讨论有问题的错误，没有意识到xaml依赖于构建的程序集来查找这些引用（不像c＃/ vb代码，它甚至可以在构建之前完成）。
我将程序集添加为项目 - 首先删除了专门添加到dll引用的ddl - 这样做了。
我一直都会遇到这个问题。我的观点是在WPF自定义控件库项目（类库中的变体）中。我可以引用预构建的程序集，但不能引用同一解决方案的另一个项目中的任何代码。一旦我将代码移动到与xaml相同的项目，它就会被识别出来。
通过清除Xaml Design Shadow Cache，我已经看到这个问题消失了。我遇到了Visual Studio 2015 Update 1的问题。
在Visual Studio 2015中，缓存位于此处：
%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache
处理：
并且没有更多的命名空间错误。
在我的情况下，当wpf程序的架构与依赖项不完全相同时，就会发生这个问题。假设您有一个x64依赖项，另一个是AnyCPU。然后，如果选择x64，AnyCPU dll中的类型将“不存在”，否则x64 dll中的类型将“不存在”。你无法解决这两个问题。
尝试将构建目标平台更改为x86并构建项目。
我通过Subversion注意到我显然将项目构建平台目标更改为x64。这是我做过的唯一改变。进行更改后，代码在开始显示您遇到的相同错误之前已经工作了一段时间。我将平台目标更改为x86进行测试，突然我的设计师再次工作。随后，我将其更改回x64，问题完全消失了。我怀疑设计人员在x32中构建了某种缓存代码，并且在进行代码更改时更改x64构建平台会破坏它。
在我的情况下，这是因为其他编译错误。当其他错误得到解决时，这个看似相关的错误也从列表中删除了。特别是错误列表底部和最近更改的页面上的错误。
因此，请不要直接关注此错误，并首先关注其他错误。
Dunno，如果这会帮助其他人
我是WPF的新手，仍然是VB.net的新手 - 所以我假设得到这个错误是由于我做巅峰傻事........假设我真的！我已经设法通过将我的项目从共享驱动器移动到我的本地驱动器之一来摆脱它。错误消失了，项目编译完全没有进一步的问题 - 然而。看起来VS2015仍然存在共享驱动器上的项目问题。
也许是项目编译时的另一种解决方案，但XAML错误显示：
无需重建或关闭视觉工作室。
耶稣......五年后，在Visual Studio 2017中，这仍然是一个问题。由于我是WPF的新手，我确信这个问题在某种程度上是我，但不是，所有内容都已编译并正确运行。
我尝试重建，清理和重建，在x86 / x64输出之间切换，重新启动Windows，清理ShadowCache文件夹，在XML命名空间声明中添加“; assembly = {my main assembly name}”，没有任何效果！做的一件事：
把我的静态类命令（在我的情况下，这个交易是关于让设计发现我的WPF命令）在它的单独程序集中，并将程序集名称改为那个。
我有同样的问题，在我的情况下，标记设计视图要求我重建解决方案，并没有向我显示这个消息的表单布局：Design view is unavailable for x64 and ARM target platforms，或Build the Project to update Design view。
它不会通过重建解决方案得到解决（设计视图和“名称空间中不存在名称”错误）
我想是因为我使用了解决方案 - >属性>配置属性上的设置
我终于解决了2个工作的问题：
我认为这是Visual Studio 2012 Update 2中的一个错误。