The name does not exist in the namespace error in XAML

Question

Using VS2012 working on a VB.NET WPF application. I have a simple MusicPlayer tutorial app I am using to learn WPF. I am converting a C# version of the tutorial to VB.NET step by step.

It has 2 classes in the app that are both under the same namespace. I am able to reference the namespace in the XAML but when I try to reference the class object in XAML I get an error and I am not able to compile.

Strange thing is that the IntelliSense works fine with both referencing the namespace via the xmlns:c= tag and also when typing the class object using <c: But the object is underlined and errors are generated trying to build or work in the designer.

The .vb class files are in a folder called \Controls. The Main project Root Namespace is intentionaly left blank. The class is coded like this...

Namespace MusicPlayer.Controls
    Public Class UpdatingMediaElement
       .... code here
    End Public
End Namespace

The xaml looks like this

(namespace defined in the <Window > tag

xmlns:c="clr-namespace:MusicPlayer.Controls"

(object defined in a <Grid> )

  <c:UpdatingMediaElement Name="MyMediaElement" />

(error displayed) The name "UpdatingMediaElement" does not exist in the namespace "clr-namespace:MusicPlayer.Controls".

Not sure what is wrong or how to fix it?

Folse

Restarting the visual worked for me. (never underestimate the power of restarting) – Persiflage

A little help for those who are struggling with this: make sure your class is public. – Behlke

close the xaml document while starting/building the app – Questa

Just like Falaque said, restarting helps in many cases. In my case that was deleting my repository and cloning it again. This way you make sure that even those git-ignored files are deleted. – Mileage

Answer 1

When you are writing your wpf code and VS tell that "The name ABCDE does not exist in the namespace clr-namespace:ABC". But you can totally build your project successfully, there is only a small inconvenience because you can not see the UI designing (or just want to clean the code).

Try to do these:

• In VS, right click on your Solution -> Properties -> Configuration Properties

• A new dialog is opened, try to change the project configurations from Debug to Release or vice versa.

After that, re-build your solution. It can solve your problem.

Diastase

This worked for me as well but I also had to restart VS to clear the error list? Weird. – Kolivas

This still happens in Visual Studio 2015 Update 1. Your solution worked - thanks! – Bier

IN VS 2015 Update 2 there is no Configuration Properties under Solution->Properties. – Menton

Perhaps not, but I found that simply switching between Debug and Release mode on the toolbar worked regardless. – Indusium

@Indusium - yes it worked for me too. I changed it from debug to release, build the solution then checnge it back to debug then error's gone. – Paget

Or, right-click solution > "Clean Solution"; right-click solution again > "Rebuild". Done. – Chouest

Amazing ..:) Worked for me on VS15 – Wry

Confirmed on VS 2017 version 15.2 (26430.15) in July 2017. Simply changed in dropdown from Debug to Release, compiled and error was gone, changed back and compiled and error was still gone. – Dunnite

In addition to the above, I had to switch between x64 and x86 in Visual Studio 2015. Also, pay attention to the Zoom setting (for some reason mine got set to 3.57%, so even after a correct compilation the XAML did not show up). – Pasha

It also helps to open the solution through a mapped drive. If I open my solution with a UNC path it can not find the namespaces correctly. (Using VS Pro 2017) – Olds

(needed and) work also in VS2017, microsoft have to put it in official documentation :) – Ginsburg

It seems that VS17 is especially stubborn - Tried changing Rel/Dbg, changing x64/x86, deleted ShadowCache, ComponentCache, Bin/Obj folders, still have "errors" and designer doesn't work for this one very small app (other apps with like 50 WPF views work fine). Happened suddenly and can't go away. Had this prob before many times but first time on VS17 and can't fix it now. Still tho this is best answer as it worked so many times before. – Miracidium

I love how I come back to this answer, and I've already upvoted it, ...2.5 years ago. – Chouest

And it still occurs in VS 2017 15.7 (August 2018). I've long given up the hope that the VS development team is actually able to really improve this product at all. For me I had to put it back from ARM to x86 mode but the trick as about the same as Toan wrote. – Terina

