I'm trying to use a 3rd party component in my Silverlight application and when I try to create an instance of the control, I get a XamlParseException:
{System.Windows.Markup.XamlParseException: **Set property 'System.Windows.FrameworkElement.Style' threw an exception.** [Line: 0 Position: 0]
---> System.Windows.Markup.XamlParseException: **Elements in the same ResourceDictionary cannot have the same x:Key** [Line: 1739 Position: 47]
at MS.Internal.XcpImports.CreateFromXaml(UnmanagedMemoryStream stream, String sourceAssemblyName, boolean createNamescope, Boolean requireDefaultNamespace, Boolean allowEventHandlers)
at System.Windows.Controls.Control.GetBuiltInStyle(IntPtr nativeTarget, IntPtr& nativeStyle)
--- End of inner exception stack trace ---
at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
at SpellCheckerSample.StandardSpellDialog.InitializeComponent()
at SpellCheckerSample.StandardSpellDialog..ctor()}
How can I debug this? How do I know what file line 1739, Position 47 is in?
Could be a bit of a bugger to find. Basically try to gather as many details as possible from the debugger.
Set the debugger to break on XamlParseException.
Have a look at the callstack. It could be possible that the offending control's constructor is on the callstack.
When paused go to the Locals debug window to see if any parameters to the function reveal more about which component this is.
If not double-click the next stack entry down and go to step 3.
Repeat steps 3 and 4.
After I wrote this I realised that the control's constructor is indeed on the callstack and it is SpellCheckerSample. Very likely it is .XAML page for that control. If you can get access to the source, the file name is most likely something like SpellCheckerSample.xaml.
The error itself is pretty straight forward, looks like there multiple things defined with the same key in the same ResourceDictionary. The below code will cause this to happen:
<Window.Resources>
<myConverters:BananaToCarrotConverter x:Key="StupidestConverterEver" />
<myConverters:BananaToAppleConverter x:Key="StupidestConverterEver" />
<Window.Resources>
Turns out my specific problem was that the ComponentOne component only works under Silverlight 4. Once I changed to target SL4 it all worked.
Check what ResourceDictionary references you got - the propblem is usually that one one of them got an error that needs to be fixed.
If your exception is cause from App it's probably one of your merged dirs there, otherwise the control in question.
Also check that you're not missing resource dir usage for styles (helps if you got ReSharper since you'll get a warning in XAML design time).
Set the debugger to break on XamlParseException (Debug -> Exceptions -> Common Language Runtime Exceptins -> System.Windows.Markup -> XamlParseException line -> set tick in Thrown column)
Take a look at the exception in debugger (especially on InnerException and LineNumber properties)
Try to go through the callstack line by line. While selecting a line look at the Locals window. It reveals some variables even in Framework code that is might be helpful.
Try to delete some part of XAML and see if exception happens again. This will help you to locate code that cause problems.
You should see an error in .cs file while trying to run the app.
And the corresponding .xaml file for this .cs file with given line number and column is the right one.
Related
I am working on a wpf-project that used a ScrollViewer to show a range of items.
In order to create a more advanced look and feel for the application, I replaced the Scrollviewer with a Carousel-control.
The code for the Carousel-control I downloaded from here:
https://www.codeproject.com/Articles/181835/WPF-Carousel-Control
Conceptually, the carousel control (as part of my wider application) consists of a large black box (which one does not need to touch) plus just a few lines of code for plugging in the carousel control. The black box is the Carousel project, highlighted in the following screenshot:
In order to plug the carousel-control in the application, just a couple of lines had to be commented out and a couple of other lines had to be added. The comments in the following two screenshots mark off the lines of code that had to be commented out and the lines of code that had to be added (in order for the scrollviewer-control to be replaced by the carousel-control):
... and (at the end of the file):
Furthermore, at the beginning of the xaml-file that contains the carousel, the following line was included:
xmlns:Carousel="clr-namespace:Carousel;assembly=Carousel"
as can be seen in the following screenshot:
As you can see, at the moment, the code for the scrollviewer is commented out. Hence, the application is using the Carousel at the moment.
This carousel works fine. However, the error list shows a bunch of errors, mostly of the following type:
the name "XYZ" does not exist in the namespace "bla".
The following screenshot shows some of the error messages:
As already mentioned, the carousel-control works despite those error messages. However, I still need to get rid of the error messages before leaving this project.
Regarding the error messages, the following points might be of interest:
No error messages are shown, when the scrollviewer-control is used.
As you can see from screenshot 5, most error messages refer to line 1 of the file CarouselControl.xaml. This file is located inside the "black box":
The beginning of file CarouselControl.xaml contains the following lines of code:
As you can see from screenshot 5, most of the error messages say that some name or property does not exist in namespace xyz, whereby namespace xyz is one of the namespaces listed at the beginning of file CarouselControl.xaml (see screenshot 7).
********************************UPDATE*****************************************
(Right-click on) Solution -> Properties -> Configuration Properties, I noticed that it was apparently not possible to change the configuration of the Carousel-project to anything other than platform x86:
No matter which platform I selected (from the drop down menu at the top of the screenshot), the platform for the Carousel-project stubbornly remained at value "x86".
Might this have something to do with the error messages?
I'm not sure how useful this may be, but I believe I have found the code that was the source of my problem:
var variables = values[0] as ObservableCollection<variable>;
var identifier = values[1] as string;
var variable = variables.SingleOrDefault(x => x.identifier == identifier);
if (variable == null) return "";
This is code of my converter to access a variable in a collection and return its value as a string, it was used on a TextBox control.
Looking back over my branches, it seems that I made this change:
var variable = variables?.SingleOrDefault(x => x.identifier == identifier);
Resharper suggested adding a Null-conditional Operator at this point, which solved my issue. It would seem that the designer was returning errors due to the LINQ expression, since the collection at this point was uninitialized.
I would look through your code to see if you have a similar instance of uninitialized collections.
I have declared an event in "Question" class as:
public event SectionAffected OnSectionAffected;
I have not used this event in the entire class.But I have used it in another class as:
Question.OnSectionAffected += new Question.SectionAffected(ResetDependentSection);
I am getting warning as:
The event 'QuestionManager.OnSectionAffected' is never used in Question class.
How to solve this warning?
A warning is just that... a warning. Having warnings is not necessarily a bad thing. However, if you really want to remove it, you can specify that in Visual Studio. If you open the relevant project's property page (by pressing ALT + Enter when the project is focused), turn to the Build tab. Click the RadioButton named Specific warnings and enter the specific error code(s) that you want to supress in a comma separated list. You can find out more from the How to: Suppress Compiler Warnings page on MSDN.
UPDATE >>>
I believe that you are looking for the numerical error code number... for this, you should look in the Output Window of Visual Studio. If you don't already use this window when writing WPF, then I would strongly advise you to do so. However, these codes are not always shown in this window.
As an alternative, you can find descriptions and error codes in the C# Compiler Errors and Code Analysis for Managed Code Warnings pages on MSDN.
UPDATE 2 >>>
After doing a quick search online (which is really what you should have done), I found this page which seems about right: Compiler Warning (level 3) CS0219
I have implemented a converter to convert Int32 to String to be able to binding a property to a textBox.
I implement this converter in the namespace MyApp.Converters and it is called Int32ToStringConverter.
Then, in my axml I add the reference to my converter as follow:
<Window x:Class="MusicaDB.Views.PrincipalView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:i="namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
**xmlns:converter="clr-namesapce:MyApp.Converters, aseembly=MyApp**">
Later, in windows.Resources I have:
<Window.Resources>
<**converter:Int32ToStringConverter** x:Key="Int32ToStringConverter" />
</Window.Resources>
I get the error that the tag Int32ToString converter does not exist in the namespace MyApp.Converters,assembly=MyApp.
I have the project in the local hard drive, in the project properties, the destination .NET is framework 4.0, not framework 4.0 client profile and I try to clear the solution and recompile but the problem persists.
Mainly, this is the two solutions that I always find, but don't resolve my problem.
Three fixes to make here:
No spaces -> xmlns:converter="clr-namesapce:MyApp.Converters,aseembly=MyApp"
No misspellings -> xmlns:converter="clr-namespace:MyApp.Converters,assembly=MyApp"
Right delimiters -> xmlns:converter="clr-namespace:MyApp.Converters;assembly=MyApp"
From the the documentation:
Note that the character separating the clr-namespace token from its value is a colon (:) whereas the character separating the assembly token from its value is an equals sign (=). The character to use between these two tokens is a semicolon. Also, do not include any whitespace anywhere in the declaration.
Another possible solution to this problem is that you're not using the same version of .Net in your project and your library.
I am exploring as to why this is happening, but if your converter is in the main assembly, removing the assembly= from your xmlns:converters tag should remove that build error.
For the record ...
I've face a similar problem and if I removed the ";assembly=X" part from the XAML it worked fine
But don't really understand the reason.
As suggested in this blog:
http://zoomicon.wordpress.com/2012/07/02/fix-the-tag-xxx-does-not-exist-in-xml-namespace-clr-namespaceyyy/#comment-7761
I see two possible causes. The first is that you misspelled "assembly" as "aseembly" in the first starred line. Changing the spelling might be enough. The second possibility is that you haven't added MyApp.dll to your project references, which appear like this
in Visual Studio.
All answers are right. And after trying all of them and you cannot configure why its happening, everything seems alright, Please restart the Visual studio.
That worked for me after wasting almost 1 hour. I found everything ok, but restarted the VS with administration.
use the assemble tag only if it is in another project.
other wise use just namespace tag alone.
For me this fixed the issue
In my situation, I had the same problem with xmlns:local="clr-namespace:<mydefaultnamespace>".
I solved this changing the order of the includes. I put it first and all was solved.
A strange behaviour, but this was my workaround that I found in my situation.
In my case, the assembly which contained the namespace was not physically there.
I checked the references of the assembly that had the build error and looked at the properties of the referenced assembly in question.
I navigated to the path and discovered the assembly was indeed missing (which I realised was my own doing), giving rise to the misleading error.
There is one very obscure case when you get this error - if you're using Microsoft.mshtml.dll and you upgrade to Windows 10 anniversary edition, or as it turns out the Creator edition too.
Even if this isn't what happens to you make sure the library containing the component that cannot be found can be fully compiled. Look in the error list (not the grid but the Output console) for any clues.
In my case I was using Microsoft.mshtml.dll as part of an HTML editor and it was unregistered somehow (in the GAC).
The following article explains with screenshots:
https://techninotes.blogspot.com/2016/08/fixing-cannot-find-wrapper-assembly-for.html#comment-form
In short I had to run a Visual Studio command prompt (as admin) run these commands:
cd C:\Windows\assembly\GAC\Microsoft.mshtml\7.0.3300.0__b03f5f7f11d50a3a
regasm Microsoft.mshtml.dll
I did say obscure :-) The important point is to read the errors that may be buried amongst all your warnings because there might be an important clue.
This can be especially confusing if an Operating system update suddenly breaks your project.
I was temporarily replacing a NuGet dll with a local one when this happened. Turned out the assembly was not the same version as the one I was replacing. I built my assembly with the correct version and it worked.
I have made a wpf standalone application for accounting purposes. The application works and prints well to an external printer or microsoft XPS printer. The problem arises when i select doPDF(an application which outputs a pdf file) as printer. The output is just fine; it creates the pdf file and saves it, but, when i come back to the application and press any button, an XamlParseException was unhandled error is thrown which says
'The invocation of the constructor on type 'RegisterMaintenance.DisplayInvoice' that matches the specified binding constraints threw an exception.' Line number '5' and line position '7'
InnerException: Verify that the file exists in the specified location
InnerException: When using relative paths, make sure the current directory is correct
Why is this happening and what can i do to get rid of this problem.
Seems that this pdf printer changes the current directory for the process.
I can think of 2 possible workarounds for your problem.
The first and most obvious workaround for your problem would be to use a absolute path for "Transactions.xml" and store this in your app.config. This might however become problematic if your application is ditributed to various different machines and installed in different locations.
The second workaround is to temporarily store your current working directory before calling the print function, and then restore it afterwards, if it has changed. Something like this:
string path = Directory.GetCurrentDirectory();
//Do the print stuff
Directory.SetCurrentDirectory(path);
Seems like most probable cause is that some resource is not found or already occupied. Please share your code for Line number '5' and line position '7' with us.
You can use your debugger and set a breakpoint on line number 5 where the constructor for RegisteMaintenance.DisplayInvoice is called. Look at the file path being used and fix the problem. Alternately, if you're highly confident it's not a problem you can try/catch and ignore the exception but I don't really recommend that.
I am mucking about with WPF glyphs and documents and have run into a null reference exception in the .Net 4 framework.
I extract and save true-type fonts to disk as .ttf files, then try to create Glyphs based on the fonts. The first time I save a font to disk and instantiate a GlyphTypeface based on the font after creating a GlyphTypeface from another font in the same folder I get a null reference exception.
Say I have fonts A and B. B has not been saved to disk (A may or may not have been saved to disk; that doesn't seem to matter):
1) save B to disk in the same folder as A,
2) create GlyphTypeface using font A,
3) create GlyphTypeface using font B = exception.
Null reference exception at:
at MS.Internal.FontCache.FontFaceLayoutInfo.IntMap.TryGetValue(Int32 key, UInt16& value)
at MS.Internal.FontCache.FontFaceLayoutInfo..ctor(Font font)
at System.Windows.Media.GlyphTypeface.Initialize(Uri typefaceSource, StyleSimulations styleSimulations)
at System.Windows.Media.GlyphTypeface..ctor(Uri typefaceSource)
If I restart my app and run it again (with font B already on disk), step 3 doesn't throw an exception.
The code to save a font to disk is simply writing a section from a binary stream and letting go of the file:
if (!File.Exists(filename))
{
using (FileStream fs = File.Create(filename, length))
{
fs.Write(m_data, m_index, length);
fs.Close();
}
}
Any ideas? I don't want to have to put every font in its own folder...
Thanks for your time.
This bug has been driving me nuts but I think I have a better understanding of what is going on now.
For testing I used the following XAML:
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Glyphs
FontUri="C:\Users\Public\Desktop\A.ttf"
FontRenderingEmSize="100"
Fill="Black"
UnicodeString="Test"/>
</Page>
Using the XamlPadX application which runs on the .NET 2 runtime I could reliably render the XAML no matter where I placed the font.
Using the Kaxaml application which runs on the .NET 4 runtime the XAML would often fail to render depending on where I placed the font in the file system. By moving the font file around and renaming I tried to discover a pattern in what was allowed. However, it was very hard to see a pattern.
For instance storing the font in the path below would render the glyphs:
C:\Users\Public\Desktop\A.ttf - OK
Renaming it from A.ttf to B.ttf would throw the exception:
C:\Users\Public\Desktop\B.ttf - throws exception
Changing the extension would also throw the exception:
C:\Users\Public\Desktop\A.odttf - throws exception
Renaming parts of the path would sometimes wreak havoc but I was unable to see any pattern. Initially I used the temp path and getting exceptions lead me to this question and the answer about not using that path. However, later I have actually been able to use that path as long as the name of the file is A.ttf and not B.ttf so avoiding the temp path is not a sure fix.
At some point during my tests using my own WPF application the B.ttf file name suddenly started working. However, I had to restart the Kaxaml application before it would accept the B.ttf file name. Also, at that point the A.odttf file name was still throwing exceptions.
My suggestion is to use an application like Kaxaml or to create a small WPF application to test which font file names are acceptable and then use them. However, I fear that the nature of this bug is such that a "good" font file name may turn "bad" at a later point in time. Only time will show.
I ended up using the workaround of saving each font to its own folder (using the font name for the folder name). The exception went away, so I guess we can chalk this up to a bug in .Net.
I (and a co-worker) finally found what our particular problem was: do not save the font files to %TEMP%. For some reason, having the fonts saved to some other folder makes it work (for us), and saving it to anywhere inside %TEMP% makes it break.
According to XamlToys Doesn't work on framework 4.0???, the problem is in the extension of the file for partial fonts.
When I renamed the .ofttf files I save to .ttf, it all works again. Haven't got the foggiest idea of why that is though. Seems to be new in .NET 4.0.
My workaround was to simply replace the < Glyphs > with equavalent < TextBlock >s. The couple of pixels difference in layout was not a problem in my case.
Like you noted was the case for you, in my case also it was not a problem in .Net 3.5, but appeared in .Net 4.0.