XAML中的名称空间错误中不存在该名称

Question

使用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”中不存在。

不确定有什么问题或如何解决？

Answer 1

当您编写wpf代码并且VS告诉＆＃34;命名空间clr-namespace中不存在名称ABCDE：ABC＆＃34;。但是你可以完全构建你的项目，只有一点点不便，因为你看不到UI设计（或者只是想清理代码）。

尝试这样做：

• 在VS中，右键单击您的解决方案 - ＆gt;属性 - ＆gt;配置属性

• 打开一个新对话框，尝试将项目配置从Debug更改为Release，反之亦然。

之后，重新构建您的解决方案。它可以解决你的问题。

Answer 2

如果程序集与包含类的命名空间不同，则必须明确指定它。

例如： -

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

Answer 3

尝试将构建目标平台更改为x86并构建项目。

我注意到通过Subversion我显然将项目构建平台目标更改为x64。这是我做过的唯一改变。进行更改后，代码在开始显示您遇到的相同错误之前已经工作了一段时间。我将平台目标更改为x86进行测试，突然我的设计师再次工作。随后，我将其更改回x64，问题完全消失了。我怀疑设计人员在x32中构建了某种缓存代码，并且在更改代码时更改x64构建平台会破坏它。

Answer 4

我已经通过清除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. 重建解决方案

并且没有更多的命名空间错误。

Answer 5

在我的情况下，这是因为其他编译错误。当其他错误得到解决时，这个看似相关的错误也从列表中删除了。特别是错误列表底部和最近更改的页面上的错误。

  

因此，请不要直接关注此错误，并首先关注其他错误。

Answer 6

Dunno，如果这会帮助其他人

我是WPF的新手，仍然是VB.net的新手 - 所以我假设得到这个错误是由于我做巅峰傻事........假设我真的！我已经设法通过将我的项目从共享驱动器移动到我的本地驱动器之一来摆脱它。 错误消失了，项目完全没有进一步的问题 - 但是。看起来VS2015仍然存在共享驱动器上的项目问题。

Answer 7

可能是项目编译时的另一种解决方案，但XAML错误显示：

1. 在解决方案探索中，在包含xaml
的项目节点上
2. 右键单击该项目，然后选择“卸载项目＆＃39;
”
3. 右键点击该项目，然后选择“重新加载项目”＆＃39; 确保您的项目仍然被选为＆＃34;启动项目＆＃34;。如果不是：
4. 右键单击项目，然后选择“设置为启动项目＆＃39;
”

无需重建或关闭视觉工作室。

Answer 8

耶稣......五年后，在Visual Studio 2017中，这仍然是一个问题。由于我是WPF的新手，我确信问题不知何故，但是没有，所有内容都已编译并正确运行。

我尝试重建，清理和重建，在x86 / x64输出之间切换，重新启动Windows，清理ShadowCache文件夹，添加＆＃34 ;; assembly = {my main assembly name}＆＃34;到XML命名空间声明，什么都没有用！做的一件事：

将我的静态类命令（在我的情况下，该协议是关于使设计发现我的WPF命令）在其单独的程序集中，并将程序集名称更改为那个。

Answer 9

我遇到了同样的问题，在我的情况下，标记设计视图要求我重建解决方案并且没有向我显示带有此消息的表单布局： Design view is unavailable for x64 and ARM target platforms或Build the Project to update Design view。

重建解决方案无法解决（设计视图和“名称空间中不存在名称”错误）

我认为这是因为我在解决方案中使用了设置 - ＆gt;属性＆gt;配置属性

我终于解决了2个工作的问题：

1. 选中页面构建列上的所有复选框：解决方案 - ＆gt;属性 - ＆gt;配置属性
2. 将解决方案配置从调试更改为发布，反之亦然。

我认为这是Visual Studio2012 Update 2中的一个错误。

Answer 10

同样的问题困扰着Visual Studios 2013 Service Pack 4。 我也尝试使用Visual Studios 2015 Preview获得相同的结果。

