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

在 VB.NET WPF 应用程序中使用 VS2012。我有一个简单的 MusicPlayer 教程应用程序，我用来学习 WPF。我正在将教程的 C # 版本逐步转换为 VB.NET。

它在应用程序中有两个同属于同一名称空间的类。我能够在 XAML 中引用名称空间，但是当我尝试在 XAML 中引用类对象时，我得到了一个错误，我无法编译。

奇怪的是，IntelliSense 既可以通过 xmlns: c = 标记引用名称空间，也可以使用 <c:键入类对象 但是对象是下划线的，并且试图在设计器中生成或工作时会生成错误。

那个。Vb 类文件位于一个名为 Controls 的文件夹中。Main 项目 Root 命名空间故意留空。类的代码是这样的..。

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-nampace: MusicPlayer.Controls”中不存在。

不知道出了什么问题或者如何解决？

160530 次浏览
小开

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

例如:-

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

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

因此，不要直接关注这个错误，而应首先关注 其他错误。

小开

我遇到了同样的问题，在我的例子中，标记设计视图要求我重新构建解决方案，但没有给我显示带有以下信息的表单布局: Design view is unavailable for x64 and ARM target platforms或 Build the Project to update Design view。

通过重新生成解决方案并不能解决这个问题(无论是设计视图还是“名称空间中不存在名称”错误)

我想这是因为我在解决方案-> 属性 > 配置属性上使用了设置

我最终用两份工作解决了这个问题:

  1. 选中页面“生成列”上的所有复选框: 解决方案-> 属性-> 配置属性
  2. 将解决方案配置从 调试更改为 放手，反之亦然。

我认为这是 VisualStudio2012Update2中的一个 bug。

小开

NET 不会像在 C # 中那样根据文件夹结构自动添加命名空间信息。我认为我正在经历相同的教程作为你(自学 WPF 在24小时) ，并做相同的转换到 VB。

我发现您必须手动将命名空间信息添加到 都有中的 XAML 类和后面的 XAML.VB 代码中，才能使用书中描述的命名空间。即使这样，VB 也不会像在 VB 中那样自动将命名空间分配给汇编。

这里还有另一篇文章展示了如何在项目模板中包含这些内容，以便自动构建命名空间信息—— 添加新项时自动添加命名空间

小开
最佳答案

当您编写 wpf 代码时，VS 会告诉您“名称 ABCDE 不存在于名称空间 clr-nampace: ABC 中”。但是您完全可以成功地构建您的项目，只有一个小小的不便，因为您无法看到 UI 设计(或者只是想清理代码)。

试着这样做:

  • 在 VS 中，右键单击解决方案-> 属性-> 配置属性

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

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

小开

在解决方案属性页中，检查包含“ UpdatingMediaElement”的程序集的平台和包含“ UpdatingMediaElement”子类或实现的任何超类和接口的程序集。似乎所有这些程序集的平台都必须是“ AnyCPU”。

小开

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

我通过 Subversion 注意到，我明显地将项目 build Platform 目标改为 x64。这是我唯一的改变。在进行这个更改之后，代码工作了一段时间，然后开始显示您所经历的相同错误。我将平台目标更改为 x86以进行测试，突然我的设计器又可以工作了。随后，我将它改回 x64，问题就完全消失了。我怀疑设计器在 x32中构建了某种缓存代码，而更改 x64构建平台会在您更改代码时破坏它。

小开

同样的问题困扰着 VisualStudios 2013，ServicePack4。 我也在 Visual Studios 2015预览版中尝试过，得到了相同的结果。

这只是 WPF 可视化工具的一个限制，VisualStudios 团队还没有解决这个问题。 作为证明，在 x86模式下构建将启用可视化工具，而在 x64模式下构建将禁用它。

奇怪的是，对于 VisualStudio2013，ServicePack4来说，足够多的智能感知工作。

小开

另一个可能的原因是: 生成后事件正在从生成文件夹中删除项目 DLL。

澄清一下: WPF 设计师可能会报告“名称 XXX 不存在于名称空间中...”，即使名称确实存在于名称空间中，并且项目构建和运行良好的 如果，后期构建事件会从构建文件夹中删除项目 DLL (bin Debug，bin Release，等等)。我在 VisualStudio2015中对此有个人经验。

小开

通过清除 Xaml Design Shadow Cache，我已经看到这个问题消失了。我在 VisualStudio2015Update1中遇到了问题。

在 Visual Studio 2015中，缓存位于这里:

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

过程:

  1. 在解决方案资源管理器中右键单击解决方案并选择“清除解决方案”
  2. 关闭 VisualStudio
  3. 删除 ShadowCache 文件夹
  4. 重新打开 VisualStudio 项目
  5. 重建解决方案

