I've got this error that I just can't figure out.
I'm using VS 2012 (VS11) on Windows 8 with .net4.5 and I get this error when compiling a project that worked with VS 2010 and .net4.0.
This is the full error:
The type System.Windows.Input.ICommand exists in both 'c:\Program
Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\PresentationCore.dll'
and 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.dll'
If anybody could provide some insight on what is causing it and/or how to fix it I'd be grateful.
Thanks.
c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.dll
The message is accurate, ICommand indeed exists in both assemblies for .NET 4.5. The problem is your reference to System.dll, your project is using the wrong one. The assemblies in the Microsoft.NET directory are no longer suitable to act as reference assemblies, like they were in versions of .NET prior to .NET 4.0. They should no longer be there but unfortunately are required to get C++/CLI projects built.
Your reference to PresentationCore.dll is correct, it uses the c:\program files\reference assembly subdirectory. The proper home for reference assemblies in .NET 4.0 and up. These assemblies are special, they contain only metadata and are not a copy of the runtime assemblies.
You'll need to fix your project. System.dll is probably not the only assembly that has this problem. Open the References node of your project and verify them one by one. Remove bad ones that point to Microsoft.NET and replace them with good ones by using Project + Add Reference. Best to just replace them all to be sure.
I had a similar problem with fxcopcmd V12.
I was able to solve it by explicitly adding
/reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\WindowsBase.dll"
See: FxCop engine exception on WPF assembly
Take a look at this similar post, How can I resolve this? The unit type exists in two dll files, it suggests that you are referencing two assemblies with the same type, so you would need to give the type you want to use the fully quantified name.
We had the same problem with our libraries after moving to a new build server.
The solution was to specify the path of the .net framework to build against:
/p:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
If the .net 4.0 framework (Multi-Targeting Pack) is not installed on the build server (as it was with us), you can just copy the "v4.0" folder with all its assemblies to the build server ;)
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?
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.
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"
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.
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:
Right-Click on the solution in the Solution Explorer and Choose "Clean Solution"
Shutdown Visual Studio
Delete the ShadowCache folder
Reopened the Visual Studio project
Rebuild the solution
And voila no more namespace errors.
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.
Maybe another solution for when the project compiles but the XAML error is showing :
In solution explore, on the project node that contains the xaml
Right-click on the project and choose 'Unload Project'
Right-click on the project and choose 'Reload Project'
Make sure that your project is still choosen as "startup project". If not :
Right-click on the project and choose 'Set as startup project'
No need to rebuild, or close visual studio.
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.
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.
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.
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:
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
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.
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.
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:
Checking all check boxes on Build Column of the page: Solution -> Properties -> Configuration Properties
Changing the solution configurations from Debug to Release or vice versa.
I think it's a bug in Visual Studio2012 Update 2.
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.
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
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.
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.
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.
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:
Right click on the DLL file in Windows Explorer and select Properties.
At the bottom of the General tab click the "Unblock" button or checkbox.
Note: Only unblock DLLs if you are sure they are safe.
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.
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
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).
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.
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.
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
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
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".
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.
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.
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.
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.
Recently, I've started to encounter exceptions in the Visual Studio 2010 WPF designer seemingly due to log4net. If I freshly build my project, the XAML file will appear correctly in the designer. Then, once I start to click on controls to jump within the XAML, this exception quickly gets thrown:
System.Reflection.Adds.UnresolvedAssemblyException
Type universe cannot resolve assembly: log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821.
at System.Reflection.Adds.AssemblyProxy.GetResolvedAssembly()
at System.Reflection.Adds.AssemblyProxy.GetHashCode()
continues...
The problem only goes away when I remove the log4net reference. This is now the second project to exhibit this behavior. Has anyone else seen this and/or found a fix?
Note: I'm using .NET 4 Full (not Client Profile) and I've toggled Specific Version on the log4net reference T/F to no avail.
I managed to resolve the issue after:
Finding this blog where the author resolved a similar situation by placing the unresolved assembly in the Public Assemblies folder (found using k3b's fuslogvw tool)
Encountering a FileLoadException which led me to this SO post.
Downloading a fresh copy of log4net, unblocking the zip file, and replacing the reference in VS and the Public Assemblies folder.
But, I'm still not sure why I had to place this particular assembly in the Public Assemblies folder. All the other assemblies I reference don't require this step.
You can use the "Assembly Binding Log Viewer" (Fuslogvw.exe) that belongs to the dotnet sdk to find out which dll is loaded when and why . If logging is enabled it can show you wich assemblies are loaded and which assembly caused it to load.
For details see http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.80).aspx
Sometimes the dll is there but in the wrong version.
if you include universe.dll into your project you must also include log4net.dll with local copy=true
Add the path to your assembly "log4net" in the Project Properties/Reference Paths.
http://msdn.microsoft.com/en-us/library/6taasyc6(v=VS.100).aspx
Turns out when we had this problem, it was due to the paths we used to add the references.
We are using some custom ".targets" files which define the references. There are lots of mixed dependencies with the projects, and using the .targets files helps to keep the references defined in one place.
Well, the references HintPath ended up something like...
<HintPath>C:\Program Files (x86)\\Custom\CustomControlsWPF2.2011\Source\\..\Binaries\WPF\Custom.Windows.Controls.dll</HintPath>
When we removed the double blackslash, replacing with single "\", the "Visual Studio 2010 UnresolvedAssemblyException: Type universe cannot resolve assembly" error went away.
This is how is should have been.
<HintPath>C:\Program Files (x86)\Custom\CustomControlsWPF2.2011\Source\..\Binaries\WPF\Custom.Windows.Controls.dll</HintPath>
Ensure that your code runs at design time, as well as run time. If your code runs at design time, do not assume that Application.Current is your application. For example, when you are using Expression Blend, Current is Expression Blend. Typical operations that cause a custom control to fail at design time include the following.
-Casting Current to your custom subclass of Application.
-Using the FindName method on Current.
-Not checking whether Application.Current has returned a value that is null. If Visual Studio does not create an application object, then Application.Current may return null.
http://msdn.microsoft.com/en-us/library/ff356886%28v=vs.95%29.aspx
give a try to this. add it at the beginig of your functions:
// Check for design mode.
if ((bool)(System.ComponentModel.DesignerProperties.IsInDesignModeProperty.GetMetadata(typeof(DependencyObject)).DefaultValue))
{
return;
}
Sketchflow newbie (couple days), WPF newbie (few weeks).
Workspace details:
WinXP, Visual Studio 2010 Ultimate, Expression Studio Ultimate (using Expression Blend 4 with SketchFlow). Downloaded the Sketchables 0.9 release and built a release version (Debug version is already built).
Issue details:
Start up Expression Blend 4, create a WPF Sketchflow project. Build it (successful). Add references to either the release or debug versions of the Sketchables library (in the Desktop, rather than the SL folder) and try to build again. The build fails with error:
Unknown build error, 'Could not load file or assembly 'System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXX' or ore of its dependencies. The local assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'
Now, I've seen some issues with a similar error, specifically a couple of issues where the problem was caused by trying to load a Silverlight control in a WPF project. However, I'm not knowledgeable enough to know if it's related. On a hunch, I tried a Silverlight project. Sure enough, building a Silverlight Sketchflow project and adding the Sketchables library builds cleanly.
So, the question is this: Does anyone have any ideas about what's actually causing this error within the Sketchables source, on pointers on how to track it down so I can work on it and get a clean library build for WPF?
Chuck's right. The Sketchables.Common dll is a Silverlight class library. Easy way to fix is to create a Sketchables.Common.WPF project and make it a regular class library. Copy over the classes from the SL library project, compile, and then change the reference in Sketchables.WPF to point to Sketchables.Common.WPF instead of Sketchables.Common. Your Blend project should now build.
A more advanced way is to share both Common projects to same files, but I won't go into that here. Search for share (link) files between projects and you'll find answers for that.
You have identified the cause of the problem, the assembly you are trying to reference in your WPF project was compiled for Silverlight (the 2.0.5.0 version number is a giveaway that it is Siverlight).
You might want to check with the author of the controls to see if there is a way to compile it for WPF.
I built a WPF application in VS.NET 2008 using ClickOnce deployment. It ran great on any machine that had VS.NET installed, but my business users received an error: "Unable to install or run the application. The application requires that assembly Microsoft.Windows.Design.Extensibility Version 3.5.0.0 be installed in the Global Assembly Cache (GAC) first."
I was surprised to discover that this dll is not part of the standard .NET 3.5 SP1 client installation, but somehow, my application thought it was needed. I checked my Publish tab for the project and it showed up as a prerequisite.
Oddly enough, I was able to just remove this (and all of the other Microsoft.Windows.Design.* dlls) and it just worked everywhere. I removed them from my project entirely, and everything was fine.
Can someone explain why the VS.NET 2008 project wizard forced these to be included in the project, and more importantly, why ClickOnce thought they needed to be on the client machine to run?
This is just a curiosity question, but I'm sure I'm not the first to be bitten by it. Hopefully, this post will at least save someone else the headache.
Try to remove all references to *.Design.dll. In my case it was WPFToolkit.Design.dll.
This is old and the OP is gone, but I ran into this today, so I thought I'd mention that my solution was removing a reference to one of the WPFToolkit references that ends with .Design.
I had referenced System.Windows.Controls.Input.Toolkit, but also had a reference to System.Windows.Controls.Input.Toolkit.Design, which should not have been there. Removed it, and all was right with the world again.
A way to find out the code that is loading the assembly is explained here:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/755272f6-0e79-4a6d-ae50-4412d0f2bc4c
I found that I was using the SelectionCommands.Clear property which is inside the Microsoft.Windows.Design.Interaction namespace inside the Microsoft.Windows.Design.Extensibility Version dll.
Beats be why this dll isn't included in the .NET 3.5 install.