mandel-macaque
commented
6 years ago Taking a look at the project. Thanks for reporting the issue, will get back ASAP with some feedback.
Closed cwrea closed 4 years ago
mandel-macaque
commented
6 years ago Taking a look at the project. Thanks for reporting the issue, will get back ASAP with some feedback.
spouliot
commented
6 years ago System.String, netstandard, Version=2.0.0.0
Sadly the type references for custom attributes are not encoded as other type references :( and this can cause issues with type forwarders.
It seems the linker did not re-write this case so it points to something that's not available (netstandard.dll) at runtime.
mandel-macaque
commented
6 years ago App ran and confirmed bug.
spouliot
commented
6 years ago Yes, disabling the linker (default on simulator but not on this project) works fine.
The custom attributes have encoded the reference to netstandard types and, since they are encoded separately than normal type references, it was not updated by the linker. We do cover similar cases so I need to investigate why this case does not work.
spouliot
commented
6 years ago .custom instance void [xunit.core]Xunit.InlineDataAttribute::.ctor(object[]) = (The signature, taking an array of System.Object, not System.Type might be the cause why the linker did not resolve the type (from the data) and re-write it (to the final destination/asembly)
spouliot
commented
6 years ago Theory confirmed. Adding Console.WriteLine (typeof (string).AssemblyQualifiedName); in a test shows
System.String, mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e
i.e. assembly is mscorlib not netstandard
Also if I write my own attribute with a .ctor like
public MyAttribute (params Type[] data)
{
this.data = data;
}then
var x = typeof (XunitInlineDataTest).GetMethod ("Foo").GetCustomAttribute<MyAttribute> ();
Console.WriteLine ((x.Data [0] as Type).AssemblyQualifiedName);also shows
System.String, mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e
so resolving/re-writting works - it just apply to System.Type, not System.Object
rolfbjarne
commented
6 years ago The signature, taking an array of System.Object, not System.Type might be the cause why the linker did not resolve the type (from the data) and re-write it (to the final destination/asembly)
Sounds like a variation/duplicate of https://bugzilla.xamarin.com/show_bug.cgi?id=57825.
spouliot
commented
6 years ago It's a variation, the type is marked (and available) but still points to netstandard.dll so the attribute cannot be re-constructed at runtime.
spouliot
commented
4 years ago The attached test case works fine with master. This was a linker issue and likely fixed in mono/linker (in one of the milestones since this was filed here).
Steps to Reproduce
Build and run the iOS project, targeting either iPhone or iPhone Simulator.
The sample project includes a .NET Standard library with a single class containing some xUnit-style tests. There are iOS and Android platform projects that use xUnit's device runners to run the tests. Each test body simply asserts true — the tests differ only in signature and xUnit attributes used.
Expected Behavior
[Theory]with two distinct parameter values passed via[InlineData]attributes on the test. Hence the total executed test count of 4.)Actual Behavior
[Theory]attribute with[InlineData]and a value of typeSystem.Type:[InlineData(typeof(string))]. The exception reported is:Xamarin.Android also shows the same test failing in the same way. FWIW, this test succeeds in .NET Core, .NET Framework, and UWP. This issue was discovered while trying to adapt some of the unit tests from Entity Framework Core to run in iOS and Android apps. This kind of test is used in EF Core's own test suite. See method
It_maps_strings_to_not_null_types()at: https://github.com/aspnet/EntityFrameworkCore/blob/2.0.2/test/EFCore.Sqlite.Tests/Storage/SqliteTypeMappingTest.csI thought perhaps as this is Reflection-related that it could be a known limitation in Xamarin, but in the Xamarin.iOS Limitations page, at bottom of the System.Reflection.Emit section, it mentions "But [except for Reflection.Emit] the entire Reflection API, including Type.GetType ("someClass"), listing methods, listing properties, fetching attributes and values works just fine."
While the attribute value in this case is not a simple type like
stringorint, having an attribute value of typeSystem.Typeis clearly of some use, and I think this ought to work.Environment
Build Logs
Example Project (If Possible)
XunitInlineDataIssueSoln.zip