Bug 35231 - [XI 9.1] The new behavior of btouch in XI 9.1 breaks all existing binding projects that include enum types. Perhaps this can be solved by changing the behavior of the "ObjcBindingCoreSource" build action?
Summary: [XI 9.1] The new behavior of btouch in XI 9.1 breaks all existing binding pro...
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: MSBuild ()
Version: XI 9.1 (iOS 9.1)
Hardware: PC All
: --- major
Target Milestone: 9.1 (iOS 9.1)
Assignee: Bugzilla
URL:
: 35207 ()
Depends on: 35232
Blocks: 35229 35230
  Show dependency tree
 
Reported: 2015-10-24 01:39 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2015-10-28 08:47 UTC (History)
4 users (show)

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


Attachments
Test case (5.09 KB, application/zip)
2015-10-24 01:39 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details
Diagnostic build output from XI 9.0 and XI 9.1 (3.68 KB, application/zip)
2015-10-24 01:45 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details


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:
Status:
VERIFIED FIXED

Description Brendan Zagaeski (Xamarin Team, assistant) 2015-10-24 01:39:09 UTC
Created attachment 13513 [details]
Test case

[XI 9.1] The new behavior of btouch in XI 9.1 breaks all existing binding projects that include enum types. Perhaps this can be solved by changing the behavior of the "ObjcBindingCoreSource" build action?


Additional context about the new behavior of btouch in XI 9.1:
[1] http://developer.xamarin.com/releases/ios/xamarin.ios_9/xamarin.ios_9.1/#Binding_generator_support_for_enums




## Regression status: regression in Xamarin.iOS 9.1




## Summary

This bug is an alternate way to view the problem presented on Bug 35229 and Bug 35230.

This bug takes the perspective that the new behavior of `btouch` should _not_ break existing projects where the only explicit definition of an `enum` types is in a file that uses the "ObjcBindingCoreSource" build action (i.e., essentially _every_ existing binding that uses enums).


To solve the problem from tis perspective, maybe the behavior of the "ObjcBindingCoreSource" build action could be modified so that `btouch` will no longer generate `.g.cs` files for `enum` types defined in these files. That way customers could continue to use enums "mostly as usual" for now, but gradually transition to placing them in `ApiDefinition.cs` files in the future for the added benefits discussed in [1].




## Temporary workaround 

Move the `enum` definitions (but _not_ the `struct` definitions) into the `ApiDefinition.cs` file (or any another file that uses the "ObjcBindingApiDefinition" build action rather than the "ObjcBindingCoreSource" build action). This would be the "intended" fix if viewing the problem from the perspective of Bug 35229 and Bug 35230.

(Note this only works on Mac at the moment due to a secondary bug in how `btouch` generates the `.g.cs` files for enums. I will add a link that secondary bug on this bug report shortly.)



### Alternate workaround (that works on both Mac and Windows)

Move the `StructsAndEnums.cs` file to a separate small iOS class library project, set the build action of the file to "Compile", and then reference that class library project from the binding project.




## Steps to reproduce

Attempt to build the attached test case on Mac:
> $ xbuild /t:Build UnifiedIosBindingProject1.sln

The test case is a "new from template", completely empty binding project with only the following lines added to the `StructsAndEnums.cs` file:

> public enum Foo : uint
> {
>     Bar,
>     Baz
> }




## Results

The build fails:

> /private/tmp/Working/UnifiedIosBindingProjectWithEnum/UnifiedIosBindingProject1/obj/Debug/ios/UnifiedIosBindingProject1/Foo.g.cs(37,14): error CS0101: The namespace `UnifiedIosBindingProject1' already contains a definition for `Foo'



### The "bad" `smcs` command on XI 9.1

The problem is that the final compilation step includes 2 different versions of the `enum` definitions:

> /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/smcs execution started with arguments:
>     /noconfig /debug:full /debug+ /optimize-
>     /out:obj/Debug/UnifiedIosBindingProject1.dll
>     Properties/AssemblyInfo.cs StructsAndEnums.cs
>     /private/tmp/Working/UnifiedIosBindingProjectWithEnum/UnifiedIosBindingProject1/obj/Debug/ios/ObjCRuntime/Messaging.g.cs
>     /private/tmp/Working/UnifiedIosBindingProjectWithEnum/UnifiedIosBindingProject1/obj/Debug/ios/UnifiedIosBindingProject1/Foo.g.cs
>     obj/Debug/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs /target:library
>     /unsafe+ /define:"__MOBILE__;__IOS__;DEBUG" /nostdlib
>     /reference:/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll
>     /reference:/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll
>     /reference:/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll
>     /reference:/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/mscorlib.dll
>     /warn:4


