#XFQaD: Compile XAML without code behind in Xamarin.Forms

Recently, I discovered the possibility to have XAML files without code behind in Xamarin.Forms. This #XFQaD shows you how to make them work.

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.


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.

Until the next post, happy coding!

Posted by msicc

.NET Dev at day & night, Geek. Father of 2 teenagers, husband of a fantastic wife. Founder of MSiccDev Software Development. Opinions are mine.


[…] #XFQaD: Compile XAML without code behind in Xamarin.Forms (Marco Siccardi) […]

[…] #XFQaD: Compile XAML without code behind in Xamarin.Forms (Marco Siccardi) […]

Vijay Anand E G

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.

Vijay Anand E G

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.

[…] to be available there as well. This can be done by loading the colors into a ResourceDictionary. As you might remember, I prefer codeless ResourceDictionary implementations. This time, however, we need the code-behind […]

Join the discussion right now!

This site uses Akismet to reduce spam. Learn how your comment data is processed.