名称 < ... > 在名称空间 clr-nampace < ... > 中不存在

我有一个小的 WPF 应用程序,用于编译只是罚款,但不再是。我不知道它是从什么时候开始停止建造的。前一天还好好的,第二天就不好了。

下面是项目结构:

enter image description here

除了标准的.net dls 之外,没有其他项目或外部引用。

下面是问题产生的用户控件:

<UserControl x:Class="TimeRecorder.HistoryUserControl"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:local="clr-namespace:TimeRecorder.ViewModel"
xmlns:framework="clr-namespace:TimeRecorder.Framework"
mc:Ignorable="d" Height="Auto" Width="Auto" Padding="5">
<UserControl.Resources>
<local:HistoryViewModel x:Key="ViewModel"/>
<framework:BoolToColorConverter x:Key="ColorConverter"/>
</UserControl.Resources>
<StackPanel DataContext="{StaticResource ViewModel}">

我得到的错误是这样的: http://i48.tinypic.com/5u1u8w.png

请注意,这不仅仅是屏幕快照中的一个文件,而是我在这个项目的所有用户控件/窗口文件中以类似的方式在 xaml 中添加的所有引用。

因此,文件在那里,文件中的名称空间是正确的,xaml 文件中的名称空间/类名称(据我所知)是正确的。当我输入 xaml 时,我会得到智能感知,所以它会找到文件,但是当它编译时就不行了。

其他文章中最常见的解决方案是。网络框架版本。当前设置为。我的主要项目和测试项目的 NetFramework4。完整版本不是客户端配置文件。

我想我搞砸了: 在配置管理器中,两个项目的 Platform 都设置为 AnyCPU,但是在尝试解决这个问题时,我注意到主项目被设置为 x86,而测试项目被设置为 AnyCPU。因此,我在配置管理器中为主项目手动添加了 AnyCPU。然而,我真的不知道我这样做是否正确,甚至不知道我是否应该这样做。因此,作为一个附加问题,是否有一种方法可以重置配置管理器到其默认状态?这对主要问题有什么要说的吗?我不知道是否总是将主项目设置为 x86,或者我以某种方式将其更改为 x86,然后它就坏了。正如前面提到的,这个项目在一段时间内编译得很好。

107451 次浏览

Every time it happend to me i just restarted visual studio, re-built the solution and it worked just fine.. can't say why

  • i would recommend to Rename x:Key="ViewModel" maybe there is a glitch
  • and if you type local: does VS show you HistoryViewModel?
  • also check if your Class is public

In addition to the "does not exist in the namespace" message, I was also getting a message from the designer that it could not display the window for x64 and ARM targets.

I have just found that switching the build to x86 mode, doing a rebuild solution, then switching back to x64 mode and then rebuilding again fixes [both] problems.

Simply rebuilding the x64 solution did nothing.

This is what worked for me on Visual Studio 2012 (Update 3).

  • Restart Visual Studio
  • Add current assembly to namespace declaration xmlns:framework="clr-namespace:TimeRecorder.Framework;assembly=MyAssembly
  • Build -> Build Solution

What worked for me: - Switch solution configuration from Debug to Release - Switch back configuration from Release to Debug

Rebuild your solution (sometimes clean then build works better). Then look at your error list, scroll to the very bottom, and it will most likely indicate an error that is not allowing your assembly to compile, and the XAML compiler is most likely using a cached version of the assembly, not the new one you mean to build.

I had the similar issue. In my case, I had to do the following

  • remove the referencing markup from xaml (in this example, <local:HistoryViewModel x:Key="ViewModel"/>)
  • build the Class ( in this example file which contains HistoryViewModel class )
  • Once its built, add the referencing markup in xaml
  • build again

The above method worked for me.

None of the solutions worked for me. I fixed it this way:

  • Remove the dll of the library from the References
  • Download the source code of the library (instead of just the dll file)
  • Build the library's project to get a new dll file
  • Add the new dll file to the References of the main project