这只是Visual Studio团队尚未修复的WPF可视化工具的限制。 作为证据，在x86模式下构建可视化器并在x64模式下构建会禁用它。

奇怪的是，intellisense适用于Visual Studios 2013，Service Pack 4。

Answer 11

我最近在.NET 4.6.2中使用VS 2015 Update 3来解决我的WPF项目。我的项目副本位于网络文件夹中，我在本地移动它并解决了这个问题。

这可能会解决其他类型的问题，因为看起来VS 2015不喜欢网络路径。另一个对他们来说是一个大问题的问题是，如果我的项目在网络路径中，同步git存储库，也可以通过在本地移动它来解决。

Answer 12

就我而言，用户控件已添加到主项目中。我尝试了上面的各种解决方案无济于事。要么我会得到无效标记，但解决方案将编译和工作，或者我会添加 xmlns：c =“clr-namespace：MyProject; assembly = MyProject”然后标记会显示，但是我会得到一个编译错误，标签在XML命名空间中不存在。

最后，我在解决方案中添加了一个新的WPF用户控件库项目，并将我的用户控件从主项目移到了那个项目中。添加了引用并更改了程序集以指向新库，最后标记工作并且项目编译时没有错误。

Answer 13

就我而言，问题是由于项目的obj目录下的一些幻像文件引起的。以下内容为我解决了此问题：

• 清洁项目
• 退出VS
• rm -rf / obj / *
• 调用VS并重建

Answer 14

我经历了所有答案，没有人帮助过我。最后能够自己解决，所以提出答案，因为它可能会帮助其他人。

在我的例子中，解决方案有两个项目，一个包含模型（比如项目和程序集名称是模型），另一个包含视图和视图模型（根据我们的约定：项目，程序集名称和默认名称空间为 Models.Monitor ）。 Models.Monitor引用了Models项目。

在Models.Monitor项目中，在其中一个xaml中我包含了以下命名空间： 的xmlns：显示器=＆＃34; CLR-名称空间：Models.Monitor＆＃34;

我怀疑 MsBuild和Visual Studio因为他们试图找到一个监视器而错误输出。输入程序集＆＃39;模型＆＃39; 。要解决我尝试了以下内容：

1. 的xmlns：显示器=＆＃34; CLR-名称空间：Models.Monitor;装配=＆＃34; - 如果命名空间与https://msdn.microsoft.com/en-us/library/ms747086(v=vs.110).aspx
在同一个程序集中，则该选项有效
2. 还尝试了显式名称空间声明： 的xmlns：显示器=＆＃34; CLR-名称空间：Models.Monitor;装配= Models.Monitor＆＃34;

上述两种方法均无效。

最后我放弃了，并且作为一个解决的工作移动了UserControl，我试图使用另一个命名空间：＆＃39; ModelsMonitor＆＃39; 。之后我就能编好了。

Answer 15

我的解决方案是解除阻塞程序集DLL。您收到的错误消息并未表明这一点，但XAML设计师拒绝加载它所调用的内容＆＃34;沙盒＆＃34;组件。您可以在构建时在输出窗口中看到这一点。如果从Internet下载DLL，则会阻止它们。要取消阻止第三方程序集DLL：

1. 在Windows资源管理器中右键单击DLL文件，然后选择“属性”。
2. 在“常规”标签的底部，点击＆＃34;取消屏蔽＆＃34;按钮或复选框。

注意：如果您确定它们是安全的，则只能解除阻止。

Answer 16

看起来这个问题可以通过各种“技巧”来解决。

就我而言，我一直在构建/重建/清理整个解决方案，而不仅仅是我在解决方案中处理的项目。点击“构建[我的项目]”后，错误消息就消失了。

Answer 17

如果您所引用的程序集实际上没有构建，也可能导致此问题。例如，如果您的xaml在Assembly1中，并且您也在Assembly1中引用了一个类，但该程序集有错误并且没有构建，则将显示此错误。

