【问题标题】：The name does not exist in the namespace error in XAMLXAML 中的命名空间错误中不存在该名称
【发布时间】：2013-01-17 21:52:24
【问题描述】：

在 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" />

（显示错误）名称空间“clr-namespace:MusicPlayer.Controls”中不存在名称“UpdatingMediaElement”。

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

【问题讨论】：

重新启动视觉对我有用。（永远不要低估重启的力量）
对那些为此苦苦挣扎的人提供一点帮助：确保您的课程是公开的。
在启动/构建应用程序时关闭 xaml 文档
就像 Falaque 所说的，重启在很多情况下都有帮助。就我而言，这是删除我的存储库并再次克隆它。这样你就可以确保即使是那些被 git 忽略的文件也会被删除。

标签： wpf vb.net xaml visual-studio-2012

【解决方案1】：

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

【讨论】：

【解决方案2】：

在我的案例中，问题是 Visual Studio 中的错误 - 因为错误没有任何意义，当我重建时 - 一切都神奇地工作了！经过 45 分钟的挫折后，这个解决方案使我的头部和显示器免于严重受伤。也许它也可以拯救你——这当然值得一试？

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

重新构建的捷径：CTRL + SHIFT + B

解决方案 2：尝试重新启动 Visual Studio

【讨论】：

是的，重建将解决大部分问题，因为 xaml 尝试调用尚未构建的元素。每次创建新类并尝试在 xaml 上使用时重新构建

【解决方案3】：

如果没有一个答案有效

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

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

【讨论】：

【解决方案4】：

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

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

喜欢命名空间 MyProgram.MyFolder.MyProgram.MyFolder

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

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

【讨论】：

【解决方案5】：

在 Visual Studio 2019 中，我能够按照其他答案中的建议将下拉列表更改为 Release 来修复它。但是当我改回调试模式时，错误再次出现。

在调试模式下为我解决了什么问题：

切换到发布模式
在 XAML 设计器中单击“禁用项目代码”

切换回调试模式 => 错误消失了

【讨论】：

【解决方案6】：

我也遇到了很多麻烦！ Intellisense 帮助我完成命名空间和一切，但编译器哭了。我已经尝试了在此线程和其他线程中找到的所有内容。但是在我的情况下，最终有帮助的是写这样的东西：

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

将程序集名称留空。不知道为什么。但是这里提到了。我必须补充说我正在开发一个程序集，所以程序集属性可能有意义。但是输入程序集名称不起作用。好诡异。

【讨论】：

【解决方案7】：

尝试检查References 部分，看看您所包含的库参考是否有警告图标：

如果您看到它，请转到 Project -> Properties -> Application 并确保两个库都针对同一版本的 .NET framework。

附：当这个问题发生时，也可以从Warnings 部分注意到：

【讨论】：

【解决方案8】：

为您的视图模型添加一个空的构造函数并重建解决方案。

【讨论】：

【解决方案9】：

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

【讨论】：

【解决方案10】：

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

来自： "\\SERVER\Programming\SolutionFolder"

到： "Z:\Programming\SolutionFolder" （精确映射可选）

【讨论】：

【解决方案11】：

这个线程中的两个想法的组合对我有用，所以我将发布我所做的事情，希望在接下来的 5 年内它可以帮助其他人解决这个问题。我正在使用 VS2017 社区）

删除对 dll 的引用
清理、重建、构建
关闭 VS，解除对 dll 的阻塞（见下面的注释），删除影子缓存
打开 VS，清理，重建，构建
恢复对 dll 的引用
清理、重建、构建

我在第 2、4 和 6 步中的顺序可能不完全正确，但在解决这个问题将近 2 小时后，我抓住了稻草。我认为对我来说关键是删除引用、解锁 dll 和删除影子缓存的组合。

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

我将在此线程上添加书签以供后代使用，因为 MS 似乎不想清理这些东西。 WPF 很难自学，当你做对了所有事情时，不得不破解这样的东西是令人愤怒的。 ???