Had this problem going round in circles wasting a few hours. I moved a separate user control dll into the project so it was compiled in the project and not a dll referenced. This broke the whole project so I then went through checking meticulously all namespaces, paths and file names. Tried deleting obj files, changing between release and debug, between x86 and AnyCPU. Opening saving all, recompile still no joy.

Remember having a similar problem before previously, the error flagged in VS2013 was not directly related to where I had to modify the XAML but by using

x:Name="myControl"

on all controls, instead of

Name="myControl"

fixed it.

This is a recurring problem for me. One of the time I found the solution looking into the Warning tab. It was a .NET framework version issue and it stated the following:

Warning 9 The primary reference "myDll" could not be resolved because it was built against the ".NETFramework,Version=v4.5.2" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".

There is a glitch with their buffering of the objects layouts. If anything gets renamed or moved, it gets lost. What generally works for me is to create a completely new class and copy in all the old code, get it working on the new class, then remove the original class. Sometimes after you get it up and running with the new class name, you can try renaming it back to the original name (but usually not)

Here's a weird example of a similar thing:

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:controls="clr-namespace:Gtl.Ui.Controls"
mc:Ignorable="d"
d:DesignHeight="120" d:DesignWidth="120"
Background="Transparent">
...
</UserControl>

will compile (VS2013).

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:controls="clr-namespace:Gtl.Ui.Controls"
mc:Ignorable="d"
d:DesignHeight="120" d:DesignWidth="120"
Background="Transparent"
IsVisibleChanged=onIsVisibleChanged>
...
</UserControl>

produces the error "type Ui not found in Gtl.Ui.Gtl" (and I assure you the handler method exists in the code-behind). The work-around is to add the handler in the class constructor, but c'mon Microsoft, wtf is going on?

I was using xmlns:local="using:MyRootNamespace.ChildNamespace" at the header of the .xaml , and i turned it into xmlns:local="clr-namespace:MyRootNamespace.ChildNamespace" ... well, I just let intellisense do the job, and it worked.

The problem is that when you create the x86 target, the output path for the particular project is set to bin\x86\Debug. It looks like Expression blend doesn't like this at all. It seems to only interested in whats in bin\Debug.

If you changed your output path(s) for the x86 project to bin\debug for example, then I'm sure you'd find it will work. Well, works for me anyway :)

I faced the same issue when i was trying to call the namespace in xaml. was showing that class is not available in the namespace. I searched a lot. Finally i found this issue was with VS. I am using VS 2013. I tried below steps:

  1. Build-->Configuration Manager--> Active Solution Platform --> Changed to x64 and x86 and Any CPU.
  2. Closed the VS and opened again.
  3. Change

    xmlns:VM="clr-namespace:MyFirstAppViewModel"
    

    to

    xmlns:VM="clr-namespace:MyFirstAppViewModel;assembly=ViewModel"
    

What I found that helped (especially if this error occurs in App.xaml) is to comment out the reference(s) that gives you trouble, rebuild, then uncomment. I think what this does is allows the entire project to actually build instead of stopping the build at the error.

From what I can gather, the app is trying to build the files in a certain order, so when App.xaml or presumably any other class file errors in a reference, the file that is causing the error hasn't been compiled correctly, hence why it doesn't find the file in that namespace.

I Changed Target Framework My Application of ".Net Framework 4.5" to ".Net Framework 4.6" and it worked!

The Target Framework of the .dll file you adding should be the same as the Target Framework of your app.

Ran into this issue today with Visual Studio 2017 Community Edition. Tried all the suggestions here (reset VS 2017, changed from x64 to x32 and back again etc etc) and from other sources to no avail. Intellisense knows everything is there but I was getting the same error everytime.

Anyway, my fix turned out to be very simple ... aren't they always when you have spent a couple of hours on the problem!

Basically, I did the following ...

  1. Remove offending code from xaml file (just 3 lines in my case)
  2. Build project so you get a successful build
  3. At this point the layout magically appeared in the designer window which was a good sign!
  4. Reinserted the code I removed in point 1. including the xmlns: entry
  5. At this point you shouldn't get any blue squiggles ... hopefully
  6. Build the project again

