148

使用 VS2012 处理 VB.NET WPF 应用程序。我有一个用于学习 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"

（在 a 中定义的对象<Grid>）

  <c:UpdatingMediaElement Name="MyMediaElement" />

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

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

4

40 回答 40

267

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

尝试执行以下操作：

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

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

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

于 2014-08-01T11:07:28.277 回答
54

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

前任：-

xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"
于 2013-04-01T11:35:14.930 回答
38

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

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

于 2013-05-28T09:48:16.210 回答
32

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

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

于 2016-03-03T18:44:54.017 回答
24

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

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

于 2014-12-26T22:00:44.477 回答
8

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

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

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

于 2017-03-24T14:33:05.120 回答
8

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

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

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

于 2017-12-15T09:36:09.387 回答
7

不知道这是否对其他人有帮助

我是 WPF 的新手，并且仍然是 VB.net 的新手 - 所以我假设得到这个错误是由于我做峰会愚蠢造成的........假设我是真的！通过将我的项目从共享驱动器移动到我的本地驱动器之一，我设法摆脱了它。错误消失了，项目编译完美，没有其他问题 - 还没有。看起来 VS2015 在共享驱动器上的项目仍然存在问题。

于 2016-03-14T18:12:30.190 回答
3

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

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

于 2016-09-28T10:37:40.737 回答
2

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

它不能通过重建解决方案来解决（设计视图和“名称不存在于命名空间”错误中）

我认为这是因为我玩过解决方案 - > 属性 > 配置属性上的设置

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

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

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

于 2013-06-02T13:55:20.167 回答
2

同样的问题困扰着 Visual Studios 2013 Service Pack 4。我还尝试了 Visual Studios 2015 Preview，结果相同。

这只是 Visual Studios 团队尚未修复的 WPF 可视化工具的一个限制。作为证明，在 x86 模式下构建会启用可视化工具，而在 x64 模式下构建会禁用它。

奇怪的是，智能感知适用于 Visual Studios 2013 Service Pack 4。

于 2015-01-15T23:24:46.883 回答
2

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

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

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

我怀疑MsBuild 和 Visual Studio 然后在试图在程序集 'Models' 中找到 'Monitor' 类型时出错。为了解决我尝试了以下方法：

  1. xmlns:monitor="clr-namespace:Models.Monitor;assembly=" - 如果命名空间与https://msdn.microsoft.com/en-us/library/ms747086(v=vs ) 位于同一程序集中，则此选项有效.110).aspx
  2. 还尝试了显式命名空间声明： xmlns:monitor="clr-namespace:Models.Monitor;assembly=Models.Monitor"

以上都不起作用。

最后我放弃了，作为解决方法，将我试图使用的 UserControl 移到另一个命名空间： 'ModelsMonitor'。在那之后我能够很好地编译。

于 2017-06-02T19:07:45.883 回答
2

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

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

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

于 2018-11-26T12:10:36.757 回答
2

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

  • 清洁项目
  • 退出VS
  • rm -rf /obj/*
  • 调用VS并重建
于 2019-04-30T20:30:04.147 回答
1

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

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

于 2016-07-22T07:44:42.120 回答
1

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

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

于 2016-07-25T23:40:41.093 回答
1

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

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

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

于 2017-02-21T15:15:44.723 回答
1

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

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

于 2017-04-03T15:59:30.150 回答
1

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

firstDepth.secondDepth.Fubar

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

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

firstDepth.secondDepth

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

不要这样做

于 2018-10-10T18:06:15.177 回答
1

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

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

于 2018-12-14T00:21:02.163 回答
1

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

于 2019-03-12T16:53:31.767 回答
1

如果没有一个答案有效

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

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

于 2020-07-06T16:18:18.933 回答
0

VB.NET 不会像在 C# 中那样根据文件夹结构自动添加命名空间信息。我想我正在经历与您相同的教程（在 24 小时内自学 WPF），并对 VB 进行相同的转换。

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

这里有另一篇文章展示了如何将其包含在您的项目模板中，以便它自动构建命名空间信息 - 添加新项目时自动添加命名空间

于 2013-09-30T14:57:08.920 回答
0

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

于 2014-09-14T21:56:26.337 回答
0

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

澄清一下：WPF 设计器可能会报告“名称 XXX 不存在于名称空间中......”，即使名称确实存在于名称空间中，并且如果构建后事件从构建文件夹（bin\Debug、bin\Release 等）。我在 Visual Studio 2015 中对此有个人经验。

于 2016-02-15T20:12:37.790 回答
0

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

于 2016-07-28T18:46:48.470 回答
0

添加到堆中。

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

于 2017-03-01T18:10:25.593 回答
0

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

于 2017-05-10T22:05:17.870 回答
0

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

于 2018-02-16T12:40:54.960 回答
0

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

于 2019-01-25T21:08:37.913 回答
0

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

于 2019-05-09T08:10:55.220 回答
0

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

  1. 删除对dll的引用
  2. 清洁、重建、建造
  3. 关闭 VS，解除对 dll 的阻塞（见下面的注释），删除影子缓存
  4. 打开 VS，清理，重建，构建
  5. 恢复对 dll 的引用
  6. 清洁、重建、建造

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

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

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

于 2019-08-23T18:10:55.427 回答
0

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

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

至： “Z:\Programming\SolutionFolder” （精确映射可选）

于 2019-12-14T11:17:41.770 回答
0

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

在此处输入图像描述

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

PS 发生此问题时，也可以从以下Warnings部分注意到：

在此处输入图像描述

于 2020-03-12T13:11:42.260 回答
0

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

在调试模式下为我修复了什么：

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

XAML 编辑器：禁用项目代码

  1. 切换回调试模式 => 错误消失了
于 2020-05-08T09:58:56.370 回答
0

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

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

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

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

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

于 2020-06-17T19:43:10.603 回答
0

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

于 2021-12-12T18:18:08.787 回答
-1

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

于 2017-10-05T20:48:29.157 回答
-1
  • 就我而言，问题是 Visual Studio 中的一个错误 - 因为该错误没有任何意义，当我重建时 - 一切都神奇地起作用了！经过 45 分钟的挫折后，这个解决方案使我的头部和显示器​​免于严重受伤。也许它也可以拯救你——它当然值得一试？

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

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

只需重建，它应该可以工作！

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

于 2019-06-24T02:52:58.203 回答
-1

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

于 2019-12-18T15:02:26.317 回答