瞧，再也没有名称空间错误了。

小开

不知道这能不能帮到其他人

我是 WPF 的新手，还是 VB.net 的新手——所以我假设出现这个错误是因为我做了一个愚蠢的峰会... ..。假设我真的是！我通过将我的项目从一个共享驱动器移动到我的一个本地驱动器上来设法摆脱它。 错误消失，项目编译完全没有进一步的问题-尚未。看起来 VS2015在共享驱动器上的项目仍然存在问题。

小开

尝试验证程序集引用。如果你在项目参考文献上有一个黄色的叹号，那里就有问题，你会得到各种各样的错误。

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

小开

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

在我的例子中，我一直在构建/重建/清理整个解决方案，而不仅仅是在解决方案中工作的项目。一旦我点击“ Build [ my project ]”，错误消息就消失了。

小开

不幸的是，这些建议对我都不管用。我最终解决了这个问题。VisualStudio 似乎不能很好地使用网络驱动器。通过将项目从共享驱动器移动到本地并重新编译，我解决了这个问题。别再出错了。

小开

我最近在我的 WPF 项目中使用 VS2015Update3时遇到了这个问题。NET 4.6.2.我的项目的副本是在一个 网络文件夹，我移动它本地，这解决了问题。

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

小开

我的解决方案是解除程序集 DLL 的阻塞。您得到的错误消息没有指出这一点，但是 XAML 设计器拒绝加载它所称的“沙箱”程序集。构建时可以在输出窗口中看到这一点。如果 DLL 是从互联网上下载的，它们就会被阻塞。要解除第三方程序集 DLL 的阻塞:

  1. 右键单击文件资源管理器中的 dLL 文件并选择“属性”。
  2. 在“常规”选项卡的底部，单击“取消阻塞”按钮或复选框。

注意: 只有当您确定 DLL 是安全的时候才取消阻塞 DLL。

小开

又多了一个。

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

小开

也许另一个解决方案，当项目编译时，但 XAML 错误显示:

  1. 在解决方案探索中，在包含 xaml 的项目节点上
  2. 右键单击该项目并选择“卸载项目”
  3. 右键单击项目并选择“重新加载项目” 确保你的项目仍然被选为“启动项目”，否则:
  4. 右键单击该项目并选择“设置为启动项目”

不需要重建，或关闭视觉工作室。

小开

在我的示例中，用户控件被添加到主项目中。我尝试了以上各种解决办法，但都无济于事。要么我会得到无效标记，但解决方案将编译和工作，或者我会添加 C = “ clr-nampace: MyProject; Assembly = MyProject”，然后会显示标记，但是我会得到一个编译错误，标记在 XML 名称空间中不存在。

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

小开

我将解决方案存储在一个网络共享中，每次打开它，我都会收到关于不可信来源的警告。我将它移动到一个本地驱动器，“名称空间不存在”错误也消失了。

小开

我找遍了所有的答案，没有一个对我有帮助。最后终于能够自己解决这个问题，所以提出这个答案，因为它可能会帮助别人。

在我的例子中，解决方案有两个项目，一个包含模型(比如项目和程序集名称是 模特) ，另一个包含视图和视图模型(根据我们的约定: 项目、程序集名称和默认名称空间是 模特，监视器)。模特们。监视参考模型项目。

在 Models.Monitor 项目中，在一个 xaml 中包含以下命名空间: Monitor = “ clr-nampace: Models.Monitor”

我怀疑 然后，MsBuild 和 Visual Studio 在试图在程序集“ Model” 中查找“ Monitor”类型时出错。为了解决这个问题，我尝试了以下方法:

  1. Monitor = “ clr-nampace: Models.Monitor; Assembly =”-如果命名空间与 https://msdn.microsoft.com/en-us/library/ms747086(v=vs.110).aspx在同一个程序集中，则该命名空间有效
  2. 还尝试了显式的名称空间声明: Monitor = “ clr-nampace: Models.Monitor; Assembly = Models.Monitor”

以上两种方法都不管用。

最后我放弃了，作为一个工作围绕 将我试图使用的 UserControl 移动到另一个名称空间: ‘ ModelsMonitor’。我能够编译之后很好。

小开

为视图模型添加空的构造函数并重新生成解决方案。

小开

天哪... 这个问题五年后在 VisualStudio2017中仍然存在。因为我是 WPF 的新手，所以我确信问题出在我身上，但是不，所有的东西都编译并正确运行了。