我对此感到很愚蠢，但是就我而言，我在用户控制之下撕裂了，结果在相关类中出现了各种错误。当我尝试修复所有问题时，我从有问题的错误开始，但没有意识到xaml依赖于已建立的程序集来找到这些引用（与c＃/ vb代码不同，即使在构建之前它也可以解决）。

Answer 18

如果没有答案有效

对我来说，我正在使用的那个版本的.Net Framework版本兼容性问题早于所引用的内容

从属性=>应用程序然后是目标框架

Answer 19

在一个复杂的WPF应用程序中，这已经发生了两次，其中有4个多平台项目，1个共享项目，2个支持库和1个测试项目。

这个非常具体的XAML命名空间错误在Shared项目上最近修改的文件上发生了两次。在我的两种情况下，都是一个新的c＃文件，其中添加了重复的名称空间条目。

像命名空间MyProgram.MyFolder.MyProgram.MyFolder

我两次错误地粘贴了一次，并且一次是由于JetBrains Rider两次粘贴了命名空间。 （如果曾经在Rider中重命名项目，则有时会在创建新文件时，尤其是在共享项目上，开始对名称空间进行两次粘贴。）然后，在XAML文件所引用的ViewModels中调用这些具有重复名称空间的c＃文件。那么，您会得到这些不相关且具有误导性的错误，您可能会遇到一个文件问题，所有Xaml文件最终都会开始出错。

无论如何，如果您遇到此类错误，则在大多数情况下，新添加的文件或代码更改通常是一个问题。我的建议是查看您最近的更改。

Answer 20

尝试检查References部分，并查看您所包含的库引用中是否有警告图标：

如果看到它，请转到项目->属性->应用程序，并确保两个库都针对相同版本的.NET framework。

P.S。当发生此问题时，也可以从Warnings部分中注意到它：

Answer 21

另一个人发布该消息可能是由于将项目保存在网络共享上引起的。我发现，如果我从使用网络路径切换到映射的网络驱动器，则一切正常。

来自： “ \\ SERVER \ Programming \ SolutionFolder”

收件人： “ Z：\ Programming \ SolutionFolder” （精确映射可选）

Answer 22

此主题中的两个想法的结合对我有用，因此我将发布我所做的事情，希望它可以在未来5年内帮助其他人这个问题继续存在。我正在使用VS2017社区）

1. 删除对dll的引用
2. 清理，重建，构建
3. 关闭VS，解除阻止dll （请参见下面的注释），删除阴影缓存
4. 打开VS，清理，重建，构建
5. 还原对dll的引用
6. 清理，重建，构建

在步骤2、4和6中，我可能没有完全正确的命令，但是在花了将近2个小时解决这个问题后，我还是不知所措。我认为对我来说，关键是删除引用，解除阻止dll和删除影子缓存的组合。

（第3步的注释-我正在使用的dll是由我的同事/导师编写的，因此我知道这是安全的。如果您不知道dll的来源，请谨慎执行此步骤）

我将这个线程标记为后代，因为看来MS不想清理这些东西。 WPF本身很难学习，当您做对了所有正确的事情后，就不得不通过这种东西来破解。 ???

Answer 23

就我而言，当wpf程序的体系结构与依赖项不完全相同时，将发生此问题。 假设您有一个依赖关系是x64，另一个是AnyCPU。然后，如果选择x64，则AnyCPU dll中的类型将“不存在”，否则，x64 dll中的类型将“不存在”。您只是不能同时宣传他们两个人。

Answer 24

VB.NET不会像在C＃中那样自动添加基于文件夹结构的命名空间信息。我想我正在和你一样学习（24小时内自学WPF），并进行相同的VB转换。

我发现您必须手动将命名空间信息添加到两者 XAML类和后面的XAML.VB代码，以便能够使用本书中所述的命名空间。即使这样，VB也不会像在VB中那样自动将命名空间分配给程序集。

此处还有另一篇文章介绍如何将其包含在项目模板中，以便自动构建命名空间信息 - Automatically add namespace when adding new item

