I've seen some people that have managed to use the themes in the Silverlight 2.0 Toolkit in Windows WPF applications. In fact, it looks like it's pretty easy...for them. I've run into an odd issue early on in my attempts.
Here is all it take to fail:
Create a new WPF Application project in VS2008 sp1
Add a reference to System.Windows.Controls.Theming.Toolkit
Rebuild all
System.Windows.Controls.Theming.Toolkit is loaded from:
C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Toolkit\March 2009\Libraries
I get the following error:
c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets(294,9): error MC1000: Unknown build error, 'The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'
I understand the general meaning of the error, but I don't know what to do about it since it doesn't specify the version it wants and since it must be referenced from the newly added Assembly I don't know how to change that.
Turns out this doesn't matter anymore. When I was doing this the WPF Toolkit didn't include Microsoft's themes. Now it does, and using those solves the problem.
Related
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 ;)
I'm having an issue with the WPF Designer. At some point I did something that broke all of my controls that reference the local assembly. The application builds and runs just fine, but the VS Designer throws errors every time that a local resource is referenced via a clr-namespace.
For instance, I have the following reference:
xmlns:Converters="clr-namespace:MyAssembly.Converters;assembly="
Note that I left off the assembly=MyAssembly because its the local/current.
Then when I reference it in a resources block:
<Converters:IsNotNullConverter x:Key="isNotNull"/>
This was all working up until today. At some point I did something which broke all of the references with the following error:
Undefined CLR Namespace. The 'clr-namespace' URI refers to a namespace 'MyAssembly.Converters' that is not included in the assembly.
I've tried cleaning, rebuilding, restarting VS, closing the designer panes, and all combinations of these 4. It's most likely some other minor issue that is causing the whole thing to blow up (as happens too often in WPF). My problem is that I have no idea how to begin to break this problem down.
Does anyone have any insights or techniques for finding the real issue with this design-time problem? Right now I'm basically going file by file and hoping I can find the needle in the haystack.
Thanks!
"I just solved this by changing the target from x64 to x86. Apparently Visual Studio is 32bit process and it's unable to load 64bit assemblies, and if your assembly is targeting x64 platform and you adding some custom control visual studio is unable to load it and throws this message. "
From: The 'clr-namespace' URI refers to a namespace that is not included in the assembly
I had it set to x64 because of a 3rd party DLL requirement...gonna be tricky. Oh well. Thanks!
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;
}
From the project "MarkdownEditorTest" I am trying to refer to controls from another project called "MarkdownEditor" but am getting the "Undefined CLR namespace" error as seen in the image below.
Isn't the way to refer to that project something like below?
xmlns:me="clr-namespace:MarkdownEditor"
Note that each project (C#, VB, etc.) creates its own assembly.
If it's in another assembly, you need to specify the assembly name:
xmlns:me="clr-namespace:MarkdownEditor;assembly=MarkdownEditor"
Note that generally each project in a solution creates a distinct assembly. And note that a project's name can be different than the assembly name. You can see the assembly name in the project's properties (in the application tab).
Also, be aware that a project's name can be different than the assembly name. You can see the assembly name in the project's properties (in the application tab).
I know that this may be a silly question, but have you included a reference to the other project in your visual studio project ?
I had the Same problem that occurred though I have added assembly. It's due to .net framework mismatch. So make sure your framework version of the assembly is equal or lower to the current project.
I hope this answer will help someone else.
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.