Xamarin

[SOLVED] The BindableProperty "Triggers" is readonly

Oliver Brown
— This upcoming video may not be available to view yet.

TLDR: When setting the Triggers property in XAML, use the actual type of the parent tag, not a supertype.

After recently updating Xamarin Forms from 2.3.2.127 to 2.3.3.175, I started getting an InvalidOperationException: The BindableProperty "Triggers is readonly" inside InitializeComponent. Unlike many problems, this was quite easy to track down. InitializeComponent errors are generally XAML, and in the page in question there was a single Trigger. In this case the solution was simple. The Trigger was on a custom Button type, but I was setting it specifically using Button.Triggers. Changing it to be the actual type fixed it. So, I changed it from

<local:MyButton>
  <Button.Triggers>
    <DataTrigger ... />
  </Button.Triggers>
</local:MyButton>

to

<local:MyButton>
  <local:MyButton.Triggers>
    <DataTrigger ... />
  </local:MyButton.Triggers>
</local:MyButton>

I believe the original should be valid (and previously was) but the change is simple enough to not be a big problem.

Xamarin Forms frame is the wrong color

Oliver Brown
— This upcoming video may not be available to view yet.
screenshot

screenshot

Xamarin Forms uses a naive conversion from it’s platform independent Color class to iOS’s CGColor, and as a result, Frame controls end up with inconsistent background colors. I’ve added a demo here.

Xamarin Forms coming to macOS

Oliver Brown
— This upcoming video may not be available to view yet.

Since .NET and Xamarin were open sourced, I’ve kept a casual watch on their repositories for interesting things.

Recently I noticed this pull request “Change appearance of NSTabView”. This immediately stood out since NSTabView is an AppKit (i.e. macOS) API as opposed to a UIKit (i.e iOS) API.

A quick read of the details and is indeed about some difference between NSTabView and UITabBar. The pull request is targeting the branch “macos” and it seems it’s been in development since at least August 17th.

[SOLVED] Xamarin Android and no-version-vectors

Oliver Brown
— This upcoming video may not be available to view yet.

TLDR: An error containing “–no-version-vectors” is probably fixed by updating your Android SDK Build Tools to at least 23.

I recently upgraded a project to the latest version of Xamarin Forms and got the following error: /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets: Error: Tool exited with code: 2. Output: ERROR: Unknown option '--no-version-vectors'

A quick $ grep -ri "no-version" . on the project revealed it was being used in a dependency brought in by the Forms update: ./packages/Xamarin.Android.Support.Vector.Drawable.23.3.0/build/Xamarin.Android.Support.Vector.Drawable.targets: $(AndroidResgenExtraArgs)--no-version-vectors

Long story short, this parameter is for the aapt tool in the Android SDK Build Tools from at least version 23. Updating through the Android SDK manager fixed it.

[SOLVED] System.ExecutionEngineException: Attempting to JIT compile method

Oliver Brown
— This upcoming video may not be available to view yet.

TLDR: Check multiple references to the same nuget package are all on the same version if you use the Mono linker.

Since my ability to post regularly on things I’m interested in is not great, I figured I could at least post stuff that might be useful.

I recently upgraded a Xamarin iOS app from the “classic” (32bit only) API to the Unified API. After doing so I got the error message:

System.ExecutionEngineException: Attempting to JIT compile method
```.

This is caused by the Xamarin (Mono) linker removing code that is only referenced dynamically. The usual solution is to let the compiler know somehow that you are using the code (using a Preserve attribute if it's your own code or something like MvvmCross's [LinkerPleaseInclude.cs](https://github.com/MvvmCross/MvvmCross/blob/f72a92e8a81b9179d1f75d6214eee8c9ca176221/nuspec/TouchContent/LinkerPleaseInclude.cs.pp) otherwisr).

In my case, this did not fix the problem. It turns out the Unified API upgrade was a red herring. I had also updated a few nuget packages at the same time. One of them was used in several projects, but I'd missed updating one of them (so I had Project A using v1 of a package and Project B using v2 of a package). This meant my efforts to stop the linker from removing some stuff only worked on one version of the package.