It's seem that by getting a successful build, it must reset 'something' within VS and/or the assembly. Once you have a successful build try inserting your code again.

This error usually occurs when project was not build successfully during the last build.

Step-1) First remove all the error causing code from the XAML or .cs file and build & start the project by pressing F5.

Step-2) Add add your error causing code in XAML one by one.

Just run code analysis from Build menu

I found that running the command "Run Code Analysis" re-builds everything and almost always fixes the problem (right click project > Analyze > Run Code Analysis). This also generally re-builds the resource files also so that strings, etc. can be found.

Tried all solutions on this thread but none worked. It turned out to be cause by the solution configuration. My WPF app was set to build for X64 because of some native dependencies that require it but the solution configuration was still set to AnyCPU for the project. Creating a new X64 configuration for the project in the solution configuration manager allowed the XAML designer to finally recognize my type and namespace.

Before adding the name space to your .xaml file, please make sure you are not having any compilation errors due to existing code.

Once all the compilation checks are OK, then rebuild your solution and try adding the required namespace to use its class or properties.

I was facing the same issue. You get this error but still you can build your project successfully, The inconvenience is that you can not see the UI designing (or just want to clean the code & remove annoying wiggly lines). Read many posts are tried several things but following works like a charm.

Tried this in Visual Studio 2019:

Right click on your Solution -> Properties -> Configuration Properties, then change the project configurations from Debug to Release or vice versa.

After that, rebuild your solution. It can solve your problem.

A complete exit and restart of Visual Studio does often resolve these issues, as stated by a few people who have answered this post already. However, sometimes the errors will not be resolved because it is actually a build failure or a dependency issue instead.

When I have worked on WPF projects in Visual Studio, the XAML errors are not always the underlying cause, but rather a symptom of what is failing. Sometimes there are .net framework dependency issues those don’t show up in there Error List windows and you have to use the Output window to debug what is actually failing.

I have learned that the underlying cause (of why so many errors light up across multiple XAML files) can actually be an incorrect manifestation when the actual culprit originates from a completely separate class or project. Often resulting in a build failure. Especially in solutions with multiple projects, there can be a DLL dependency that fails to generate by one project, leading to a cascading failure that shows up as XAML document errors.

One of the downsides of XAML is that it requires a built copy of the library in order to verify the XAML since the element names match to actual classes. So sometimes you will get XML errors because a library didn't build correctly. Also when adding new controls, if you haven't built the project it won't be able to find the new classes. Just something to keep an eye on when looking at the errors.

Once you fix the underlying build issues outside of the XAML files, it will allow each of the dependent projects to build. In these situations, the errors being thrown across multiple XAML files have nothing to do with the document structure, but rather that the failure of underlying dependencies; it can break the affected XAML document's ability to render the required properties and bindings. This is misleading initially, but helpful for finding the underlying issue if you understand it.

https://i.stack.imgur.com/2oEWs.png

https://i.stack.imgur.com/dMwNX.png

Had the same issue and I resolved by keeping the exe inside the net5.0-windows folder.

Do not try to remove it in Post-build event command line.

"the name <...> does not exist in the namespace clr-namespace <...>" If this error persist, no matter what you do, there's most likely other error(s) in your solution that is related to the XAML file. For me the error got resolved when I solved other issues in my solution.

This may happen if you have errors other than this specific error also. More errors may cause the file not to compile properly and resulting in this error.

First try to remove other build errors and if possible warnings also. Then rebuild the solution.

If the xaml file has the correct namespaces and if you have recently modified the names of any projects within the solution, then here's something to try:

  1. Clean the whole solution
  2. Rebuild each project starting from the lowest in the dependency hierarchy to the highest one by one. Thus, if Project A depends on Project B and Project C, both of which have no further dependencies, then rebuild B and C first, followed by A.
  3. Unload the project with the errors and reload it. Then close and open the sln again if the errors persist.

By me the issue was that I renamed a view file after creating it so the class name didn't change so it actually wasn't able to import the view, hope this helps someone