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 2787 [details]
Generated source file that caused complier error
I'm trying to bind the beta Urban Airship Android SDK jar file and am getting a compilation error in a invoker class that is being generated because two private fields using the same name were created.
The exact error is:
/Users/bartsipes/Projects/UrbanAirship-Android/AndroidSDK.Binding/AndroidSDK.Binding/obj/Debug/generated/src/Com.Google.Protobuf.GeneratedMessageLite.cs(39,39): Error CS0102: The type `Com.Google.Protobuf.GeneratedMessageLite.ExtendableBuilderInvoker' already contains a definition for `id_internalGetResult' (CS0102) (AndroidSDK.Binding)
And the occurs in the Com.Google.Protobuf.GeneratedMessageLite.cs generated file that is attached.
The problem can be reproduced by building my project located here https://github.com/bartsipes/UrbanAirship-Android.
Forgot to mention that I brought this up on Xamarin Chat and @jonp replied:
@bartsipes please file a bug
@bartsipes the "simple" workaround is to just remove all internalGetResult() bindings: <remove-node path="/api/package[@name='com.google.protobuf']/class/method[@name='internalGetResult']" />
@bartsipes but when i do that i then get another 83 errors, so i need eno to look at that.
The generated api.xml contains two internalGetResult() signatures which is certainly a bug. However you cannot bind this method as is, because we never support such method covariants/contravariants; they are in generic class which derives from another generic class and generics don't exist in jar (they only exist in the sources). You have to either fix them manually in case you can, or completely remove them.
The same principle applies to those remaining 80+ errors.
OK, I think that makes sense.
Since the UrbanAirship library isn't intending to expose the com.google.protobuf code, I just added <remove-node path="/api/package[@name='com.google.protobuf']" /> so code should only be generated for the UrbanAirship classes.
I now receive the following errors:
/Users/bart/Projects/UrbanAirship-Android/AndroidSDK.Binding/AndroidSDK.Binding/obj/Debug/generated/src/Com.Urbanairship.Util.AsyncImageLoader.cs(111,111): Error CS0029: Cannot implicitly convert type `System.Delegate' to `Com.Urbanairship.Util.AsyncImageLoader.Delegate' (CS0029) (AndroidSDK.Binding)
and this one which occurs 8 times:
/Users/bart/Projects/UrbanAirship-Android/AndroidSDK.Binding/AndroidSDK.Binding/obj/Debug/generated/src/Com.Urbanairship.Util.UnzipperTask.cs(71,71): Error CS0029: Cannot implicitly convert type `System.Delegate' to `Com.Urbanairship.Util.UnzipperTask.Delegate' (CS0029) (AndroidSDK.Binding)
Are these bugs as well or is there some way to tweak the way the code is being generated?
Sorry for my rambling. This is the first binding project I've created. I was able to fix the errors I just listed by adding:
<attr path="/api/package[@name='com.urbanairship.util']/class[@name='AsyncImageLoader.Delegate']" name="managedName">AsyncImageLoader.AsyncImageLoaderDelegate</attr>
<attr path="/api/package[@name='com.urbanairship.util']/class[@name='UnzipperTask.Delegate']" name="managedName">UnzipperTask.UnzipperTaskDelegate</attr>
No worries, and sorry I had to deal with other binding bugs and didn't spare enough time to review the entire errors you had. Now with market billing jar file I created from Android SDK extras (changed eclipse project to check "Is Library" to build a jar from extras/google/market_bililng) and it successfully built with your latest repo.
I keep it open since we still have api.xml generation bug (duplicate field). Thanks for the report.
OK, after investigation I found that I misunderstanding the cause of the problem. There was no duplicate method elements in the same class element in api xml, but they rather resided in different classes. So, this falls to the case I mentioned on comment #2 and the derived one has to be eliminated by <remove-node /> element.
(We might be able to improve such override situation, but it needs decent method variant detector in Java context and generator to resolve every issue involved, which cannot be supported at this state. We have internal record for future feature enhancement so no need to keep it open and have it confused with the mentioned problem.)