【讨论】：

【解决方案12】：

在我的情况下，当 wpf 程序的架构与依赖关系不完全相同时，就会发生此问题。假设您有一个依赖项是 x64，另一个是 AnyCPU。那么如果选择x64，AnyCPU dll中的类型会“不存在”，否则x64 dll中的类型会“不存在”。你只是不能模仿他们两个。

【讨论】：

【解决方案13】：

在我的情况下，问题是由于项目的 obj 目录下的一些幻像文件。以下为我解决了这个问题：

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

【讨论】：

【解决方案14】：

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

【讨论】：

【解决方案15】：

我已将程序集添加为项目 - 首先删除了专门添加到对 dll 的引用的 ddl - 这样做了。

【讨论】：

【解决方案16】：

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

我对此感到很傻，但在我的情况下，我在用户控制下撕裂，结果在相关类中出现了各种错误。当我试图修复它们时，我从有问题的错误开始，没有意识到 xaml 依赖于构建的程序集来查找这些引用（与 c#/vb 代码不同，它甚至可以在构建之前解决）。

【讨论】：

【解决方案17】：

在我的例子中，我的命名空间和类的拼写完全相同，例如，我的命名空间之一是

firstDepth.secondDepth.Fubar

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

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

firstDepth.secondDepth

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

不要这样做

【讨论】：

【解决方案18】：

我已经通过清除 Xaml Design Shadow Cache 看到这个问题消失了。我遇到了 Visual Studio 2015 Update 1 的问题。

在 Visual Studio 2015 中，缓存位于此处：

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

流程：

在解决方案资源管理器中右键单击解决方案并选择“清洁解决方案”
关闭 Visual Studio
删除 ShadowCache 文件夹
重新打开 Visual Studio 项目
重建解决方案

瞧，不再有命名空间错误。

【讨论】：

可悲的是，对我来说并没有改变任何事情。将近整整一年后仍在处理这个烦人的问题。 ://
谢谢！这最终为我工作。很遗憾在 VS15 中仍然需要这些技巧
您可以使用 %localappdata%\Microsoft\VisualStudio\14.0\Designer\ 立即转到正确的文件夹
拥有一个只有在您构建解决方案时才有效的设计师是很糟糕的。想象一下，在看到设计之前告诉汽车设计师制造整辆汽车。
好建议。谢谢。它本身并没有完全解决问题，但帮助我找到了解决方案，因为它将编译错误的数量从 190 个减少到 5 个。

【解决方案19】：

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

【讨论】：

您的建议是一项重大更改，如果他们针对特定环境，OP 甚至可能都不可能。无论哪种方式，它都不太可能成为问题的原因，如果它为您解决了问题，那么我建议您的实际问题是项目配置不匹配，这将以许多不同的方式表现在此处显示的问题上。

【解决方案20】：

天哪...五年后在 Visual Studio 2017 中这仍然是一个问题。由于我是 WPF 新手，我确信问题出在我身上，但不，一切编译和运行都正确。

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

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

【讨论】：

【解决方案21】：

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

我通过 Subversion 注意到我显然将项目构建平台目标更改为 x64。这是我所做的唯一改变。进行该更改后，代码运行了一段时间，然后开始显示您遇到的相同错误。我将平台目标更改为 x86 进行测试，突然我的设计师又开始工作了。后来我又改回x64，问题就彻底消失了。我怀疑设计者在 x32 中构建了某种缓存代码，并且在您进行代码更改时更改 x64 构建平台会破坏它。

【讨论】：

我再次发生这种情况，我可以确认这解决了我的问题。在 x86 中构建后，您可以切换回 x64。
这在 VS 2012 中也对我有用......经过数小时试图找出合乎逻辑的东西。谢谢，汤姆！
切换到 x86 并返回到 x64 解决了这里的问题，因此感谢您鼓励我尝试这样做。我什至关闭了 VS，删除了 bin 和 obj，并根据其他建议进行了重建，但在此之前没有任何帮助。
是的，这在 VS2015 Update 2 上也适用于我。但是，我有必要重新加载我的外部 dll 文件并重建它们。
使用 VS2015U2，我仍然在 x64 中遇到这个问题。适用于任何 CPU。来回切换对我不起作用。