Answer 25

我将程序集添加为项目-首先删除了专门添加到dll引用的ddl-完成了此操作。

Answer 26

好的，不幸的是，这些提示都不适合我。我最终能够解决这个问题。似乎Visual Studio不能很好地与网络驱动器配合使用。我通过将项目从共享驱动器移动到本地并重新编译来解决了这个问题。没有更多的错误。

Answer 27

我对此也有很多麻烦！ Intellisense可以帮助我完成名称空间和所有内容，但是编译器会哭。我已经尝试了在此线程和其他线程中找到的所有内容。但是，对我而言，最终的帮助是编写了这样的内容：     xmlns：util =“ clr-namespace：LiveSpielTool.Utils; assembly =”

将程序集名称保留为空。不知道为什么。但是这里提到了。我必须添加我正在开发一个程序集，所以Assembly属性可能有意义。但是输入程序集名称无效。太奇怪了。

Answer 28

在我的情况下，我有一个名称空间和类的拼写完全相同，因此，例如，我的一个名称空间是

firstDepth.secondDepth.Fubar

包含自己的类（例如firstDepth.secondDepth.Fubar.someclass）

但是我在命名空间中也有一个' Fubar '类

firstDepth.secondDepth

在文本上与上面的Fubar命名空间相同。

不要这样做

Answer 29

还尝试右键单击您的项目＆gt;属性并将平台目标更改为任何CPU并重建，然后它将起作用。这对我有用

Answer 30

在解决方案属性页面中，检查包含＆＃34; UpdatingMediaElement＆＃34;的程序集的平台。和包含任何超类和接口的assmeblies＆＃34; UpdatingMediaElement＆＃34;子类或实现。似乎所有这些组件的平台必须是＆＃34; AnyCPU＆＃34;。

Answer 31

另一个可能的原因：构建后事件是从构建文件夹中删除项目DLL。

澄清一下：WPF设计人员可能会报告＆＃34;命名空间名称XXX在命名空间中不存在...＆＃34;，即使名称确实存在于命名空间中且项目构建并运行得很好 if 后期构建事件从构建文件夹（bin \ Debug，bin \ Release等）中删除项目DLL。我在Visual Studio 2015中有相关的个人经验。

Answer 32

我将解决方案存储在网络共享中，每次打开它时都会收到有关不受信任来源的警告。我将它移动到本地驱动器并且＆＃34;命名空间不存在＆＃34;错误消失了。

Answer 33

尝试验证您的装配参考。如果项目引号上有黄色感叹号，则会出现问题，并且您会收到各种错误。

如果您知道项目引用是正确的，请检查Target框架。例如，使用4.5框架的项目引用具有4.5.2框架的项目不是一个很好的组合。

Answer 34

添加到堆中。

我是WPF应用程序的程序集名称与引用的dll具有相同的程序集名称。因此，请确保您的任何项目中没有重复的程序集名称。

Answer 35

• 该问题看起来像是Visual Studio中的错误。

解决方案：尝试重新构建解决方案

• 要重建的快捷方式：CTRL + SHIFT + B

Answer 36

为视图模型添加一个空构造函数并重建解决方案。我尝试了很多不起作用的解决方案，但这解决了我。

Answer 37

我有相同的症状“名称空间错误中不存在名称”，但原因却不同。我发生了C：驱动器崩溃，不得不重新安装Visual Studio2017。我还原了源代码文件并打开了解决方案。建好了。没有骰子。除了出现“名称空间中不存在名称”错误外，我还注意到我的子项目抱怨他们找不到MyProject.cs文件（“ MyProject”不是实际的项目名称，仅在此处用作示例） 。我一直在寻找MyProject.cs的去向，然后记得从来没有任何这样的文件！我查看了每个子项目的Properties文件夹，发现Visual Studio自己重新添加了对MyProject.cs的虚假引用！我删除了这些参考，现在该解决方案可以像以前一样构建良好。