Bug 51731 - XAML parsing exception on iOS only for List<T>
Summary: XAML parsing exception on iOS only for List<T>
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.3.4
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2017-01-24 09:39 UTC by Philipp Sumi
Modified: 2017-01-26 15:30 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Philipp Sumi 2017-01-24 09:39:43 UTC
About to port my Android forms app to iOS - this is not smooth at all despite it's all XAML. Here's one during loading of a page that declare a dynamic list:

In the header:

In the page:
    <generic:List x:TypeArguments="controls:TabsModel"> ... </generic:List>

This crashes hard on me with the following exception:

 Xamarin.Forms.Xaml.XamlParseException: Position 24:18. Type generic:List not found in xmlns clr-namespace:System.Collections.Generic;assembly=System.Collections
  at Microsoft.Scripting.Interpreter.NewInstruction.Run (Microsoft.Scripting.Interpreter.InterpretedFrame frame) [0x0004d] in /Users/builder/data/lanes/3985/9975cb17/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/mcs/class/dlr/Runtime/Microsoft.Dynamic/Interpreter/Instructions/TypeOperations.cs:77 
  at Microsoft.Scripting.Interpreter.Interpreter.Run (Microsoft.Scripting.Interpreter.InterpretedFrame frame) [0x0001b] in /Users/builder/data/lanes/3985/9975cb17/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/mcs/class/dlr/Runtime/Microsoft.Dynamic/Interpreter/Interpreter.cs:126

Works just fine in Android. I could work around this with a custom class that just extends List<T>.
Comment 1 Stephane Delcroix 2017-01-26 14:56:54 UTC
Are you using a PCL project or Shared Assets ?
Could you please attach the simplest possible reproduction project triggering this issue so we can investigate a bit more ?

Comment 2 Philipp Sumi 2017-01-26 15:00:47 UTC
Sorry, that code is gone.

That was PCL. The repro is rather simple I guess: Take an arbitrary ContentView you have lying around, declare a bindable property of type List<object>, and set it with the XAML from above:

public class Foo { }

    <generic:List x:TypeArguments="local:Foo">
        <local:Foo />
        <local:Foo />
        <local:Foo />
Comment 3 Philipp Sumi 2017-01-26 15:01:49 UTC
Then, the fix would be a custom class:

public class FooCollection : List<Foo> { }
Comment 4 Stephane Delcroix 2017-01-26 15:21:55 UTC
I tested both PCL and SAP and could not reproduce it.

A few hints on what to look for if it happens again: 
 - the xmlns is not the one I usually for lists. I use xmlns:scg="clr-namespace:System.Collections.Generic;assembly=mscorlib" (using mscorlib assembly). Again, I tested both, both works in this case, but depending on your dependencies it might matters,
 - it might be the linker removing List before executing the app. Try disabling it. But I wasn't able to reproduce the issue with LinkingAll enabled...
 - you can use XamlC and get that call resolved at compile time, on the right assembly.
Comment 5 Philipp Sumi 2017-01-26 15:30:38 UTC
Thanks for investigating it, Stephane! Sorry there wasn't an easy repro - let's hope R# just messed up a bit here with the declarations. Either way, I was fine with the custom collection, so all is good. Plus the thread here as a reference for others :)