Bug 44594 - Implementing Intents interfaces sometimes generates inaccessible signatures
Summary: Implementing Intents interfaces sometimes generates inaccessible signatures
Status: RESOLVED DUPLICATE of bug 39779
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: iOS add-in ()
Version: Trunk
Hardware: PC Mac OS
: --- normal
Target Milestone: master
Assignee: Jeffrey Stedfast
Depends on:
Reported: 2016-09-21 19:15 UTC by Larry O'Brien
Modified: 2016-09-22 05:36 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Sample project showing signatures (44.24 KB, application/zip)
2016-09-21 19:15 UTC, Larry O'Brien

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Larry O'Brien 2016-09-21 19:15:24 UTC
Created attachment 17650 [details]
Sample project showing signatures

There are a number of interfaces in Intents that combine the component interfaces within an Intents domain (e.g., IINWorkoutDomainsIntentHandling, IINMessagesDomainHandling). When a class is declared as implementing one of these "rollup" interfaces, one can right-click on the interface declaration and use "implement interface..." to generate stubs. However, the methods generated have type signatures that refer to Trampolines types. 

To recreate: create an XS Project. Now add an "Intents" extension. Within the Intents project template, change the type signature to, e.g.,:

    [Register ("MyIntentHandler")]
    public class MyIntentHandler : INExtension, IINWorkoutsDomainHandling

Right-click on the IINWorkoutsDomainHandling interface and choose "Quick fix/implement interface". The methods generated are, e.g., :

    public void HandleEndWorkout (INEndWorkoutIntent intent, [BlockProxy (typeof (NIDActionArity1V58))] Action<INEndWorkoutIntentResponse> completion)

The types of NIDActionArity{etc} are internal to Trampolines and the generated code cannot be used by customers. 

The same BlockProxyAttribute behavior occurs on some (but not all) individual interfaces. e.g., IINCancelWorkoutIntent does not generate the `BlockProxyAttribute` but IINStartWorkoutIntentHandling.HandleStartWorkout does. 

Workaround: strip out the `BlockProxyAttribute` on generated signatures.
Comment 1 Sebastien Pouliot 2016-09-22 01:50:00 UTC
That was discussed a while ago but I can't find a bug (it was likely not filed). This is an IDE behaviour that would need to change in both XS and XVS.
Comment 2 Rolf Bjarne Kvinge [MSFT] 2016-09-22 05:36:41 UTC
I found bug #39779, which says it's a roslyn bug: https://github.com/dotnet/roslyn/issues/5646

*** This bug has been marked as a duplicate of bug 39779 ***