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.
Created attachment 5440 [details]
When referencing some PCL libraries from a Xamarin.iOS project, the linker fails with the following error:
error MT2002: Failed to resolve "System.Linq.Expressions.ParameterExpression
reference from "System.Core, Version=126.96.36.199, Culture=neutral,
I've seen this error with several PCL projects, most notably perhaps Autofac and Ninject.
IMO this is a really bad bug, as it breaks compatibility with some of the most popular nuget packages.
The following bug is probably related, but seems to have been closed:
It is not a linker issue, the member `System.Linq.Expressions.Expression::Variable` is not part of System.Core as shipped with Xamarin.iOS.
That _might_ be a bug or it's a limitation because not everything can be supported in an AOT scenario (which is mandatory to build iOS applications).
@Martin iirc you had a tool that checked if the BCL we ship had everything used by PCL profiles, right ? what that reported ?
I understand that AOT can't support the full Linq.Expressions API, however I thought that ParameterExpression was permitted.
I don't understand the mono code 100% but it seems to me that there is fallback implementation that will work without Reflection.Emit/with AOT:
In the issue I linked above, Martin Baulig seems to say that the error is due to PCL issues, not because of AOT limitations.
Additionally I've seen this problem (and similar linker problems) in code that works in a Xamarin.iOS project, but fails in a PCL project.
It seems to me that if the code works in a Xamarin.iOS project, it should be possible to make it work in a PCL project as well.
If you want a repro case for that scenario I might be able to create it, but it would probably take me some time.
I discovered this problem when I attempted to refactor our main model project to be PCL. We've used TinyIOC, and had the TinyIOC source in a "model" project.
When I moved the TinyIOC code to the Xamarin "app" project instead and made the model project PCL, I got this error, despite the fact that I don't think I made any functional changes to any source code.
The reason for the MT2002 error message is neither PCL or AOT related : it's because the member is not present and the linker can't resolve missing members.
The reason for this member absence (bug or limitation) needs to be confirmed. If it's a bug then it can be enabled, if it's a limitation then _maybe_ it can be worked around somehow.
Also the reason for the member *requirement* might be a PCL assembly. That might explain why the same project works correctly when not used with PCL (i.e. that member is not referenced, so the linker does not try to resolve it).
> Additionally I've seen this problem (and similar linker problems) in code that
> works in a Xamarin.iOS project, but fails in a PCL project.
Please file separate bug reports for them along with a self-contained test case. They might seem related but their causes could be different.
I actually had an old sample which included this method, but when I just tried to compile it again, I'm now seeing the same error. Maybe that's because I previously compiled without linking.
So I checked the source code and System.Linq.Expressions.ParameterExpression
System.Linq.Expressions.Expression::Variable(System.Type,System.String) is really not available on iOS. See https://github.com/mono/mono/blob/master/mcs/class/System.Core/System.Linq.Expressions/Expression.cs
Regarding the fallback implementation without AOT, that's the code in
Note that this is not a complete implementation, it's based on an old version of the DLR, so most of the newer .NET 4.0+ methods are missing.
We're using this on Android and Desktop Mono:
Would it be possible to add the ParameterExpression Variable(Type, String) method in Expression.cs or is it a fundamental limitation in how AOT works?
I.e. should I stop bugging you guys and start working on possible workarounds instead ;P ?
Having support for this would be really awesome IMO, a good IoC framework is a fundamental part of any large project.
I just had a quick look at the Full-DLR implementation (https://github.com/mono/mono/tree/master/mcs/class/dlr/Runtime/Microsoft.Scripting.Core/Ast) and it should be possible to add this one.
However, I don't think we should do it, there is no real benefit in adding a single method.
Ideally, we should eventually finish the interpreter, so we could simply use the Full-DLR implementation for these APIs.
Maybe this issue should really be a feature request then?
My vote is certainly to prioritize this, but obviously you probably have a lot of other things that are high priority.
I've similar issue:
error MT2002: Failed to resolve "System.Linq.Expressions.Expression System.Linq.Expressions.ExpressionVisitor::Visit(System.Linq.Expressions.Expression)" reference from "System.Core, Version=188.8.131.52, Culture=neutral, PublicKeyToken=7cec85d7bea7798e"
Failed to resolve System.Linq.Expressions.Expression System.Linq.Expressions.ExpressionVisitor::Visit(System.Linq.Expressions.Expression)
This bus doesn't allow me to use PCL in a significant way :-(
Same thing here, the class is internal and the method protected in the non-Full-AOT implementation.
Created attachment 5607 [details]
Test case to reproduce the error
Just compile the project
Martin: Can you say anything regarding timeline for a fix?
As more and more people start using PCL this problem is going to hit a lot of projects I think.
Exactly. The recent announcement of partnership with microsoft and pcl support brings me to use PCL, but after a lot of work I can create the final package. This is a big problem for me
Look at my previous comments #6 and #9. This is not a PCL issue.
It's also not a simple "bug" that needs to be fixed, Rewriting the DLR is a huge task which would certainly take weeks, if not months, just to write the code. This does not necessarily mean that it won't eventually happen one day, but there are no immediate plans to do this very soon at the moment.
Note that we're not using a custom Mono implementation for these classes on non-FullAOT systems, but a clone of Microsoft's DLR (http://dlr.codeplex.com/). So it may actually make sense to suggest this new feature to them. Last time I checked, there was some preliminary version of an Interpreter, but it was not complete.
*** Bug 13081 has been marked as a duplicate of this bug. ***