Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Xamarin.Forms is missing the equivalent of XamlServices.Load and XamlServices.Save.
These methods can be found here:
Instead, the closest that Xamarin.Forms offers is an extension method that is tightly-coupled to BindableObject. This is poor design and reflects poorly on the capabilities, intention, and understanding of Xaml. Xaml is intended to be an *object* graph description language, not just a serialization language for presentation-based elements.
As seen above in XamlServices, any NET Framework object can be serialized and deserialized using these methods, not just elements of a Presentation-based nature. A developer is able to serialize and deserialize *any* object using the functionality in XamlServices.
Xaml is truly the superior serialization language and should be provided (and implemented) as such in Xamarin.Forms. Xamarin.Forms offers the IMarkupExtension which is a spot-on conceptual implementation Xaml's superstar, but tightly-coupling serialization to any object besides System.Object does a disservice to its overall intention and should be corrected.
IMO, of course. :) Please let me know if you have any questions around this, or if I can assist in any way.
We are aware of the tight coupling. This has to do partly with the young age of the Xaml system and partly to do with the need to get a working system out first before we open it further. I appreciate your feedback and will make sure it gets discussed in a design meeting, however it seems obvious to me that when/if we really have no bigger fish to fry (crashers/etc) we will move to address this.
OK... thank you for your great explanation Jason, and for all your hard work. I know you have a lot of big fish out there right now. Hang in there!!! :)
Although not optimal, we will have to use an ISerializer-type adaptation interface that offloads the serialization to the target platform in the meantime. If CSHTML5 supports Xamarin (and it sounds like they will), then that will work out nicely as it means only having to create 1 ISerializer implementation to make this work everywhere.
I have created a uservoice vote for this issue here:
FWIW, .NET Core 5 has announced that System.Xaml will not be included in the new core libraries, just the following from the XML spaces:
(full list here: http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-10-58-94-19/NetCore_5F00_OpenSourceUpdate.xlsx)
The current Xamarin.Forms.Core.Xaml is the closest offering to System.Xaml (that I have seen, at least).
It would be (really!) nice to see a "Xamarin.Xaml" project based on this to replace System.Xaml with cross-platform feature parity. Also, it would also be really great to see Xamarin.Forms become open source so that we could submit this as a PR. This would definitely be something that I would be interested in implementing for you. :)
Forms is approaching the level of stability that Jason referred to in Comment #1. As we plan our upcoming releases, we will review this enhancement with fresh eyes.
Great... thank you for your feedback and continued interest in improving your product.
FWIW, there is an open issue on .NET Core's GitHub to port System.Xaml to .NET Core. It would be nothing short of amazing/wonderful to have your team join the conversation there and see if we can all unite behind a comprehensive, powerful, and performant Xaml model:
Thank you for any consideration and continued dialogue!