Same issue. Switching to release makes the issue dissappear, but then back to debug makes it come back. Looks like it is an IDE issue which does probably not affect the code. I guess I will file an issue as well. – Exorbitance

Hit this in VS 2017 and found another thing to try to fix it. In your library references, go delete your xmlns:control ="clr-namespace:BadApp.BadLibrary", build, re-add the line, build, and that fixed it for me (after I'd tried the changing target build to Release and Debug trick). – Kcal

Worked for me in VS 2017 after I changed it back and forth twice – Medlin

Visual Studio 2019 - i commented out all code that referenced the file in this namespace. Built solution successfully. Uncommented code and it works. – Suprarenal

VS 2019. This shit just happened to me I've tried everything. commenting out/in rebulding, restarting, cleaning the solution, deleting the .suo files. Nothing works. I have literally EXACTLY the same datatemplates for other classes and it works perfectly. Just for three classes this doesn't work at all.... – Testate

Worked for me in VS 2017, I just switched to Release, didn't rebuild solution. – Killiecrankie

VS2019 net core 3 wpf, just switching the drop down from Debug to Release fixed it for me... smh... – Benco

@GregK. I have exactly the same. VS 2019 and tried every hint already. Nothing fixes that. – Cruise

Latest VS2019; no amount of cleaning/rebuilding would fix this but toggling between Debug/Release magically solved it. WPF is a burning pile of trash. – Decimal

"there is only a small inconvenience" sometimes it's not that small. Seeing a bunch of fake errors makes it so hard to find the real errors that prevent building the project. – Armrest

I can still reproduce this in VS2022. Hard to believe they could not fix this in 8 years... – Coussoule

Just to add that removing the sealed keyword from a class also takes away the error just in case one's classes are with that keyword. – Tereus

In VS2022, when you try to add you custom element, it will tell you to rebuild the project in order to see your changes. Make sure your namespaces for xmlns:local are correct. Other posts I read on this say to remove that line from your custom element. – Pulpit

Answer 2

If the assembly is different from the namespace in which your class is contained, you have to specfiy it explicitly.

ex:-

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

Arun

While it appeared to have solved my problem at first, it still throws the same error. However, now I'm even not able to build the solution anymore. – Accounting

@bouke Clean the solution and rebuild it – Arun

Awesome, thanx. That really helped – Officialism

This did it for me. The weird thing is that the converters were in the same assembly as the xaml file.... But they were on a different namespace. – Wifely

Thanks, the assembly was missing. – Shebat

Answer 3

In my case it was because of other compile errors. When other errors have been solved this seemingly related error was also removed from the list. Specially the errors at the bottom of the errors list and on pages you have recently changed.

So do not pay attention to this error directly and focus on other errors at first.

Bloom

Note that doing a build/compile resolved this problem for me, even though I didn't have any other unrelated compile errors. Looks like the XAML windows aren't always aware of new classes until you've done a compile. – Deiform

This was the best advise for me, but as @Deiform sometimes there's no other entries in the compiler error list... there aren't errors in the list but there are other errors. To see them, comment or delete the lines marked with the namespace error, compile again and then you will see the other compiler errors. Amend them, and the lines before marked with the namespace error will ok when you restore them. – Alurd

I had removed a method in code behind that was still referenced in XAML. Once I removed the reference, this error went away. – Lactoscope

This has worked for me, the real errors are often hiding, even after clean and rebuild. The errors can lurk in unopened Xaml files, make sure you open all of them. – Faythe

I found a hint which really helped me out reducing the errors appear at "error list" tab on top left drop down list select "open documents" so it will show you only the errors from the open docs , i go the the uncommitted changes and open all the files so i know that only few of those files is broke the entire solution – Ability

Answer 4

I've seen this issue go away by clearing the Xaml Design Shadow Cache. I had the issue with Visual Studio 2015 Update 1.

In Visual Studio 2015 the Cache is located here:

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

Process:

1. Right-Click on the solution in the Solution Explorer and Choose "Clean Solution"
2. Shutdown Visual Studio
3. Delete the ShadowCache folder
4. Reopened the Visual Studio project
5. Rebuild the solution

And voila no more namespace errors.

Rebutter

Sadly, didn't change a thing, for me. Still dealing with this annoying after almost a whole year. :/ – Dardan

Thanks! This ended up working for me. It's sad to see this tricks still being necessary in VS15 – Huskamp

You can use %localappdata%\Microsoft\VisualStudio\14.0\Designer\ to go immediately to the right folder – Privatdocent

Having a designer that only works if you build the solution is terrible. Imagine telling a car designer to build the whole car before seeing the design. – Uninterested

Good piece of advice. Thx. It hasn't solved the problem all by itself but helped me find a solution as it cut the number of compile errors from 190 to 5. – Civism

Don't want to add to the pile so just for somebody who will stumble here: in my case it was a shadowing namespace in XAML. I had one namespace, used a user control from it and then on another line in namespace declarations I had another one mapping the same ns to a different name. Thus it shadowed the former and then all hell broke loose. – Civism

Answer 5

Try changing the build target platform to x86 and building the project.

I noticed via Subversion that I apparently changed the project build Platform target to x64. This was the only change I had made. After making that change, the code was working for a short while before it started showing the same error you experienced. I changed the platform target to x86 to test and suddenly my designer was working again. Subsequently, I changed it back to x64, and the problem has disappeared completely. I suspect that the designer builds some kind of cached code in x32 and changing the x64 build platform breaks it when you make code changes.

Morey

I've had this re-occur and I can confirm this solves the problem for me. You can switch back to x64 after you build it in x86. – Morey

This worked for me too in VS 2012...after hours of trying to figure out something logical. Thanks, Tom! – Millsaps

Switching to x86 and back to x64 fixed the problem here, so thanks for inspiring me to try that. I had even closed VS, deleted bin and obj, and rebuilt, along with other suggestions, and nothing helped until this. – Mill

Yes, this also worked for me on VS2015 Update 2. However, it was necessary for me to reload my external dll files and rebuild them also. – Menton

With VS2015U2, I still get this issue in x64. Works great in Any CPU. Switching back and forth doesn't work for me. – Maudmaude

Worked with VS2017 15.6.7 – Raising

Worked. Changed project file from <PlatformTarget>x64</PlatformTarget> to <PlatformTarget>AnyCPU</PlatformTarget> – Kerbstone

Answer 6

Maybe another solution for when the project compiles but the XAML error is showing :

1. In solution explore, on the project node that contains the xaml
2. Right-click on the project and choose 'Unload Project'
3. Right-click on the project and choose 'Reload Project' Make sure that your project is still choosen as "startup project". If not :
4. Right-click on the project and choose 'Set as startup project'

No need to rebuild, or close visual studio.

Unwashed

Thanks Simon in 2017 - this worked for me, in version Version 17.9.2 (Visual Studio 2022) ... kind of a bizarre issue ... wonder what files it is caching. comment from 2024. – Farinaceous

Answer 7

Jesus... This is still a problem five years later in Visual Studio 2017. Since I'm new to WPF, I was sure the problem was somehow me, but no, everything compiled and ran correctly.

I tried rebuilding, cleaning and rebuilding, switching between x86/x64 output, rebooting Windows, cleaning the ShadowCache folder, adding ";assembly={my main assembly name}" to the XML namespace declaration, nothing worked! The single thing that did:

Put my static class of Commands (in my case the deal was about making the design discover my WPF Commands) in its separate assembly and changing the assembly name to that one's instead.

Bleary

Answer 8

In my case, it was just a weird bug.

I had the class I was trying to use in my namespace however Visual Studio kept throwing an error saying the class did not exist in the given namespace.

What I did to fix it was really silly but worked like a charm.

I commented out all the lines of code where I was trying to use the class, cleaned the build, rebuilt and the project was up and running.

Then I just uncommented the lines of code I had commented earlier and well, Visual Studio was no longer throwing me any errors.

Rebuild again and you are ready to go.

Foret

Answer 9

Dunno if this will help anyone else

I'm new to WPF and still a novice with VB.net - so I was assuming that getting this error was being caused by me doing summit silly........ suppose I was really! I've managed to get rid of it by moving my project from a shared drive to one of my local drives. Error's disappeared, project compiles perfectly no further issues - yet. Looks like VS2015 still has problems with projects held on a shared drive.

Odell

This was the case for me, I moved it to my vm (on which I develop) and boom no problems. Thanks! – Selfless

This was the case for me as well it appears. Moving them to being on a local drive (instead of a network share -- as set up by Parallels to union both the Mac and Windows filesystem a bit), fixed the issue. – Endoblast

Answer 10

I went through all the answers and none helped me. Finally was able to solve it by myself, so presenting the answer as it might help others.

In my case, the solution had two projects, one containing the models (say the project and assembly name was Models) and another containing the views and view models (as per our convention: project, assembly name and default namespace were Models.Monitor). The Models.Monitor referred Models project.

In the Models.Monitor project, in one of the xaml I included the following namespace: xmlns:monitor="clr-namespace:Models.Monitor"

I suspect that MsBuild and Visual Studio then were erroring out as they were trying to find a 'Monitor' type in the assembly 'Models'. To resolve I tried the following:

1. xmlns:monitor="clr-namespace:Models.Monitor;assembly=" - which is valid if the namespace is in same assembly as per https://msdn.microsoft.com/en-us/library/ms747086(v=vs.110).aspx
2. also tried the explicit namespace declaration: xmlns:monitor="clr-namespace:Models.Monitor;assembly=Models.Monitor"

Neither of the above worked.

Finally I gave up, and as a work around moved the UserControl I was trying to use to another namespace: 'ModelsMonitor'. I was able to compile fine after that.

Sherlock

Answer 11

I'm also having a lot of trouble with this one! Intellisense helps me complete the namespace and everything, but the compiler cries. I've tried everything I found in this and other threads. However in my case what helped in the end was writing something like this:

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

Leaving the assembly name empty. No idea why. But it was mentioned here. I must add I am developing an assembly, so the assembly attribute might make sense. But entering the assembly name did not work. So weird.

Extend

Answer 12

I had the same problem , and in my case the the Markup Design View asked me to rebuild the solution and did not show me the form layout with this message: Design view is unavailable for x64 and ARM target platforms, or Build the Project to update Design view.

It does not get solved by rebuilding the solution (neither the design view nor the "The name does not exist in the namespace" error)

I think it was because I had played with the settings on Solution -> Properties > Configuration Properties

I finally resolved the problem with 2 jobs:

1. Checking all check boxes on Build Column of the page: Solution -> Properties -> Configuration Properties
2. Changing the solution configurations from Debug to Release or vice versa.

I think it's a bug in Visual Studio2012 Update 2.

Satiable

Answer 13

I had this problem recently using VS 2015 Update 3 for my WPF project in .NET 4.6.2. The copy of my project was in a network folder, I moved it locally and that solved the problem.

This may solve other sort of problems, as it looks like VS 2015 doesn't like network paths. Another issue that is a big problem for them is syncing git repositories if my project is in a network path, also solved by moving it locally.

Heuer

Answer 14

The same problem plagues Visual Studios 2013, Service Pack 4. I also tried it with Visual Studios 2015 Preview with the same results.

It's just a limitation of the WPF visualizer which the Visual Studios team hasn't fixed. As proof, building in x86 mode enables the visualizer and building in x64 mode disables it.

Strangely enough intellisense works for Visual Studios 2013, Service Pack 4.

Pettaway

Answer 15

In my case the problem was due to some phantom files under the project's obj directory. The following fixed the issue for me:

• Clean project
• Exit VS
• rm -rf /obj/*
• Invoke VS and rebuild

Fairminded

Answer 16

Try verifying your assembly references. If you have a yellow exclamation mark on the project references there's a problem there and you'll get all kinds of errors.

If you know the project reference is correct, check the Target framework. For instance, having a project using the 4.5 framework reference a project with 4.5.2 framework is not a good combination.

Decapolis

In other words, project's .NET Framework version can't be older than referenced project's .NET Framework version. – Rigid

Answer 17

Looks like this problem may be solved through a variety of "tricks."

In my case, I had been building/rebuilding/cleaning the entire solution, instead of just the project that I was working on within the solution. Once I clicked "Build [my project]," the error message went away.

Unreadable

Answer 18

The solution for me was to unblock the assembly DLLs. The error messages you get don't indicate this, but the XAML designer refuses to load what it calls "sandboxed" assemblies. You can see this in the output window when you build. DLLs are blocked if they are downloaded from the internet. To unblock your 3rd-party assembly DLLs:

1. Right click on the DLL file in Windows Explorer and select Properties.
2. At the bottom of the General tab click the "Unblock" button or checkbox.

Note: Only unblock DLLs if you are sure they are safe.

Corybantic

This worked for me - I had downloaded a project off of dropbox and was getting the error. I also had to delete the ShadowCache – Halda

Answer 19

In my case, the user control was added to the main project. I tried various solutions above to no avail. Either I would get Invalid Markup but the solution would compile and work, or I would add the xmlns:c="clr-namespace:MyProject;assembly=MyProject" and then the markup would show, but I would get a compile error that the tag does not exist in the XML namespace.

Finally, I added a new WPF User Control Library project to the solution and moved my user control from the main project into that one. Added the reference and changed the assembly to point to the new library and finally the markup worked and the project compiled without error.

Bedplate

Answer 20

In my case I had a namespace and class spelled exactly the same, so for example, one of my namespaces was

firstDepth.secondDepth.Fubar

which contains its own classes (e.g. firstDepth.secondDepth.Fubar.someclass)

but I also had a 'Fubar' class in the namespace

firstDepth.secondDepth

which textually resolves to the same as the Fubar namespace above.

Don't do this

Maximilianus

Answer 21

This problem can also be caused if the assembly that you're referencing isn't actually built. For example, if your xaml is in Assembly1 and you're referencing a class also in Assembly1, but that assembly has errors and isn't building, this error will be shown.

I feel silly about it, but in my case I was tearing asunder a user control and had all sorts of errors in the related classes as a result. As I was attempting to fix them all I started with the errors in question, not realising that xaml relies on built assemblies to find these references (unlike c#/vb code which can work it out even before you build).

Nosh

Answer 22

I get this problem all the time. My views are in a WPF Custom Control Library project (a variant on Class Library). I can reference pre-built assemblies, but cannot reference any code in another project of the same solution. As soon as I move the code to the same project as the xaml it's recognized.

Escheat

Answer 23

This happened to me already twice in a complex WPF app, in it there are 4 multi platform projects, 1 shared project, 2 support libraries, and 1 test project..

This very specific XAML namespace error happened twice on very recently modified files on the Shared project. In both of my cases, it was a new c# file added with a repeating namespace entry;

Like namespace MyProgram.MyFolder.MyProgram.MyFolder

I double pasted it once by mistake, and once it was due to JetBrains Rider double pasting the namespace. (If you ever rename a project in Rider, it time to time starts double pasting namespaces on new file creations, especially on Shared projects..). These c# files with repeating namespaces were then called in the ViewModels where XAML files were referencing to. Well you then get these unrelated and misleading errors, you can have a problem with one file, all your Xaml files will start erroring out eventually.

Anyways, if you get these kind of errors, it's most of the time an issue on a very newly added file or code change. My suggestions would be to look at your very recent changes.

Kilogram

A similar thing happened to me. Because I moved the only existing file in that namespace first from the main project folder to my Converters folder. The namespace in C# class didn't update so there actually was no defined yet. I kept insisting that the namespace exists since the folder exists, but it's not the case. Good lesson learned. – Canterbury

Answer 24

If non of the answers worked

For me was .Net Framework version compatibility issue of the one i'm using was older then what is referencing

From properties => Application then target framework

Ability

Answer 25

VB.NET does not automatically add the Namespace information based on the folder structure as it does in C#. I think I am going through the same tutorial as you (Teach Yourself WPF in 24 Hours), and doing the same conversion to VB.

I found you have to manually add the Namespace information to Both the XAML Class and the XAML.VB code behind to be able to use the Namespaces as described in the book. Even then, VB doesn't automatically Assign the Namespace to the Assembly as it does in VB.

There is another article here that shows how to include this in your project templates so it does build the Namespace information automatically - Automatically add namespace when adding new item

Cupola

Answer 26

In the solution property page, check the platform of the assembly that contains "UpdatingMediaElement" and the assmeblies that contain any of the superclasses and interfaces from which "UpdatingMediaElement" subclasses or implements. It appears that the platform of all these assemblies must be "AnyCPU".

Americano

Answer 27

Another possible cause: A post-build event is removing the project DLL from the build folder.

To clarify: WPF designer may report "The name XXX does not exist in the namespace...", even when the name does exist in the namespace and the project builds and runs just fine if a post-build event removes the project DLL from the build folder (bin\Debug, bin\Release, etc.). I have personal experience with this in Visual Studio 2015.

Hohenstaufen

Answer 28

Ok, so none of these tips worked for me, unfortunately. I was able to eventually solve the issue. It seems that Visual Studio does not play nicely with network drives. I solved this issue by moving the project from the shared drive to my local and recompiled. No more errors.

Salutatory

This answer is supplied at least twice above. – Dewie

Answer 29

Adding to the pile.

Mine was the assembly name of the WPF application was the same assembly name as a referenced dll. So make sure you don't have duplicate assembly names in any of your projects.

Lopes

Answer 30

I had the solution stored on a network share and every time I opened it I would get the warning about untrusted sources. I moved it to a local drive and the "namespace does not exist" error went away as well.

Xylograph

Answer 31

Also try to right click on your project->properties and change Platform target to Any CPU and rebuild, it will then work. This worked for me

Muniment

Your suggestion is a significant change that may not even be a possibility for the OP if they are targeting a particular environment. Either way it is very unlikely to be the cause of the problem, and if it solved the issue for you then I would suggest that your actual problem was mismatching project configurations, which would have manifested itself in many different ways to the problem shown here. – Powerful

Answer 32

I had the added the assembly as a project - first deleted the ddl that was added specifically to the references to the dll - that did it.

Blanche

Answer 33

In my case, this problem will happen when the wpf program's architechture is not exactly same with dependency. Suppose you have one dependency that is x64, and another one is AnyCPU. Then if you choose x64, the type in AnyCPU dll will "does not exist", otherwise the type in x64 dll will "does not exist". You just cannot emilate both of them.

Norikonorina

Answer 34

A combination of two ideas in this thread worked for me, so I'll post what I did in the hopes that it helps someone else over the next 5 years that this problem continues. I'm using VS2017 Community)

1. Delete reference to dll
2. Clean, Rebuild, Build
3. Close VS, Unblock the dll (see note below), Delete shadow cache
4. Open VS, Clean, Rebuild, Build
5. Restore reference to dll
6. Clean, Rebuild, Build

I may not have the order exactly right in steps 2, 4, and 6 but I was grasping at straws after spending nearly 2 hours with this problem. I think the key for me was the combination of removing the reference, unblocking the dll and deleting the shadow cache.

(Note for step 3 - The dll I'm using was written by a coworker/mentor of mine, so I know it's safe. Careful with this step if you don't know the source of your dll)

I'll be bookmarking this thread for posterity, since it appears that MS has no desire to clean this stuff up. WPF is hard enough to learn on it's own, and having to hack through stuff like this when you've done everything right is infuriating. 🤬🤬🤬

Papery

Answer 35

As another person posted this can be caused by saving the project on a network share. I found that if I switched from using a network path to a mapped network drive everything worked fine.

from: "\\SERVER\Programming\SolutionFolder"

to: "Z:\Programming\SolutionFolder" (exact mapping optional)

Homologue

Answer 36

Try checking the References section, and see if there is a warning icon over the library reference you included:

If you see it then go to the Project -> Properties -> Application and make sure that both libraries are targeting the same version of the .NET framework.

P.S. When this issue happens it can also be noticed from the Warnings section:

Ferren

Answer 37

In Visual Studio 2019 I was able to fix it by changing the dropdown to Release as recommended in other answers. But when I changed back to Debug mode the error appeared again.

What fixed it for me in Debug mode:

1. Switch to Release mode
2. Click on "Disable project code" in the XAML Designer

3. Switch back to Debug mode => the error is gone

Peneus

Answer 38

One more twist, in the hope that someone else may find it helpful. I had the same issue as everyone else here, and I tried all the suggestions--verified references, Debug/Release switch, restarted VS, checked build config level, rebuilt numerous times--and NOTHING HELPED. Finally, I tried the suggestion where I created a new Project and moved the one single object I was trying to resolve to that project, and THAT solved the reference issue.
However--and this is the reason I'm adding yet another post, here--eventually I figured out that the actual problem was that the original Project included one object referencing a SQLite database. It turned out that the installed NuGet SQLite package was actually causing the issue. When I moved the DB-accessing code and the NuGet SQLite reference to its own project, then I was able to move the original object back into the original project with all the others, and the referencing issue did not reappear. Evidently there's some setting in the NuGet SQLite package that was confusing the system.

Septuagenarian

Answer 39

I've stumbled accross the same problem too.

In my case, I deleted the x:class property from my XAML file by mistake and it didn't work anymore.

Conditioner

Answer 40

FWIW... I was having this exact issue today and come to find out, it was due to opening my Solution/Project from a UNC Network Path instead of a mapped drive.

As soon as a mapped a drive to my repo and opened the project, it worked great.

TLDR: Try opening project from a mapped drive

Spradlin

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Egeria

Answer 41

Removing the sealed keyword from a class also takes away the error just in case one's classes are with that keyword. It worked for me!

Tereus

Answer 42

For me, I created a custom control and a second Generic.xaml because I didn't notice that a new folder that contains the associated Generic.xaml was created. So I just removed the duplicated Generic.xaml that I created and modified the other one.

Imperialism

Answer 43

In my case it was an upper case vs. lower case problem inside of the namespace. One single letter was different.

Compare exactly:

• The namespace definition of your UserControl <UserControl x:Class="..."
• The local definition of your UserControl xmlns:local="..."
• The namespace definition of the parent UserControl xmlns:myNamespace="...", which you use to embed your UserControl.

The search function of Visual Studio is your friend, when you enable the option for case-sensitivity. If the namespace is different, it's not highlighted at all places.

If the case-sensitivity is your problem, then fix it, clean the solution, close Visual Studio, restart it and compile again.

Hardigg

Answer 44

Shoonya hit upon the same issue as I did, an overlap of namespaces in my local project with that of a referenced library. However, the solution is a little easier than "Create a new library and move your code".

Solution: ensure the namespace of any objects in your project don't overlap with that of an assembly. Moving the classes will work, but just editing your code/namespaces is sufficient.

Example to reproduce the issue;

• Reference a library that you intend to use in XAML (like a control), e.g. SomeLibrary.Wpf
• Have at least one object in your project with a namespace like MyProject.SomeLibrary

The XAML will no longer compile with a message saying "The name MyProject.SomeLibrary.Wpf does not exist"

It seems that the assembly resolver for the XAML references makes the assumption that if any object has a namespace that matches the start of a 3rd party reference, that all objects should be pulled from the local project.

Whichever

Answer 45

Add an empty constructor for your view model and rebuild solution.

Donnydonnybrook

Answer 46

I had the same symptoms "The name does not exist in the namespace error", but the cause turned out to be different. I had a C: drive crash and had to reinstall Visual Studio 2017. I restored my source code files and opened the solution. Built it. No dice. As well as the "Name does not exist in the namespace" errors I noticed my sub-projects complaining that they couldn't find a MyProject.cs file ('MyProject' is not the actual project name, just used here as an example). I had a hunt for where MyProject.cs had gone, then remembered that there was never any such file! I looked in the Properties folders of each sub-project and found that Visual Studio had off its own back added bogus references to MyProject.cs!! I removed these references and now the solution builds fine like it used to.

Katelynnkaterina

Answer 47

• In my case, the problem was a bug in Visual Studio - because the error didn't make any sense and when i Rebuilt - everything magically worked! After 45 minutes of frustration, this solution saved both my head and monitor from serious injury. Perhaps it may save you as well - it's certainly worth a shot?

Solution: Try Re-building the solution

• Short cut to re-build: CTRL + SHIFT + B

Solution 2: Try Restarting Visual Studio

Forewoman

yes, Rebuild will solve most of problems because xaml tried to call an element that is not build yet. Rebuild every time you create a new class and try to use it on xaml – Gowk