Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

XAML (WPF) designer does not resolve app resources in a consistent or meaningful way

Tags:

c#

wpf

xaml

I've often been troubled by designer issues where the XAML designer (WPF's "xdesproc") will display my controls in one way, but they will be displayed in a totally different way at run time. Often these differences come down to the fact that the static resources used at runtime (at the application level) are not the ones used in the designer.

This happens primarily when a large solution is made up of a number of projects - most of which are user control libraries, and a few of them are startup projects (applications, test harnesses, etc).

While using VS to edit a usercontrol in one of the libraries, I've discovered a trick from Blend whereby you can introduce the "DesignTimeResources.xaml" file in a project and visual studio will "respect" it and merge these resources as a supplement to the ones in the user control itself (as if they had been found in the logical tree for that usercontrol).

I thought that this trick would be sufficient so that I would be able to forgo the need for application-level resources in the designer. However, the "DesignTimeResources.xaml" doesn't solve all my problems. Nor does xdesproc consider this as a sufficient source of application-level resources either (ie. xdesproc might consider loading this both as its application-level resources and in the logical tree of the user control if it wanted to.)

After snooping on xdesproc with procmon, I find it behaves in very unusual ways in order to find the stuff that it wants to use for its application-level resources. The search mechanism that it uses does not seem very well-defined. If one is not careful, it either neglects to establish any application-level resources at all, or it picks randomly from one of the projects it might find in the outer solution (a project which is possibly not relevant to the usercontrol library in any way, but is found and is used because it contains a project item which happens to be an "Application/").

Can someone tell me if there is supposed to be a well-defined way that the xdesproc finds application-level resources while editing a usercontrol? My work-around is a lot of obsessive tinkering that involves unloading projects. I temporary unload all projects from my solution that have "Application" elements, with the exception of one. Unless I do this, xdesproc is liable to randomly pick one of them out and start happily using it for its app-level resources. It doesn't seem to limit itself to the current startup project in the VS IDE.

I would appreciate any pointers to help me understand what xdesproc thinks it should be using for its app resources. I suspect it was programmed to be "smart" and "just work". And it probably does work in many cases, except when it doesn't.

like image 616
David Beavon Avatar asked Nov 15 '25 17:11

David Beavon


1 Answers

I have a bit more of an answer on this topic (from someone other than myself). This is from a Microsoft engineer in the visual studio developer community...

see link:

https://developercommunity.visualstudio.com/content/problem/86265/xamlwpf-designer-will-not-find-application-resourc.html

I took a quick look at our logic for finding the application document. Your description on StackOverflow seems accurate. I'd summarize the designer's preference order as:

1.Application document from the project containing the open XAML file.

2.Application document from the startup project

3.Application document from the first project we find that references the project containing the open XAML file.

There is no designer feature to tell users which application document we chose. We generally assume that #1 or #2 will be used and that that's what most users want. I can understand that hitting #3 would lead to unpredictable results in complex solutions.

like image 103
David Beavon Avatar answered Nov 18 '25 06:11

David Beavon



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!