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 25050 [details]
Partial build output
When building a Xamarin Android project that has a reference to a net standard 2.0 library, which in turn references Microsoft.Identity.Client, the linker seems to have at least one, potentially two bugs.
First is that it's unable to link Microsoft.Identity.Client (not sure whether it should be even attempting to in first place?). Second is that when I add the AndroidLinkSkip for that lib, the linker still attempts (and fails) to link that assembly.
I've created a repo that shows this problem here:
I'm using Xamarin.Android 184.108.40.206
This bug is related to the following issue that has been fixed already:
https://bugzilla.xamarin.com/show_bug.cgi?id=59109 (iOS Specific)
This was also filed under the Android product:
https://bugzilla.xamarin.com/show_bug.cgi?id=59822 (Android Specific)
Specifically the following comment provides insights for the cause of this issue:
There is then a comment of where the actual fix is located:
In short, you will need Xamarin.Android 220.127.116.11 which should hopefully make 15.4 Preview 4.
Thus I am marking this issue as a DUPLICATE of 59822.
*** This bug has been marked as a duplicate of bug 59822 ***
Taking a second look at this bug, I actually believe this is a different linking error that had very similar parameters to the known item I had marked as duplicate(F#, Microsoft.Identity.Client, Linker Problem). I am going to set the status to REOPENED given my earlier mistake. Apologies in advance.
Here is the output from the linker error that I believe differs from the issue in https://bugzilla.xamarin.com/show_bug.cgi?id=59822
2>C:\Program Files (x86)\Microsoft Visual Studio\Dogfood\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1628,5): error MSB4018: The "LinkAssemblies" task failed unexpectedly.
2>Mono.Linker.MarkException: Error processing method: 'System.Void Microsoft.Identity.Client.AuthenticationActivity::OnResume()' in assembly: 'Microsoft.Identity.Client.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve System.Void Android.Support.CustomTabs.CustomTabsIntent::LaunchUrl(Android.App.Activity,Android.Net.Uri)
2> at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference reference)
2> at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference reference)
2> at Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction)
2> at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body)
2> at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method)
2> at Mono.Linker.Steps.MarkStep.ProcessQueue()
2> --- End of inner exception stack trace ---
2> at Mono.Linker.Steps.MarkStep.ProcessQueue()
2> at Mono.Linker.Steps.MarkStep.Process()
2> at Mono.Linker.Steps.MarkStep.Process(LinkContext context)
2> at Mono.Linker.Pipeline.Process(LinkContext context)
2> at MonoDroid.Tuner.Linker.Process(LinkerOptions options, LinkContext& context)
2> at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res)
2> at Xamarin.Android.Tasks.LinkAssemblies.Execute()
2> at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
2> at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
2>Done building project "LinkerProblem.Droid.fsproj" -- FAILED.
https://developer.android.com/reference/android/support/customtabs/CustomTabsIntent.html#launchUrl(android.content.Context, android.net.Uri) indicates that this was added in 25.0.0. Interestingly we see that the trace is expecting a different method that is of launchUrl(android.app.Activity, android.net.Uri). I am still investigating this issue and will add updates to this issue when I figure the source cause.
The main cause is that Microsoft.Identity.Client has a dependency here:
Xamarin.Android.Support.CustomTabs (>= 23.3.0)
This of course installs a 23.3.0 version of this assembly which has the following definition:
LaunchUrl(Activity context, Uri url)
This of course does not exist for what is expected of the new definition in newer versions of this library. i.e.
LaunchUrl(Context context, Uri url)
Thus to fix this issue, you would need to explicitly use a newer version of Xamarin.Android.Support.CustomTabs. Whoever maintains this library should also bump the >= NuGet dependency to a newer version such as 18.104.22.168.
Thanks Jon, I'll explicitly reference version 22.214.171.124 or higher for now and try the linker again. Thanks for your help, I'll let you know how I get on with it.
Small correction and clarification on the previous comment. The dependency on 23.3.0 is *expecting* the method definition of LaunchUrl(Activity context, Uri url) whereas you might have a newer version installed such as 126.96.36.199+ which has the up to date method definition: LaunchUrl(Context context, Uri url). As you can imagine, the linker is trying to find a method that does not contain those parameters and thus the error is thrown.
The library in question is located here: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet
The problematic lines are here:
I have gone ahead and filed an issue on your behalf:
The current workaround for you since you do not control this library would be using Xamarin.Android.Support versions 23.3.0 as if you install the latest versions, it will have the new definition that the library does not expect.
It looks like there is a fix here:
Thus I am marking this issue as RESOLVED UPSTREAM
Hey Jon, on that last Github the last action there seems to close the issue with a resolution of bumping the support libraries up to 188.8.131.52+ to workaround the issue. I'm going to go with your solution of bringing them down to 23.3.
My apologies, my interpretation was off there. I see now KPanwar is talking about bumping Microsoft.Identity.Client references up to 184.108.40.206+ not that I should bump my dependencies up to that version. Thanks for logging that issue with the guys managing that library for me by the way!
(In reply to Gary from comment #10)
> My apologies, my interpretation was off there. I see now KPanwar is talking
> about bumping Microsoft.Identity.Client references up to 220.127.116.11+ not that
> I should bump my dependencies up to that version. Thanks for logging that
> issue with the guys managing that library for me by the way!
No problem, thank you for reporting this and making our product better!
Hi Jon, I'm so swamped in issues right now with Xamarin/Paket/Net Core that I've not noticed that this bug I logged is solely about the linker skip not working.
If the AndroidSkipLink would work correctly then I should be able to avoid this issue by way of not linking Microsoft.Client.Identity without rolling back my support libraries to 23.3.0, is that not right?
As it stands, this issue and many more like it are piling up and I think we're going to have to ditch Xamarin now for good. It was a good platform a few years back but my team have been swamped with issues this past few weeks and we can't lose any more time to Xamarin bugs. (Walmart Labs).
I do not believe this is Linker related in this case per-say. I rather believe it's a problem of NuGet dependency resolution and the linker catches the issue. See:
I believe this is a red herring to the actual issue because even if the LinkAssemblies task ignored this skipped assembly, you would fail at runtime if this code got invoked. Secondly I believe that the LinkAssemblies task needs to load the assembly in order for it to be marked to be skipped. This error happens prior to that I believe which makes it seem like <AndroidLinkSkip> does not work.
However these items are added to a delimited list and then added to the options.SkippedAssemblies item to be processed by the linker:
You can then look to see how these are skipped: https://github.com/mono/linker/blob/master/tuner/Mono.Tuner/CustomizeActions.cs
I apologize for your trouble with the tooling, I believe this whole issue happened because of a bad dependency in the Microsoft.Identity.Client library and is resolved in their alpha version on myget. Many of these items are fairly new and need some time to iron out the issues such as netstandard2.0 support and paket items(Although paket has been around awhile).
Please let me know if there are any painpoints that I can help resolve. I know many of these items around nuget dependency resolution and the mono linker tend to be confusing.
Were you able to use the myget version of the Microsoft.Identity.Client package and then keep your Xamarin.Android.Support libraries at 25.3.1+?
Hi Jon, thanks for your comprehensive response, I appreciate it.
Yeah, I hear what you're saying and it makes sense.
Our team has been moving to Xamarin native from Xamarin forms for the past month and we've hit so many issues with tooling now that I think ultimately this one issue is, or could be the straw that broke the camels back. From VS for Mac to the linker, designer, Multi-Dex issues, this is all costing us the same time that a regular native app would have in the first place.
No, I've not got the myget version yet. Hopefully that will resolve one problem when I do. I tried setting Paket to explicitly take 23.3.0 for the support libraries and all I got from that was a StackOverflow. Till then I'm just forced to have Multi-dex on with the linker off.
(In reply to Gary from comment #14)
> Hi Jon, thanks for your comprehensive response, I appreciate it.
> Yeah, I hear what you're saying and it makes sense.
> Our team has been moving to Xamarin native from Xamarin forms for the past
> month and we've hit so many issues with tooling now that I think ultimately
> this one issue is, or could be the straw that broke the camels back. From VS
> for Mac to the linker, designer, Multi-Dex issues, this is all costing us
> the same time that a regular native app would have in the first place.
> No, I've not got the myget version yet. Hopefully that will resolve one
> problem when I do. I tried setting Paket to explicitly take 23.3.0 for the
> support libraries and all I got from that was a StackOverflow. Till then I'm
> just forced to have Multi-dex on with the linker off.
No problem Gary, If you have any suggestions for anything that we can improve or areas that are real pain points that we can look into making less painful please let me know. For multidex and linker type issues, I have quite a few blogs on my personal blog that might help demystify these topics:
Please be aware that any and all feedback will be put in the right hands to improve the product overall. Thanks again!