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 5094 [details]
Reported on behalf of a user. There's also a similar report on StackOverflow: http://stackoverflow.com/questions/17849100/system-platformnotsupportedexceptionthis-platform-is-not-supported-with-tasks
## Steps to reproduce
1. Open attached test case in VS2012.
2. Build the HttpAsyncLibrary project (to generate the HttpAsyncLibrary.dll reference).
3. Run the HttpAsyncTest app on device.
3. Tap the button in the running app.
The app breaks on a PlatformNotSupportedException after the call to `Example.HttpRequestAsync()` completes.
The exception is thrown by the `System.ExecutionContextLightup.Run()` method:
if (LightupType.ExecutionContext == null || LightupType.ContextCallback == null)
throw new PlatformNotSupportedException ();
Add "--nolinkaway --linkskip=mscorlib" under "Project Options -> iOS Build -> Additional mtouch arguments" for the HttpAsyncTest project.
## Version information
Xamarin.iOS 1.4.2, with Xamarin.iOS 18.104.22.168 on the build host
Tested on an iOS 5.1 iPod touch.
Oh, right. This might be unavoidable if the Microsoft.Bcl package uses reflection to access types when setting up LightupType. Might not be a bug.
--nolinkaway keeps around non-fully working code (mostly remoting which does not work on iOS). That code is removed by default to save space (about 100kb ) and because non-working features are bad.
OTOH that does not mean the check is there because it really needs the (missing) feature to works (but that needs to be fixed on the library side).
Got the same exception :
- appears in iphone device mode only, works ok in emulator !
- always appears when using the await keywork on "await Task.Delay(1000);" in an async delegate
- appears in both simple iOS apps, and also in PCL library projects using TaskEx.Delay(1000) with the async nuget package.
I don't have any bug with HttpClient package which works ok, but should be installed in both ios and pcl projects to work on a real device.
Created attachment 6763 [details]
Update test case: no more bug with latest stable versions
The problem associated with this test case is resolved as of Xamarin.iOS 22.214.171.124 (Mac) + Xamarin for Visual Studio 1.12.275.
Specifically, the `--nolinkaway --linkskip=mscorlib` workaround is no longer needed.
The original test case pre-dated the improved assembly resolver in Xamarin.iOS for VS 1.10. So there is one "new" workaround required. The HttpAsyncTest project must include an `app.config` that redirects `System.Net.Http` to use the Xamarin.iOS version, as mentioned under "Close to the finish line" on .
>  http://motzcod.es/post/78863496592/portable-class-libraries-httpclient-so-happy
Without the `app.config` workaround, the app will hit an error at runtime:
> System.InvalidOperationException: Operation is not valid due to the current state of the object
> in System.Lightup.Call<System.Net.HttpWebRequest, long>
> in System.Lightup.Set<System.Net.HttpWebRequest, long>
> in System.Net.HttpWebRequestLightup.SetContentLength
This new issue is distinct from the original problem, and it has its own report already: bug #17396.
In short, I believe this bug can now be closed!
@Brendan don't hesitate to close the bug you open :-)
Thanks for the updates!
Will do, thanks!
Also a correction for my comment 4: