Search code examples
xamarin.iosxamarin.androidportable-class-library

How to correctly implement type forwarding?


I am about to write a shim assembly for Microsoft.Threading.Tasks.Extensions to be able to build Mono projects (I described the issue here), but there are a few things I am not sure.

1) Assembly contains the following methods (some with multiple overloads):

  • FromCancellation,
  • HandleEapCompletion
  • ReadAsync
  • WriteAsync
  • FlushAsync
  • CopyToAsync
  • CopyToAsyncInternal
  • ReadBlockAsync
  • ReadLineAsync
  • ReadToEndAsync
  • WriteLineAsync
  • GetResponseAsync
  • GetRequestStreamAsync

How can I find out which types I should forward and which methods to implement? And those that should be forwarded, where should I redirect them? In this case I suspect I will have to provide implementation because they don't exist in Mono assemblies, but how do I know for sure?

2) Do I need to implement or type-forward everything, or only stuff that is used in my code? In a latter case, if I skip some of the required types or methods, how will I know? I noticed that I am not getting a compiler error for missing methods - it only complains about missing assembly with no hint about what methods it is looking for. Will I get any hint from a compiler if I leave unforwarded types or not implemeneted methods?

UPDATE. There are two types defined there: System.Threading.Tasks.TaskServices and AsyncExtensions. None of them is known to Android/Touch projects. I can only forward types that are referenced by the assembly, and these two are not. Does this mean I have to implement them?


Solution

  • You shouldn't really be type-forwarding methods - instead you should be type-forwarding types.

    My advice - based on what I did for System.Windows and System.Net - is to start by type-forwarding all types in the reference assemblies.

    After you do this - when you build - you'll probably discover some that won't type-forward. For those you can either:

    • simply miss them out - in which case some code will later fail at runtime with some variant of Missing exception.
    • implement stub versions - with liberal helpings of NotImplementedException
    • implement replacement versions (although I would shy away from doing this - would probably be better to talk with the Mono guys and try to patch the Mono implementations)

    I believe the new Mono3 implementations of the Async code is very complete - so I don't think you should hit too many problems.