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 11813 [details]
[XI 8.10] Enabling linker for PCL with "duplicate" System.Threading.Tasks references causes "Could not load file or assembly 'System.Threading.Tasks'" on simulator
This is almost certainly a duplicate of Bug 31379, but I will file it anyway because the test case is simple, so it might be useful for QA to verify that this test case is also fixed after Bug 31379 is fixed.
As with Bug 31379 and Bug 29211, there are at least 2 workarounds:
1. Disable the linker for simulator builds. This both stops the problem and makes the build time significantly faster.
2. Add "-linkskip=System.Threading.Tasks" under "project options -> iOS Build -> Additional mtouch arguments".
## Steps to reproduce
Build and run the attached test case in the "Debug|iPhoneSimulator"
The app crashes due to a missing "System.Threading.Tasks" dependency.
### Excerpt from the simulator console log
> System.IO.FileNotFoundException: Could not load file or assembly 'System.Threading.Tasks' or one of its dependencies. The system cannot find the file specified.
> File name: 'System.Threading.Tasks'
> at System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity) [0x00081] in /Users/builder/data/lanes/1880/ef8c2f77/source/mono/mcs/class/corlib/System/AppDomain.cs:706
### Related build warning from the diagnostic build output
> There was a conflict between "System.Threading.Tasks, Version=22.214.171.124,
> Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and
> "System.Threading.Tasks, Version=126.96.36.199, Culture=neutral,
### Assemblies referenced by the Windows-compiled `HttpAsyncLibrary.dll`
> $ monop -r:HttpAsyncTest/libs/HttpAsyncLibrary.dll --refs
> System.Runtime, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
> System.Resources.ResourceManager, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
> System.Threading.Tasks, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
> System.Diagnostics.Debug, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
> System.Net.Http, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
> System.Threading.Tasks, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Note the duplicate reference to "System.Threading.Tasks".
## Regression status: regression between XI 8.9 and XI 8.10
BAD: Xamarin.iOS 188.8.131.52 (ef8c2f7)
GOOD: Xamarin.iOS 184.108.40.206 (f7736a4)
Updating milestone (the C6 release will be 9.2).
I am happy with calling this resolved on Xamarin.iOS 9.0 and Xamarin.iOS 9.2. In both versions the app now runs successfully on simulator. I will leave the target milestone unchanged for now. QA, if you like feel free to set the target milestone back to 9.0 after verifying on both versions.
The Application Output still shows a diagnostic error message:
> Could not find `System.Threading.Tasks` referenced by assembly `HttpAsyncLibrary, Version=220.127.116.11, Culture=neutral, PublicKeyToken=null`.
But I think that's fine because the app does run successfully on the simulator.
Verified with cycle6 builds and app launched successfully on simulator without any crash but diagnostic message as mentioned on comment#4 does appear. Based on comment #4 and based on my verification, I am closing this bug.
Application Output: https://gist.github.com/GouriKumari/052d1255dc8c42dfb68a
Test Env: https://gist.github.com/GouriKumari/264d2dbc7d4ed16b487c