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.
When setting AutomationId, a System.InvalidOperationException was thrown with the message "AutomationId may only be set one time"
The cause of this can be clearly seen in the XF code at https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Core/Element.cs
Whilst it would not be common practice to change an existing AutomationId, doing so should not throw an exception.
Thank you for your feature request. Unfortunately the bug tracker is not the right place to initiate such a discussion, there is a xamarin evolution process available which you can use to pursue new features in Xamarin.Forms.
Please see here for more details: https://github.com/xamarin/xamarin-evolution
This is not a feature request. Xamarin.Forms is throwing an exception rather than doing what it would be expected to do. That's a defect.
John is by design. This would be a change to our approach.
As @rui said, changing the AutomationId is not supported, and the proper behavior is to crash
I suspect I can guess the reason for it being designed that way, but could somebody give the reasoning please. It seems to be an unnecessary constraint.
If the implementation is going to be left such that changing AutomationId throws an exception, can the documentation at least be updated to state that this happens. Locations for updating include:
We will update the docs as John suggested.
Still curious as to the reason for this being "by design". Can anybody clarify please? Without understanding why it is "by design" this still seems an unnecessary constraint.
Because UITEst will not reevaluate the tree, so allowing it to be changed after will give expectations that you could query by the value later, but that's not possible.