My C# WinForms solution has two projects.
A DLL which is the main project I'm working on, and an executable WinForms I call "Sandbox" so that I can compile/run/debug the DLL easily in one go.
I'm working in .Net 4.0 for both projects.
Everything was working fine until I added some seemingly innocent code, and a reference to System.Web in the DLL.
Now my Sandbox project can't see the namespace of the DLL project. I didn't change anything which I believe should have affected this.
If I delete the project reference to the DLL from the Sandbox references and re-add it, then the red underlines all disappear and the colour coding comes back for all my classes etc; but as as soon as I try to build the solution, the whole thing falls apart again.
When I right-click the DLL project in the Sandbox's references and view in object browser, I can see the namespace and all the stuff in there.
I have a feeling this might be some sort of bug?
Is this some sort of VS2010 bug? I had this same issue a few months ago and I could only fix it at the time by making a whole new project and re-importing my files. This time, however, I have a bajillion files and will only do that as a last resort!
Edit:
After panickedly going through and undoing all my changes, trying to find what caused the problems, it seems to be this line:
string url = "http://maps.google.com?q=" + HttpUtility.UrlEncode(address);
If I comment out this line, then I get no namespace errors and the project builds fine. I can't see anything wrong with this line though.
I'm ready to declare this a bug in VS2010, this has bitten way too many programmers already. The fix is easy: Project + Properties, Application tab, change Target Framework to ".NET Framework 4" instead of the Client Profile that is selected by default.
System.Web is not included in the client profile. Having this option in the first place is quite silly, the client profile is only 15% smaller than the full version of .NET 4.0. Having it selected by default is even sillier. But I digress.
UPDATE: mercifully this all got fixed in VS2012. Which no longer makes the client profile the default for a new project. And the client profile got retired completely in .NET 4.5, good riddance.
Check to make sure that both projects are using the non-client profile for their target framework (go to each project's properties to do this).
One possibility is that the target .NET Framework version of the class library is higher than that of the project.
I faced this problem, and I solved it by closing visual studio, reopening visual studio, cleaning and rebuilding the solution. This worked for me. On some other posts, I have read the replies and most of users solved the problem by following this way.
Try building only the project with the Sandbox dll first independently.
Then point your executable project to the required dll and ensure copy local is set to true. in reference settings.
Tthen build the executable project.
Changing the target framework from the ".NET Framweork 4 Client Profile" to ".NET Framework 4" worked for me with a similar problem. I agree that the client profile doesn't seem to have much of an advantage to using it. I seem to get nailed with weird errors that I hunt for until I remember that Visual Studio defaults to the client profile. I guess the moral of the story when getting an error is: if "Rebuild Solution" doesn't work, check the Target framework...
If you tried already doing the Framework change, and still not worked, I hope this works for you (as it did for me): Simply add the necessary references from within your projects. Very obvious but I was doing it wrong until I found what was the issue.
I just had this issue and it turned out to be I had multiple namespaces being used that had the same object name (i.e. business objects had the same names as mvc models);
Fully qualifying the names fixed the issue for me.
I have a weird error showing up in my project when it is open in the VS2012 IDE. Everywhere where I make use of another referenced project it suddenly says "Type or Namespace name could not be found". And by "says", I mean it has the text underlined in red with the error when I hover over it. The intellisense doesn't work for that code. BUT (and here's the weird part), the errors do not show up in the error console and the project builds and runs fine.
I can even debug and step through the code and it works perfectly fine. So at runtime the project is referenced fine but at design time the IDE can't find it. This worked for the past 2 weeks, and only then suddenly went a little bonkers. It's really annoying because I am rubbish at coding without intellisense!
Has anybody ever seen anything like this or have any suggestions?
I had this. I referenced assemblies whose "Target Framework" were set to ".Net Framework 4" in the "Application" secion of the projects properties. I changed this to ".Net Framework 4.5" not just in the referenced assembly's project but also the project I was building and it worked. Give this a try.
I have found this is a known problem with VS2012. Check to see how you are building, 64 bit or 32 bit. It won't work with 64 bit but it will with 32 bit. It will say things are missing and design will not work, however the program will run fine. I have heard the new VS update that hasn't been released yet will fix it.
Manually delete all the references to the libraries of the other projects and re-add. Intellisense rebuilds whatever it needs at that point and doing this has helped me in the past.
Another source of this problem is a solution with multiple projects containing code for the same namespace. The compiler can handle this. Intellisense won’t.
Related to a couple other answers here, I had a "Data" project using a "Data" namespace. Built fine, but just started recently showing errors from intellisense (even though it continued building fine.) (VS 2015.)
I fixed this by changing my "Data" project and namespace to "MyCompany.Data".
Oddly, the problem didn't seem to show up until recently, but making the change did fix it. Presumably there was a conflict in namespace with another project or reference, which can build fine, but intellisense can't handle.
You can change this in the Application tab of Project properties. You can also open up an EDMX diagram, right click, choose model browser, choose the second collapsable item in the model browser tab, hit properties, and there you'll find the Namespace option for generated Entity Framework entities and contexts. (Similiarly, if you modify an Entity Framework Model's namespace, you might also need to change the related connection to match [in Web.Config for ASP.Net and MVC.])
Make sure that there is no class with the name same as Project default namespace.
make sure that you don't reference .net framework 4.5 projects in .net 4 projects!
Examine your .proj files in a text editor and make sure the paths to your references are correct.
This can also happen if you set the Build Action to "None" on the referenced file and forget about it.
I had the same problem, where it would build and run fine, it just would always show that error and I couldn't use intellisense with the class.
I actually used the automatic method of creating the class in a new file to resolve the issue, then just copied the code over from the real class. I deleted the old file, renamed the new file, and now it works.
I have a small WPF application which used to compile just fine but is not anymore. I can't really say at which point it stopped building. It just worked fine one day, and the next it's not.
Here's the project structure:
There is no other projects or external references other than standard .net dlls.
Here's the user control where the problem originated:
<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}">
And here's the error I get:
Please note that this is not just the one file in the screenshot, but all references I add in similar fashion in xaml in all user control/window files in this project.
So the file is there, the namespace in the file is correct, the namespace/class name in the xaml file is (to my understanding) correct. I get intellisense when I type in the xaml so it finds the files ok then but not when it compiles.
The most common solution for this in other posts has been the .net framework version. It is currently set to .Net Framework 4 for both my main and test project. The full version not the client profile.
Here's what I think I messed up:
In the configuration manager, both projects have their Platform set to Any CPU, but at one point when trying to solve this I noticed that the main project was set to x86 and the test project was set to Any CPU. So I added Any CPU manually for the main project in the configuration manager. However I honestly don't know if I did this correctly or even if I should do it. So as an additional question, is there a way I can reset the configuration manager to its default state? Will this have anything to say for the main problem? I don't know if the main project was always set to x86 or not or if I somehow changed it to x86 and then it broke. As mentioned this project was compiling just fine for a while.
Every time it happend to me i just restarted visual studio, re-built the solution and it worked just fine.. can't say why
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.
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.
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
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.
What worked for me:
- Switch solution configuration from Debug to Release
- Switch back configuration from Release to Debug
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.
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 ...
Remove offending code from xaml file (just 3 lines in my case)
Build project so you get a successful build
At this point the layout magically appeared in the designer window which was a good sign!
Reinserted the code I removed in point 1. including the xmlns: entry
At this point you shouldn't get any blue squiggles ... hopefully
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.
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.
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
I Changed Target Framework My Application of ".Net Framework 4.5" to ".Net Framework 4.6" and it worked!
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 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:
Build-->Configuration Manager--> Active Solution Platform --> Changed to x64 and x86 and Any CPU.
Closed the VS and opened again.
Change
xmlns:VM="clr-namespace:MyFirstAppViewModel"
to
xmlns:VM="clr-namespace:MyFirstAppViewModel;assembly=ViewModel"
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.
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.
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
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.
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.
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)
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 :)
The Target Framework of the .dll file you adding should be the same as the Target Framework of your app.
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.
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.
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:
Clean the whole solution
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.
Unload the project with the errors and reload it. Then close and open the sln again if the errors persist.