我尝试过重新构建、清理和重新构建，在 x86/x64输出之间切换，重新启动 Windows，清理 ShadowCache 文件夹，在 XML 名称空间声明中添加“ ; Assembly = { my main Assembly name }”，但没有任何效果！唯一起作用的是:

将我的命令的静态类(在我的例子中是关于让设计发现我的 WPF 命令)放在其单独的程序集中，并将程序集名称更改为该程序集的名称。

小开

还可以尝试右键单击您的项目-> 属性和改变平台目标为任何 CPU 和重建，然后它将工作。这招对我很管用

小开

在我的例子中，我有一个名称空间和一个类的拼写完全相同，所以例如，我的一个名称空间是

firstDepth.secondDepth.Fubar

它包含自己的类(例如 firstDepth.second Depth. Fubar.somecclass)

但是我在名称空间中也有一个‘ 混蛋’类

firstDepth.secondDepth

它在文本上解析为与上面的 Fubar 名称空间相同。

别这样

小开

我也有很多麻烦，这一个！智能感知帮助我完成名称空间和一切，但编译器哭了。我已经试过了所有我在这个和其他线程中找到的东西。然而，在我的案例中，最终起作用的是写下这样的东西:

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

将程序集名称保留为空。不知道为什么。但这里提到过。我必须补充说，我正在开发一个程序集，因此程序集属性可能有意义。但输入程序集名称无效。太奇怪了。

小开

如果引用的程序集实际上没有生成，也可能导致此问题。例如，如果您的 xaml 在 Assembly1中，并且您正在引用 Assembly1中的类，但是该程序集有错误并且没有生成，那么将显示此错误。

