@ChaseFlorell But if I don't want the ResourceDictionary on a page it means I can't create my own ResourceDictionary as a workaround I did have to add the Resources to a page and Retrieve them.

Background info

I was trying to add Application.Resources to an Mvvmcross application. MvvmCross application relies on you building a MvxApplication (Which doesnt inherit from Application) meaning you do not have an Application.Resources property for your application (Can't put them in the App.xaml class)

You can however use Xamarin.Forms.Application.Current.Resources = new MyResourceDictionary();

But you can't create your own Xaml resource dictionary because it is a Sealed class.

What I infact had to do was create a dummy ContentPage with Resources as you have shown and do a for loop on the Resources adding them to my own Resource Dictionary..

Was just wondering whether there was any valid reason as to why it was a Sealed class

I understand your dilemma now (it wasn't clear in the original question). I too tried the same thing and hit a wall. I simply wanted to create a ResourceDictionary.xaml page... and you're right, we cannot.

I do know from a number of months ago that the X.F team wants to un-seal the majority of the API, but they will only do so when they feel it's in a finished state, which makes sense.

I'm not sure if I'd throw it up on Bugzilla, but definitely on UserVoice.

I think you're mixing up some terms here. In C# sealed just means you can't create subclasses. It doesn't mean you can't create instances using the constructor. As long as the type has a public constructor (which this one does) you can create instances of it using new, and then you can add things to it. You can also create one in XAML anywhere that a ResourceDictionary is supported. I even just tested making a new class that has a Styles property of type ResourceDictionary, and I created that ResourceDictionary within a XAML file. All of that works. So what specifically are you trying that doesn't work?

The custom class isn't accomplishing anything for that use case. You're just describing having multiple instances of resource dictionaries that you can merge together. The feature you're missing for that is merged resource dictionaries, which WPF and other Microsoft XAML variants have but Xamarin.Forms doesn't.

Even if you could make a custom subclass this XAML syntax wouldn't work:

Because the Application.Resources property is a singleResourceDictionary, and it would throw an exception if you try to put multiple objects in that property. The way it would need to work using merged resource dictionaries is like this:

Again, none of that requires a custom subclass. I can't think of any use cases for custom subclasses of ResourceDictionary, especially not the ones given in this thread. Merged resource dictionaries are the way to support composable XAML resources in every other XAML framework. They're very powerful.

I suppose that's a fair point, but it would still be mooted if you already had that feature, which was the premise I was starting with when I said I couldn't think of a use case. So can you think of any other use cases?

The fact is that there is some advantage to not having to worry about subclasses. It might be cheaper for them to give us the one feature we actually need than to unseal the class and try to handle all the other possible cases. Personally I would much prefer that they implement merged dictionaries as a first class concept rather than the community having to do it.