How I discovered this #XFQaD
When I was reorganizing the application resources on my current side project, I decided to create some thematically divided ResourceDictionary files. This has led me to do a quick research on Xamarin.Forms resource dictionaries.
If you’re doing this research, you will stumble upon this post from 2018 (!), where the hint to the magic I’ll show you soon was hidden.
Until now, I only used this with ResourceDictionary files. Maybe it will be helpful also for other XAML resources like controls (I will try that in the future).
How to make XAML only files compile
Add a new XAML file (sample is still ResourceDictionary) to your project:
Delete the code behind file, and add your XAML code. Before hitting the Build button, add this line immediately after the .xml file header:
<?xaml-comp compile="true" ?>
This line is where the magic happens. It tells the compiler to include the XAML file in the Build, pretty much like it does with XAML compile attribute in the code behind file.
Conclusion
The only place where I found this hint was the blog post mentioned above. Neither the docs on XAML Compilation nor the docs on resource dictionaries are mentioning this trick. It somehow went quietly from the nightly builds into production code.
Using this trick, we are able to have a more clean project structure. As always, I hope this post will be helpful for some of you.
The one thing to note in this approach is to avoid using the x:Class attribute usually defined on the XAML file pointing to the code-behind class. If that attribute is present, this will compile without any error but will end up in a runtime exception.
You are right. As this one is mentioned in the documentation for the standalone ResourceDictionary, I didn’t mention it again (as I linked to the docs, anyway). I should have mentioned it, I guess.
Cheers, cute little trick to manage resources effectively 🙂
Another gotcha – if you have multiple non-code-behind resource dictionaries present in your app.xaml – and any resources in one depend on resources defined in another – the order they appear in app.xaml matters. For example, Colors.xaml should be defined before Styles.xaml, if Styles.xaml has items that use colors from colors.xaml. I scratched my head over that one for a long while! I’m not used to the order of definitions in C# based code mattering, that’s usually a bug more common to JavaScript. I am assuming this also means we can’t have “sibling” resource dictionaries that contain items defined in each other.
My last comment appears to be wrong :haha As far as I can actually see, you can’t have separate dictionaries that use static resources defined in other dictionaries. At least using this code-less approach. I am very happy to be corrected if someone can help me out.
Well, as far as I remember one has to merge the dictionaries. I haven’t tested it with the codeless approach until now, but merging dictionaries works like described here. You were right, order matters.