【解决方案22】：

我浏览了所有答案，但没有一个对我有帮助。终于能够自己解决了，所以提出答案，因为它可能有助于其他人。

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

在 Models.Monitor 项目中，我在其中一个 xaml 中包含以下命名空间： xmlns:monitor="clr-namespace:Models.Monitor"

我怀疑 MsBuild 和 Visual Studio 在尝试在程序集“模型”中查找“监视器”类型时出错。为了解决，我尝试了以下方法：

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'。之后我就可以正常编译了。

【讨论】：

【解决方案23】：

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

所以不要直接关注这个错误，先关注其他错误。

【讨论】：

请注意，进行构建/编译为我解决了这个问题，即使我没有任何其他不相关的编译错误。看起来 XAML 窗口在您完成编译之前并不总是知道新类。
这对我来说是最好的建议，但由于@HK1 有时编译器错误列表中没有其他条目......列表中没有错误但还有其他错误。要查看它们，请注释或删除标有命名空间错误的行，再次编译，然后您将看到其他编译器错误。修改它们，之前标记命名空间错误的行恢复时就可以了。
我在代码中删除了一个在 XAML 中仍然引用的方法。一旦我删除了引用，这个错误就消失了。
这对我有用，真正的错误通常是隐藏的，即使在清理和重建之后也是如此。这些错误可能潜伏在未打开的 Xaml 文件中，请确保打开所有这些文件。
我发现了一个提示，它确实帮助我减少了出现在左上角“错误列表”选项卡上的错误下拉列表选择“打开文档”，因此它只会显示打开文档中的错误，我去未提交的更改并打开所有文件，所以我知道这些文件中只有少数文件破坏了整个解决方案

【解决方案24】：

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

【讨论】：

【解决方案25】：

在我的例子中，用户控件被添加到主项目中。我尝试了上述各种解决方案均无济于事。要么我会得到 Invalid Markup 但解决方案会编译并工作，要么我会添加 xmlns:c="clr-namespace:MyProject;assembly=MyProject" 然后会显示标记，但我会收到一个编译错误，即 XML 命名空间中不存在该标记。

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

【讨论】：

【解决方案26】：

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

在解决方案探索中，在包含 xaml 的项目节点上
右键单击项目并选择“卸载项目”
右键单击项目并选择“重新加载项目” 确保您的项目仍被选为“启动项目”。如果没有：
右键单击项目并选择“设置为启动项目”

无需重建或关闭 Visual Studio。

【讨论】：

【解决方案27】：

添加到堆中。

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

【讨论】：

【解决方案28】：

我的解决方案是解除对程序集 DLL 的阻止。您收到的错误消息并未表明这一点，但 XAML 设计器拒绝加载它所谓的“沙盒”程序集。您可以在构建时在输出窗口中看到这一点。如果从 Internet 下载 DLL，则它们会被阻止。要取消阻止您的第 3 方程序集 DLL：

在 Windows 资源管理器中右键单击 DLL 文件并选择属性。
在“常规”选项卡底部单击“取消阻止”按钮或复选框。

注意：只有在您确定 DLL 安全的情况下才能取消阻止它们。

【讨论】：

这对我有用 - 我从 Dropbox 下载了一个项目，但遇到了错误。我还不得不删除 ShadowCache

【解决方案29】：

我最近在 .NET 4.6.2 中为我的 WPF 项目使用 VS 2015 Update 3 时遇到了这个问题。我的项目副本位于网络文件夹中，我将其移至本地并解决了问题。

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

【讨论】：

【解决方案30】：

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

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

【讨论】：

换句话说，项目的 .NET Framework 版本不能早于被引用项目的 .NET Framework 版本。