Bug 39520 - User is not able to create Archive with using a Lib project for F# android application.
Summary: User is not able to create Archive with using a Lib project for F# android ap...
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 6.0.99
Hardware: All All
: High major
Target Milestone: 6.1 (C7)
Assignee: Atsushi Eno
: 40446 ()
Depends on:
Reported: 2016-03-10 15:05 UTC by Rajneesh Kumar
Modified: 2016-05-23 20:28 UTC (History)
6 users (show)

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

repro solution (35.03 KB, application/zip)
2016-05-19 19:24 UTC, Peter Collins

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:

Comment 1 Peter Collins 2016-03-10 15:31:54 UTC
Does this behavior change when only switching XA versions? I'm wondering if this issue could have been introduced by changes in XS.

What happens if you install all stable builds and then only upgrade XS to 6.0 and test this behavior?
Comment 3 Peter Collins 2016-03-10 19:23:17 UTC
I'm a bit confused by the last comment Rajneesh, does this failure also occur with Stable XA and C7 XS installed?
Comment 4 Rajneesh Kumar 2016-03-11 09:17:38 UTC
Hi @ Peter 
>>does this failure also occur with Stable XA and C7 XS installed?
Answer:- No. 

Comment 5 Greg Munn 2016-04-04 14:22:18 UTC
There are a bunch of activation issues which look like they're causing the issue. I would test again with the updates to the branches and the activation changes.
Comment 6 Greg Munn 2016-04-04 14:42:03 UTC
Looking at the log, and this bit in particular.

