I'm getting an odd invalid cast exception, which I suspect is due to mismatched namespaces, but I'm not sure where.
The exception message is:
Additional information: Unable to cast object of type 'FishTracker.FishTracker' to type 'FishTracker.Application'.
Now this has come about because I decided to rebuild an application from the ground up having spotted a crucial flaw. It's a wpf app.
The main xaml reads like this:
<Application x:Class="FishTracker"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:FishTracker"
StartupUri="Views\MainRibbonView.xaml">
<Application.Resources>
</Application.Resources>
In the vb file behind that is defined thus:
Public Partial Class FishTracker
Inherits Windows.Application
and in the application settings the Assembley name is FishTracker and the RootNamespace is FishTracker.
As far as I can see everything matches, it builds yet fails when it runs with the invalidcast exception thrown from MyWpfExtension.vb (and I can't even see that in the solution) .
Any ideas most welcome.
Related
I have an issue that is driving me nuts. When I try to build my VB.NET + WPF project in Visual Studio, I get an error "Type 'MyProject.MyUC' is not defined". This error appeared after I made some changes to other files from this solution (completely unrelated to that UC, it's backend code, or the window that uses that UC. Entirely separate code). I am using GIT, and I'm comparing old branch with a new branch, so I know this for a fact.
The window that uses the control is defined like this:
<Window x:Class="MyWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:uc="clr-namespace:MyProject"
xmlns:xctk="http://schemas.xceed.com/wpf/xaml/toolkit"
mc:Ignorable="d"
Title="MyWindow" Height="350" Width="650">
<Grid>
<uc:MyUC x:Name="MyUC"></uc:MyUC>
</Grid>
</Window>
The UC is defined like this:
<UserControl x:Class="MyUC"
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:FLOATSOFT"
mc:Ignorable="d"
d:DesignHeight="450" d:DesignWidth="600">
<Grid>
</Grid>
</UserControl>
And it's backed VB code:
Public Class MyUC
End Class
(No specific namespace declarations)
I have removed all functional code to show the structure. But even if I actually trim down my code to what I quoted, it doesn't compile.
I don't get it. MyUC is definitely in the MyProject namespace. If I hover my mouse over the class name in VB code, the tooltip says: "Class MyProject.MyUC", confirming it is definitely in the right namespace.
Why could this be happening? I still have all this that I quoted here in another GIT branch, and even though all these files match 100%, that other branch compiles, while this one gives this dreaded "Type 'MyProject.MyUC' is not defined" error.
I have tried:
Restarting Visual Studio - this used to help with such errors befoe;
Cleaning and rebuilding;
Re-creating all these files (MyWindow.XAML, MyWindow.XAML.VB, MyUC.XAML and MyUC.XAML.VB) and copying code to these new files;
Making sure my code builds if I comment out the usage of this UC and that there are no other compile errors.
Explicitly stating the namespace in the MyUC.XAML:
<UserControl x:Class="MyProject.MyUC"
And in MyUC.XAML.VB:
Namespace MyProject
Public Class MyUC
End Class
End Namespace
Doesn't help either. Same error.
Creating a new project and copying over these 4 files. It compiles. But it would be ridiculous having to re-create the project every time this happens. Like I said, it happens often, but restarting Visual Studio used to help. Not this time.
And I am at complete loss. I have reviewed dozens of similar posts to this one, but haven't found the answer. One answer suggested that this might be due to different .NET versions of the project and referenced assemblies, but I don't have any of that.
One branch compiles, another one throws this error. Both have identical code in every file that could possibly be related to this UC. How do I find the cause?
EDIT: I forgot to mention that I also tried creating a new UC from scratch in this project branch, and if I try to use it like this MyUC, this project branch won't compile. But the other branch still compiles.
EDIT: VERY IMPORTANT: I just discovered that if I change
<Grid>
<uc:MyUC x:Name="MyUC"></uc:MyUC>
</Grid>
To
<Grid>
<uc:MyUC></uc:MyUC>
</Grid>
(Omitting x:Name="MyUC"), then suddenly code compiles and I get no error. If I set a name to this UC - any name whatsoever - it won't compile. I have absolutely no idea what is happening.
I finally figured it out. Turns out, this issue is identical to this one. In short, I was right - nothing was changed in these 4 files, and they should have compiled. However, in a completely separate file, I incorrectly defined a namespace for one of the modules. I should have written:
Namespace MyModule
Public Module MyModule
End Class
End Namespace
But instead, I wrote:
Namespace MyProject.MyModule
Public Module MyModule
End Class
End Namespace
And although this MyModule is absolutely unrelated to the MyUC or MyWindow, apparently it created a namespace MyProject.MyProject, and that is why MyWindow wouldn't compile, as it tried to search for MyUC in MyProject.MyProject, presumably. Which is very weird, because the error I got did not suggest this. In fact, nothing anywhere ever suggested that I have this kind of namespace. Like I wrote in my question, everywhere I debugged, I found that MyUC has is declared directly in MyProject.MyUC. And every other window had the same declaration, yet they compiled.
I must admit that the error thrown by VS compiler was extremely unintuitive and the information it provided on namespaces was completely wrong for that UC, and I discovered the solution simply by accident. Even the Object Viewer showed that there is no issue with namespaces (it didn't show that I have MyProject.MyProject).
Hope this helps if anyone encounters the same issue. And I would also love to hear any suggestions on how to make these compiler errors more straightforward to the actual issue, because in this instance it was just plain wrong.
I've been working with the DevExpress MVVM assembly (.Net Core).
I created a version of the assembly that uses AvaloniaUI in place of WPF.
I'm including this assembly in my client project and am having difficulty with name space resolution in a XAML definition. I' using the above mentioned MVVM assembly (using AvaloniaUI) in place of the default version.
Consider the following XAML definition:
<Window x:Class="Moonshot_Foundry_Core.Views.MainWindowView"
xmlns="https://github.com/avaloniaui"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:dxmvvm="http://schemas.devexpress.com/winfx/2008/xaml/mvvm"
xmlns:views="clr-namespace:Sample.Views"
xmlns:productionViewModels="clr-namespace:Sample.ViewModels.Production"
xmlns:designViewModels="clr-namespace:Sample.ViewModels.Designer"
WindowStartupLocation="CenterScreen"
mc:Ignorable="d" Title="Sample" Height="720" Width="1280"
DataContext="{dxmvvm:ViewModelSource Type=productionViewModels:MainWindowViewModel}"
d:DataContext="{dxmvvm:ViewModelSource Type=designViewModels:MainWindowViewModel}">
I get the following error:
Error XAMLIL Unable to resolve type ViewModelSource from namespace
http://schemas.devexpress.com/winfx/2008/xaml/mvvm (line 13 position
9) Line 13, position 9.
I recall reading somewhere that I should try using the referenced assembly rather than the URL in the namespace definition. I'm unsure on how to do this.
Can someone help shed some light on how to debug this or what the possible resolution might be?
You can try using a namespace declaration using the referenced assembly in place of the URL: (replace the v19.1 with your referenced version)
xmlns:dxmvvm="clr-namespace:DevExpress.Mvvm.POCO;assembly=DevExpress.Mvvm.v19.1"
In my case, I was having a similar issue where I created a new DevExpress project, and it created the MainWindow.xaml with the assembly namespace declaration, but it would not build and I had to replace it with the URL declaration to get it working:
xmlns:dxmvvm="http://schemas.devexpress.com/winfx/2008/xaml/mvvm"
Perhaps the opposite will work in your case.
Also note that if the project builds and runs, any errors regarding the namespace declarations are likely not an issue - it's just the XAML parser not being able to get full access to the (un)built assembly and you are likely fine to ignore these errors if you're able to run your application.
So I have an application and a class library.
The class library has
UserControls/Test.xaml
Images/TestImage.png
Test image is marked as 'Content' and 'Copy to Output Directory' is set to false because I want all of my images to be stored inside the class dll.
Test.xaml looks something like this...
<UserControl x:Class="TestLib.UserControls.Test"
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"
mc:Ignorable="d"
>
<Image Source="/TestLib;component/Images/TestImage.png"/>
</UserControl>
The designer works fine but when I try to instantiate the UserControl/Test.xaml in my application then it throws the following exception:
System.IO.IOException occurred
Message=Cannot locate resource 'images/TestImage.png'.
Source=PresentationFramework
StackTrace:
at MS.Internal.AppModel.ResourcePart.GetStreamCore(FileMode mode, FileAccess access)
InnerException:
I have tried changing the resource type to "Resource" and "Embedded Resource" but neither makes any difference. I have also tried using the full pack string
"pack://application,,,/TestLib;component/Images/TestImage.png"
but it throws the exact same exception even stating the same 'images/TestImage.png'.
Edit: I forgot to mention that Images/TestImage.png is not "included" it is "included as link". Apparently this is the problem because of a compiler bug: Linked Files within a Folder Structure
The last URI should work with 'Resource' build action. Try code from this answer.
It looks like the solution is to not use "linked" instead of "included" resources within libraries. The compiler fails to respect their path which makes them impossible to reference when using them inside of a class library. See: Linked Files within a Folder Structure
Even if the linked file lives on the root of a project you still cannot reference it at runtime.
For some reason the following code is giving me an exception.
<Application.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="/PPCa.Common.Infrastructure;component/Skins/Default.xaml"/>
<ResourceDictionary>
<app:ResourceWrapper x:Key="ResourceWrapper" />
<app:NotOperatorValueConverter x:Key="NotOperatorValueConverter" />
</ResourceDictionary>
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Application.Resources>
Here is the exception:
System.Windows.Markup.XamlParseException occurred
Message=Failed to assign to property 'System.Windows.ResourceDictionary.Source'. [Line: 11 Position: 44]
LineNumber=11
LinePosition=44
StackTrace:
at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
InnerException:
Line 11 is this:
<ResourceDictionary Source="/PPCa.Common.Infrastructure;component/Skins/Default.xaml"/>
Am I somehow merging my dictionaries wrongly?
Why is no one answering my questions? Am I blacklisted or something. People used to help me out quite a bit more. Anyway, I discovered my problem. The exception was a red herring. The problem had nothing to do with my application resource definition. The problem I was having deep inside my resource dictionaries. I was merge-referencing a dictionary inside my dictionary that no longer existed. That was difficult to figure out.
Are these dictionaries in the same XAP? If so, a relative path should work. I have used all relative paths to merge in dictionaries without any issue. Here is an example of mine:
<Application.Resources>
<ResourceDictionary x:Name="appDictionary">
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary x:Name="ControlStylesDictionary"
Source="Resources/Styles/ControlStyles.xaml" />
<ResourceDictionary x:Name="MenuStylesDictionary"
Source="Resources/Styles/MenuStyles.xaml" />
</ResourceDictionary>
</Application.Resources>
That is the only difference I can see in your XAML.
If the dictionary is in another XAP, you need to download the XAP and load the dictionary from there.
I ran into the same problem, same generic error message and found the solution. This appears to be a bug IMHO.
I am building an app for .Net, SL5, WP7.1. To do this I put the code in the .Net app and add source links for the other projects. Works great.
My main app projects are called MyApp.Net, MyApp.SL, and MyApp.WP. However, I make the default namespace and project output for these projects simply MyApp. Again, works great as it should.
I place my resources in projects MyApp.Resources.Net, MyApp.Resources.SL, and MyApp.Resources.WP. There is a bit of a glitch with using the VS source links as Expression Blend wants direct access to the physical files and gets confused when (for example) the MyApp.Resources.WP project contains a source link to a MyStyles.xaml file in the MyApp.Resources.Net projects. Therefore, all my resource projects actually contain physical files. This works fine also, I just have to synch the files manually. No problems so far.
However, for my resource projects I change the namespace and output files to MyApp.Resources. This keeps my application code simple also, regardless the platform it's built for, the namespace is the same.
Yes, I know this is a bit complicated but it allows me to build for 3 platforms (technically 5 if you include Blendability and UnitTesting) all with the same code base.
To continue, if I create a ResourceDictionary as such
<ResourceDictionary Source="/MyApp.Resources;component/Styles/TextStyles.xaml"/>
I get the Failed to assign to property 'System.Windows.ResourceDictionary.Source' etc...
In short, I discovered that if the assembly name contains a '.' this error shows up. For example if I change my project names to simply 'Resources' it works fine. Or if I leave my projects with their default build names of 'MyApp.Resources.WP' it also works fine.
This has nothing to do with changing my resource dll output file names, I change them all day long and it works great, but if they contain a '.' I get the above error. For example, I can change the output name to "MyAppResourceThatWorks" (leaving the project name as MyApp.Resources.WP and load it in App.xaml with
<ResourceDictionary Source="/MyAppResourceThatWorks;component/Styles/TextStyles.xaml"/>
Works great. Change the output name to "MyAppResourcesThatDoNot.Work" and load it with
<ResourceDictionary Source="/MyAppResourceThatDoNot.Work;component/Styles/TextStyles.xaml"/>
Fails.
Yes, I tried changing the assembly properties, etc. etc. It's a load issue with Pack Uri's.
In my WPF project i keep a user control in a separate library project. The user control accesses resources in a separate XAML file, like this:
<UserControl.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="/Resources/ViewResources.xaml" />
</ResourceDictionary.MergedDictionaries>
<!-- Local styles here -->
</ResourceDictionary>
</UserControl.Resources>
The resource file, ViewResources.xaml, resides in a folder in the control library project named Resources. It has the default build action (Page) and custom tool (MSBuild:Compile).
The problem is when I reference the control library in my WPF application and use the user control. At runtime, I get the following XamlParseException:
Set property 'System.Windows.ResourceDictionary.Source' threw an exception.
...which wraps the IOException:
Cannot locate resource 'resources/viewresources.xaml'.
How can I fix this? I have tried to change the resource file's build action to "content" and have it copied to the output directory (that works for files and similar "dumb" resources). But to no avail. Also, it doesn't work property in the user control then.
Is there a better way to specify the path?
Will I have to move the resource file to the application project (I'd rather not, as it belongs in the user control's domain).
Found it.
Turns out there is a better way to specify the path, Pack URIs. I changed the XAML to the following:
<UserControl.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="pack://application:,,,/RoutingManager;component/Resources/ViewResources.xaml" />
</ResourceDictionary.MergedDictionaries>
<!-- Local styles here -->
</ResourceDictionary>
</UserControl.Resources>
and that fixed it.
I thought it was worth posting this just in case anyone else is struggling with the same problem, as I've spent over two hours fighting with syntax, etc. only to find that the solution was dead simple, but not that apparent:
When referencing a packed resource from another control library, it seems to work fine at design time, and even compiles without error, but fails at runtime with the 'Set property 'System.Windows.ResourceDictionary.Source' threw an exception' error. It turns out that simply referencing the resource assembly from your control library is not enough, you ALSO need to add a REFERENCE to the assembly containing the resource dictionary in you main application assembly, else it seems it does not get compiled into the application. (i.e. Startup Application (the one with app.xaml) -> Add Reference -> select assembly with referenced resource file/s).
Hope this helps!
In my case I had the ResourceDictionary and the UserControl on the same Library, but separate from the main application. What worked for me was specifying the name of the assembly in the format Adam suggested in the comment AND I had to change the ResourceDictionary in the project from Embedded Resource to Page. I didn't try using the pack:// format, but I assume it would work too.
<ResourceDictionary Source="/AssemblyName;component/Assets/MyResource.xaml"/>
I had the same error (IOException - file not found), which cost me a day of my life that I'll never get back.
Using neither the simpler "/assemblyname..." nor the "pack://...." syntax worked for me.
I was referencing the resource assembly in my main assembly correctly.
The error disappeared when I changed my xaml resource file Build Action property to "Resource", as mentioned above.
However, I then encountered a XamlParseException at this line:
<ImageBrush x:Key="WindowBackground" ImageSource="Images/gradient.png" />
(which I had hand-typed).
This left the xaml resource file I was trying to include with effectively an invalid dependency.
Oddly the fix was to delete the ImageSource property I had typed, re-insert it BUT select the image from the pulldown menus that appear as a result.
Even though the resulting line appears exactly the same, it clearly isn't.
Starting to dislike WPF (VS2013), but hope this helps.
:0/
I had the same situation, but the Pack URIs didn't help me, I was still getting "Cannot locate resource..." exception in the referencing (executable) project. What helped me, was the setting of my ResourceDictionary files in the custom control library project as Embedded Resource.