I am building a C#/WPF application using VS2013, and I have the following class definition (in the same assembly of the running application):
namespace MyNamespace
{
public class MyKey
{
public MyKey() { }
public string name = "";
}
}
In MainWindow.xaml I have:
<Window x:Class="MyNamespace.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:MyNamespace"
Title="MainWindow" Height="350" Width="525" WindowState="Maximized" WindowStyle="None">
<Window.Resources>
<local:MyKey x:Key="key" />
</Window.Resources>
...
VS keeps reporting that
The name "MyKey" does not exist in namespace "clr-namespace:MyNamespace"
Any ideas?
P.S. I tried the following solutions (from already posted questions in stackoverflow) but none of them worked:
- Moving the class to a different namespace, then using the new namespace in xaml reference
- Restarting VS and cleaning/rebuilding the solution
- cleaning the solution then renaming its folder then building the solution again
- changing the reference to:
xmlns:local="clr-namespace:MyNamespace;assembly="
Edit: Additional info: The target architecture: X64, target framework: .Net 4.5
I had a similar issue. What fixed it for me was changing the build properties of the project, that was added as a reference. Turned out that the "Platform target" had been changed in the past. Setting it to "Any CPU" and rebuilding it solved the error.
Running VS Enterprise 2017 version 15.6.2 Targeting .Net 4.6.1
I had this same problem with a UserControl xaml page where in its resources it was trying to reference a ValueConverter. The namespace was correct, the intellisense would even drop it in for you, but the designer would not load the page and the code would not compile. I even tried moving one of the value converters out of the file and namespace in question and moving it to the code-behind. VS was getting so freaked out that it was claiming the InitializeComponent() method in the code-behind constructor was non-existent.
What I think finally fixed it for me was when I realized the ValueConverter class was missing the leading attribute like this:
Once I added that line, I did a quick solution clean and compile and then it compiled and worked. Then suddenly the xaml could see all the validation rules and value converters in that file. And now I've realized that the other 3 value converters in that file also didn't have a ValueConversion attribute on them and yet the code still compiles now. Maybe something about the incoming types in that first converter were vague.
It's still somewhat of a mystery. I know I should back out my change and see if the error is reproducible, but after fighting that code for most of a day I'm sick of looking at it. It was an old Prism project that wasn't running and I upgraded it to Prism 7.0 libraries. I'd also tried resetting all the processor settings to 'Any CPU'. It complained about the bootstrapper being obsolete but I'd ignored it. I'd rebooted and cleaned everything multiple times. I'd even deleted the .vs folder. I probably should have tried earlier to outright delete the obj and bin folders - that's the one thing I hadn't done.
This wasn't my project. Normally I always build value converters one to a file with the file named the same. I wouldn't think that would matter, but the whole error was a little crazy in the first place.
One common solution to this known VS bug that you haven't specified as having tried is changing the build target platform.
If your current build target platform is x64, change to x86. If it's currently x86, change to x64.
Clean and Build solution for new target platform.
Change back to desired target platform and re-build.
One possible solution is by removing all the .dll files from Debug and Release folder.
Because sometimes when you refer to the project it refers to the pre-built dlls, even if you running your project in debug mode.
Remove all files from debug and release folder and build that project again, now add reference of this project to where you want. Worked perfectly fine on my end.
I had the same issue in VS2012 express edition. Solved the issue using the command
"WDExpress/ResetSettings" in vs2012 command prompt.
https://stackoverflow.com/a/33706647/4855197