INFO [2016-03-10 17:42:08Z]: Running license sync for Android
INFO [2016-03-10 17:42:08Z]: Running license sync for iOS
INFO [2016-03-10 17:42:08Z]: Running license sync for Mac
INFO [2016-03-10 17:42:11Z]: Updated license: Android Starter
INFO [2016-03-10 17:42:11Z]: Updated license: iOS Starter
INFO [2016-03-10 17:42:13Z]: Updated license: Mac Starter
ERROR [2016-03-10 17:42:33Z]: Build failed.
System.ArgumentException: minimumEdition
  at Xamarin.Components.Ide.Activation.ActivationReason..ctor (XamarinProduct product, Restriction restriction, XamarinEdition minimumEdition, System.String errorText, System.String errorCode, System.String restrictedItem) [0x00060] in /Users/builder/data/lanes/2920/1e92171c/source/md-addins/Xamarin.Ide/Xamarin.Components.Ide/Activation/ActivationReason.cs:65 
  at Xamarin.Components.Ide.Activation.ActivationReason.FromToolError (System.String errorCode, System.String errorText) [0x00025] in /Users/builder/data/lanes/2920/1e92171c/source/md-addins/Xamarin.Ide/Xamarin.Components.Ide/Activation/ActivationReason.cs:176 
  at Xamarin.Ide.ActivationHelper.<HandleToolErrors>m__1 (MonoDevelop.Projects.BuildError be) [0x00000] in /Users/builder/data/lanes/2920/1e92171c/source/md-addins/Xamarin.Ide/Xamarin.Ide/Xamarin.Ide.Accounts/ActivationHelper.cs:61 
  at System.Linq.Enumerable+WhereSelectEnumerableIterator`2[TSource,TResult].MoveNext () [0x00064] in /private/tmp/source-mono-4.4.0/bockbuild-mono-4.4.0-branch/profiles/mono-mac-xamarin/build-root/mono-x86/external/referencesource/System.Core/System/Linq/Enumerable.cs:285 
  at System.Linq.Enumerable+WhereEnumerableIterator`1[TSource].MoveNext () [0x00062] in /private/tmp/source-mono-4.4.0/bockbuild-mono-4.4.0-branch/profiles/mono-mac-xamarin/build-root/mono-x86/external/referencesource/System.Core/System/Linq/Enumerable.cs:147 
  at System.Collections.Generic.List`1[T]..ctor (IEnumerable`1 collection) [0x0008b] in /private/tmp/source-mono-4.4.0/bockbuild-mono-4.4.0-branch/profiles/mono-mac-xamarin/build-root/mono-x86/external/referencesource/mscorlib/system/collections/generic/list.cs:99 
  at System.Linq.Enumerable.ToList[TSource] (IEnumerable`1 source) [0x00011] in /private/tmp/source-mono-4.4.0/bockbuild-mono-4.4.0-branch/profiles/mono-mac-xamarin/build-root/mono-x86/external/referencesource/System.Core/System/Linq/Enumerable.cs:835 
  at Xamarin.Ide.ActivationHelper.HandleToolErrors (MonoDevelop.Projects.BuildResult br, Boolean rebuild) [0x0000b] in /Users/builder/data/lanes/2920/1e92171c/source/md-addins/Xamarin.Ide/Xamarin.Ide/Xamarin.Ide.Accounts/ActivationHelper.cs:60 
  at MonoDevelop.MonoMac.XamMac2ProjectFlavor+<OnBuild>c__async0.MoveNext () [0x000d2] in /Users/builder/data/lanes/2920/1e92171c/source/md-addins/MonoDevelop.MonoMac/MonoDevelop.MonoMac/Project/XamMac2Project.cs:133 

we can see that you end up with Starter edition. Then looking at the code in ActivationReason and we can see that Stater is not valid edition at this point

> (int)MinimumEdition <= (int)XamarinEdition.Starter

So, given that we have made radical changes to activation, I think that we should re-test this the latest builds from C7 and / or master.
Comment 8 Rajneesh Kumar 2016-04-15 17:00:34 UTC
*** Bug 40446 has been marked as a duplicate of this bug. ***
Comment 9 Jonathan Pryor 2016-05-07 02:49:40 UTC
It would be nice if we could see Resource.designer.fs:65, but probably not relevant.

What I believe is the relevant difference between Xamarin.Android 6.0 (Cycle 6) and 6.1 (Cycle 7) that would impact F# generation is that FSharp.Compiler.CodeDom.dll was upgraded from 0.9.2 to 0.9.4, which was done in monodroid/cdc1a3b8 to fix Bug #24709.

I would surmise that while 0.9.4 may have fixed one F# generation bug, it presumably introduced another.

However, Xamarin.Android *does* perform some post-processing of F# files, so perhaps that is the problem?


@Peter/@Singh: This can be manually tested by taking a failing build, and replacing the installed FSharp.Compiler.CodeDom.dll file with the version installed with Cycle 6, restarting the IDE, and trying again.

It would likewise be interesting to know if FSharp.Compiler.CodeDom.dll fixes the issue:

Comment 10 Rajneesh Kumar 2016-05-09 13:00:57 UTC
Hi Jonathan, I tried to check this issue via adding FSharp.Compiler.CodeDom.dll to the project but but I am not able to do so:

To check this issue I have followed the steps mentioned below:

1. Create a Fsharp Android Project.
2. Add new F# Lib project to this solution.
3. Set reference to Main project.
4. Try Add FSharp.Compiler.CodeDom.dll Version:

Screencast: http://www.screencast.com/t/K80ixy5WA

Please let me know that what I am missing to test this issue. Or what steps should I follow to check this issue ?

Also after updating the package I am getting same behavior. 

Comment 11 Atsushi Eno 2016-05-19 11:03:48 UTC
@Rajneeshk FSharp.Compiler.CodeDom is used by Xamarin.Android itself and not something user app could reference.

I'm asking XS team how I can build or install F# project support addins on Linux (which is required for me to investigate this issue).
Comment 12 Peter Collins 2016-05-19 19:24:38 UTC
Created attachment 16039 [details]
repro solution

Using the current Beta and the newly attached repro project, the suggested workaround in Comment #9 (of using the FSharp.Compiler.CodeDom.dll shipped with C6SR4) works for me.

> 6.0.4-0/lib/xbuild/Xamarin/Android/FSharp.Compiler.CodeDom.dll
in place of
> 6.1.0-56/lib/xbuild/Xamarin/Android/FSharp.Compiler.CodeDom.dll
Results in the repro case building and deploying successfully. 

However, the FSharp.Compiler.CodeDom.dll from the version of the NuGet also results in the same build error reported after moving
> packages/FSharp.Compiler.CodeDom. 
> 6.1.0-56/lib/xbuild/Xamarin/Android/FSharp.Compiler.CodeDom.dll
Comment 13 Jonathan Pryor 2016-05-19 19:51:41 UTC
The erroneous output? https://gist.github.com/pjcollins/7e1cfb2d99dc61af61b5896179b87b8d#file-gistfile1-txt-L5

>     global.LibFSherp.Resource_String.library_name@ <- Resource_Resource_String.library_name@

Sounds like a bug in FSharp.Compiler.CodeDom. :-(

Regardless, there are two options here:

1. We accept this bug (Bug #39520).

2. We go back to FSharp.Compiler.CodeDom 0.9.2, which was distributed with C6SR4.

This *may* reopen Bug #40613 and Bug #24709.

In the absence of fixing FSharp.Compiler.CodeDom (help?), these appear to be the only options.

I'm inclined to go with (2).
Comment 14 Jonathan Pryor 2016-05-19 21:27:36 UTC
Fixed (for cycle7 ONLY) in monodroid/cycle7/75402fb7.

I'm not sure what should be done for master.
Comment 16 Peter Collins 2016-05-23 20:28:10 UTC
Bug #41254 was caused by a new support lib reference in the templates, and is a dupe of Bug #24709.

I'm able to verify the fix for this specific error with the following steps:
1. Create a new 'Modern Development' F# Android App in XS
2. Right click the top value in the solution tree -> Add new project
3. Select Android -> Library -> Class Library (F#)
4. Right click on the App project References -> Edit References
5. Go to the Projects tab, and add a reference to the newly created lib.

### Bad  - monodroid/cycle7/c479b9e0 ###
Solution fails to compile.
> error FS0010: Unexpected symbol '<-' in expression
> http://screencast.com/t/MmzsL0nY

### Good - monodroid/cycle7/52635947  ###
Solution builds and deploys successfully.
> http://screencast.com/t/ARjO5UGyCf