我对此感到很愚蠢，但在我的情况下，我正在拆分一个用户控件，结果在相关类中出现了各种各样的错误。当我试图修复这些错误时，我从这些错误开始，没有意识到 xaml 依赖于构建的程序集来找到这些引用(不像 c #/vb 代码，它甚至可以在构建之前解决这些问题)。

小开

我将程序集作为一个项目添加——首先删除了专门添加到 dll 引用的 ddl ——这样做了。

小开

我经常遇到这种问题。我的视图位于 WPF 自定义控件库项目(类库的变体)中。我可以引用预生成的程序集，但不能引用同一解决方案的另一个项目中的任何代码。只要我将代码移动到与 xaml 相同的项目中，它就会被识别出来。

小开

在我的例子中，问题是由于项目的 obj 目录下的一些幻象文件造成的。以下内容为我解决了这个问题:

  • 清洁工程
  • 出口 VS
  • Rm-rf/obj/*
  • 调用 VS 并重新构建
小开

在我的例子中，当 wpf 程序的体系结构与依赖关系不完全相同时，就会出现这个问题。 假设您有一个依赖项 x64，另一个依赖项 AnyCPU。然后，如果选择 x64，AnyCPU dll 中的类型将“不存在”，否则 x64 dll 中的类型将“不存在”。你不可能同时模仿他们两个。

小开
  • 在 我的强大的情况下，问题是一个 bug 在 Visual Studio-因为错误没有任何意义，当我重建-一切神奇地工作！经过45分钟的沮丧，这个解决方案挽救了我的头部和显示器从严重受伤。也许这也能救你一命——值得一试吗？

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

  • 重新构建的捷径: CTRL + SHIFT + B

Simply rebuild and it should work!

解决方案2: 尝试重新启动 VisualStudio

小开

这个帖子中的两个想法对我来说都很有效，所以我将把我所做的发布出来，希望能够在未来5年内帮助其他人解决这个问题。我正在使用 VS2017社区)

  1. 删除对 dll 的引用
  2. 清洁，重建，建造
  3. 关闭 VS，解锁 dll (见下文注释)，删除阴影缓存
  4. 打开 VS，清洁，重建，构建
  5. 还原对 dll 的引用
  6. 清洁，重建，建造

在步骤2、4和6中，我可能没有完全正确的顺序，但是在花了将近2个小时处理这个问题之后，我抓住了救命稻草。我认为对我来说，关键是删除引用、解除阻塞 dll 和删除影子缓存的组合。

(注意步骤3-我正在使用的 dll 是由我的一个同事/导师编写的，所以我知道它是安全的。如果您不知道 dll 的源代码，请小心这一步)

我将把这个帖子作为书签留给后人，因为 MS 似乎并不想清理这些东西。WPF 本身就很难学习，而且当你把所有事情都做对了的时候，还要破解这样的东西，真是让人恼火。🤬🤬🤬

小开

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

来自: “服务器编程解决方案文件夹”

致: “ Z: 编程解决方案文件夹” (精确映射可选)

小开

我有同样的症状“名称不存在于名称空间错误中”，但原因是不同的。我有一个 C: 驱动器崩溃，不得不重新安装 VisualStudio2017。我恢复了源代码文件并打开了解决方案。建造它。没戏。除了“名称空间中不存在名称”错误之外，我还注意到我的子项目抱怨说他们找不到 MyProject.cs 文件(‘ MyProject’不是实际的项目名称，只是用在这里作为例子)。我搜索了一下 MyProject.cs 去了哪里，然后想起来根本就没有这样的文件！我查看了每个子项目的 Properties 文件夹，发现 Visual Studio 自己在后面添加了对 MyProject.cs 的虚假引用! ！我删除了这些引用，现在解决方案构建得很好，就像以前一样。

小开

尝试检查一下 References部分，看看在你包含的库参考文献上是否有一个 警告图标:

enter image description here

如果您看到它，那么转到 工程项目-> 物业-> 申请，并确保两个库的目标都是相同版本的 .NET framework。

另外，当这个问题发生时，也可以从 Warnings章节中注意到:

enter image description here

小开

在 VisualStudio2019中，我可以按照其他答案中的建议，通过将下拉列表更改为“发布”来修复它。但是当我切换回调试模式时，错误又出现了。

在调试模式下修复它的方法:

  1. 切换到释放模式
  2. 单击 XAML 设计器中的“禁用项目代码”

XAML editor: Disable project code

  1. 切换回调试模式 = > 错误消失
小开

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

这个非常特定的 XAML 命名空间错误在共享项目中最近修改的文件上发生了两次。在我的两个案例中，它都是一个新的 c # 文件，添加了一个重复的名称空间条目;

就像 名称空间 MyProgram.MyFolder.MyProgram.MyFolder

我错误地双重粘贴了一次，还有一次是因为 JetBrains Rider 双重粘贴了名称空间。(如果您曾经在 Rider 中重命名项目，那么有时会在新文件创建时开始双重粘贴名称空间，特别是在共享项目上。.).然后在引用 XAML 文件的 ViewModel 中调用这些带有重复名称空间的 c # 文件。然后你会得到这些不相关的和误导性的错误，你可能会有一个文件的问题，所有的 Xaml 文件最终都会开始出错。

无论如何，如果出现这种错误，大多数情况下都是新添加的文件或代码更改出现问题。我的建议是看看你最近的变化。

小开

如果这些答案都不起作用的话

对我来说，我正在使用的.Net Framework 版本兼容性问题比所引用的更早

从属性 = > 应用程序到目标框架

小开

再来一个转折，希望其他人会觉得有帮助。我和这里的每个人都有同样的问题，我尝试了所有的建议——验证引用、调试/发布开关、重新启动 VS、检查构建配置级别、多次重新构建——但没有任何帮助。最后，我尝试了创建一个新项目的建议，并将我试图解决的一个单一对象移动到该项目中，这样就解决了引用问题。
然而——这就是我在这里添加另一篇文章的原因——最终我发现实际的问题是原始 Project 包含了一个引用 SQLite 数据库的对象。事实证明，安装的 NuGetSQLite 包实际上导致了这个问题。当我将 DB 访问代码和 NuGet SQLite 引用移到它自己的项目时，我就能够将原始对象和其他所有对象一起移回原始项目中，而且引用问题不会再出现。显然，NuGetSQLite 包中的一些设置让系统感到困惑。

小开

我也碰到过同样的问题。

在我的例子中，我错误地从 XAML 文件中删除了 x: class 属性，它不再工作了。

小开

对我来说，这只是个奇怪的窃听器。

我有一个类，我试图在我的名称空间中使用，但是 Visual Studio 不断抛出一个错误，说该类不存在于给定的名称空间中。

我所做的修复工作真的很愚蠢，但却非常有效。

我注释掉了试图使用该类的所有代码行，清理了构建、重新构建和项目启动并运行。

然后我取消了之前注释过的代码行的注释，Visual Studio 不再给我添加任何错误。

重建一次，你就可以出发了。

小开

FWIW... 我今天碰到了这个问题，结果发现，这是由于从 UNC 网络路径打开我的解决方案/项目，而不是映射驱动器。

只要一个映射驱动器到我的回购和打开项目，它工作得很好。

TLDR: 尝试从映射驱动器打开项目

小开

从类中移除 sealed关键字也会带走错误，以防某个类使用该关键字。我成功了！

小开

对于我来说，我创建了一个自定义控件和第二个 Generic.xaml，因为我没有注意到创建了一个包含相关 Generic.xaml 的新文件夹。所以我只是删除了我创建的复制的 Generic.xaml 并修改了另一个。


提交答案