Note in particular the inclusion of _both_ `Foo.g.cs` and `StructsAndEnums.cs`. These are the 2 files that conflict.



### The "good" `smcs` command from XI 9.0

> /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/smcs execution started with arguments:
>     /noconfig /debug:full /debug+ /optimize-
>     /out:obj/Debug/UnifiedIosBindingProject1.dll
>     Properties/AssemblyInfo.cs StructsAndEnums.cs
>     obj/Debug/ios/ObjCRuntime/Messaging.g.cs
>     obj/Debug/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs /target:library
>     /unsafe+ /define:"__MOBILE__;__IOS__;DEBUG" /nostdlib
>     /reference:/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll
>     /reference:/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll
>     /reference:/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll
>     /reference:/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/mscorlib.dll
>     /warn:4

Note in particular the _absence_ of the `Foo.g.cs` file.



The `btouch` command _invocation_ itself is unchanged, but the new XI 9.1 `btouch` produces a `Foo.g.cs` file that didn't exist before

### `obj/` folder after `btouch` invocation on XI 9.1

> $ find obj
> obj
> obj/Debug
> obj/Debug/ios
> obj/Debug/ios/ObjCRuntime
> obj/Debug/ios/ObjCRuntime/Messaging.g.cs
> obj/Debug/ios/sources.list
> obj/Debug/ios/temp.dll
> obj/Debug/ios/temp.dll.mdb
> obj/Debug/ios/UnifiedIosBindingProject1
> obj/Debug/ios/UnifiedIosBindingProject1/Foo.g.cs



### `obj/` folder after `btouch` invocation on XI 9.0

> $ find obj
> obj
> obj/Debug
> obj/Debug/ios
> obj/Debug/ios/ObjCRuntime
> obj/Debug/ios/ObjCRuntime/Messaging.g.cs
> obj/Debug/ios/sources.list
> obj/Debug/ios/temp.dll
> obj/Debug/ios/temp.dll.mdb
Comment 1 Brendan Zagaeski (Xamarin Team, assistant) 2015-10-24 01:45:47 UTC
Created attachment 13514 [details]
Diagnostic build output from XI 9.0 and XI 9.1
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2015-10-24 02:07:20 UTC
The secondary Windows-only bug mentioned in Comment 0 for the "Temporary workaround" is now filed here: Bug 35232.
Comment 3 Brendan Zagaeski (Xamarin Team, assistant) 2015-10-24 02:23:28 UTC
*** Bug 35207 has been marked as a duplicate of this bug. ***
Comment 4 Sebastien Pouliot 2015-10-26 17:45:06 UTC
As this change (sharing binding code across iOS/tvOS/watchOS) is not immediate of benefit to customers we'll make this optional for XI 9.1.

Fixed in maccore/xcode7.1 897a0ef013f1d59776d70c467122af497442b593

Once verified by QA it will be backported to `monotouch-9.1.0-branch`
Comment 5 Arpit Jha 2015-10-27 08:10:09 UTC
*****************************
Reproduce Status:

*****************************
I have checked this issue with monotouch-9.1.0.18 and able to reproduce this issue with the help of bug description and observed that getting build error when build attached project through command line.
xbuild /t:Build ~/Downloads/UnifiedIosBindingProjectWithEnum/UnifiedIosBindingProject1.sln 

Build output: https://gist.github.com/Arpit360/0d22f94e13782e360cf4

*********************
Verify Status :

**********************
I am able to verify this issue using monotouch-9.3.1.59 and observed that project build successfully.

Build output: https://gist.github.com/Arpit360/8b1e63dfd8661892a24c

Environment Info: https://gist.github.com/Arpit360/bac81c0fd2a76f822031

Hence closing this issue
Comment 6 Jose Gallardo 2015-10-27 09:08:49 UTC
*** Bug 35229 has been marked as a duplicate of this bug. ***
Comment 7 Sebastien Pouliot 2015-10-27 10:41:40 UTC
backported to maccore/monotouch-9.1.0-branch 530a812539d67b88ef46042f93cc058ef88ec64b
Comment 8 Arpit Jha 2015-10-28 08:47:06 UTC
*********************
Verify Status
*********************

I have checked this issue with latest iOS 9.1 + C5SR5 build  monotouch-9.1.0.27.pkg and observed that app build successfully with command line


Build output: https://gist.github.com/Arpit360/4feb6f139e9681d77d1b
Environment Info: https://gist.github.com/Arpit360/f2f0429e48aba612e48d