Bug 35894 - "Building from the command-line requires a Business license." When building iOS App via TFS
Summary: "Building from the command-line requires a Business license." When building i...
Status: VERIFIED FIXED
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: General ()
Version: 4.0.0 (C6)
Hardware: PC Windows
: Normal critical
Target Milestone: 4.1.0 (C7)
Assignee: Adrian Alonso
URL:
: 36181 ()
Depends on:
Blocks:
 
Reported: 2015-11-16 11:48 UTC by Jesse Young
Modified: 2016-05-19 05:36 UTC (History)
18 users (show)

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


Attachments
XamarinTestApp.log (116.16 KB, application/octet-stream)
2015-11-16 11:48 UTC, Jesse Young
Details
Broker log files from mac (28.59 KB, application/octet-stream)
2015-11-16 14:48 UTC, Jesse Young
Details
Build log files from mac (2.39 KB, application/octet-stream)
2015-11-16 14:48 UTC, Jesse Young
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 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 Jesse Young 2015-11-16 11:48:09 UTC
Created attachment 13823 [details]
XamarinTestApp.log

# Steps to reproduce
Create new Xamarin Forms (Portable) project in Visual Studio and check into TFS.
Create a new (XAML) build definition in TFS using default template.
 - Build full solution
 - Set Configurations to build to "iPhone|Ad-Hoc"
 - Set MSBuild arguments to include /p:ServerAddress and /p:ServerUser with appropriate values

# Actual behavior
Build fails reports error as "Building from the command-line requires a Business license."

# Supplemental info (logs, images, videos)
Error from MSBuild log (full log attached):
       "D:\BuildsWksp\8\MDX\XamarinTestApp\src\XamarinTestApp\XamarinTestApp.sln" (default target) (1) ->
       "D:\BuildsWksp\8\MDX\XamarinTestApp\src\XamarinTestApp\XamarinTestApp\XamarinTestApp.iOS\XamarinTestApp.iOS.csproj" (default target) (3) ->
       (_DetectSdkLocations target) -> 
         C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(507,3): error : Building from the command-line requires a Business license. [D:\BuildsWksp\8\MDX\XamarinTestApp\src\XamarinTestApp\XamarinTestApp\XamarinTestApp.iOS\XamarinTestApp.iOS.csproj]


# Test environment (full version information)

=== Xamarin Studio ===

Version 5.10 (build 871)
Installation UUID: b6d317db-707d-446a-91c3-68213efa523a
Runtime:
	Mono 4.2.1 (explicit/6dd2d0d)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 402010102

=== Xamarin.Profiler ===

Not Installed

=== Apple Developer Tools ===

Xcode 7.1 (9079)
Build 7B91b

=== Xamarin.iOS ===

Version: 9.2.1.51 (Business Edition)
Hash: 3c0ec35
Branch: master
Build date: 2015-11-12 13:05:39-0500

=== Xamarin.Android ===

Not Installed

=== Xamarin Android Player ===

Not Installed

=== Xamarin.Mac ===

Not Installed

=== Build Information ===

Release ID: 510000871
Git revision: 4e9c5abb5ffdae12ba02ac49da83f8b2011dbb88
Build date: 2015-11-12 06:02:54-05
Xamarin addins: 55007ed0e56436f385d8e26394a45be563abc7e8
Build lane: monodevelop-lion-cycle6

=== Operating System ===

Mac OS X 10.10.5
Darwin mcadmins-Mac-mini.local 14.5.0 Darwin Kernel Version 14.5.0
    Tue Sep  1 21:23:09 PDT 2015
    root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64


TFS Build Server:
Microsoft Visual Studio Premium 2013
Version 12.0.31101.00 Update 4
Microsoft .NET Framework
Version 4.6.00081

Installed Version: Premium

...

Xamarin   4.0.0.1686 (4a80730)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android   6.0.0.33 (81fb408)
Visual Studio plugin to enable development for Xamarin.Android.

Xamarin.iOS   9.2.1.50 (2edcbef)
Visual Studio extension to enable development for Xamarin.iOS.
Comment 2 Adrian Alonso 2015-11-16 12:41:42 UTC
Hi Jesse,

A few questions:

1. Can you build a simple project against the same Mac from VS (just unfolding an empty app, connect and build)? 

2. Could you please also attach the Xamarin logs from the mac? You should be able to find them in ~/Library/Logs/Xamarin-4.0

Thanks,
Adruab
Comment 3 Jesse Young 2015-11-16 14:48:25 UTC
Created attachment 13827 [details]
Broker log files from mac
Comment 4 Jesse Young 2015-11-16 14:48:44 UTC
Created attachment 13828 [details]
Build log files from mac
Comment 5 Jesse Young 2015-11-16 14:50:04 UTC
1. Actually building while connected via a RDP session to the TFS Build agent, the same project builds just fine, it just seems to fail when queuing a build from within TFS.

2. I've attached the Build and Broker log files to the bug.
Comment 6 Adrian Alonso 2015-11-16 15:44:30 UTC
Hi Jesse, thanks for the logs. What account are you using to connect via RDP? Are you sure that the Build agent is using the same account to run the build? It seems that the Xamarin account is not configured (or logged in/activated) for the (Windows) user that the agent is using.
Comment 7 Jesse Young 2015-11-16 17:23:20 UTC
The account I'm using to start the RDP session is the same as the account that the build service host is running as. On the same machine with the latest stable version of Xamarin the same build definition succeeds.
Comment 8 Adrian Alonso 2015-11-19 09:39:22 UTC
Jesse: When you say "building while connected via a RDP session to the TFS build agent, the same project builds just fine" it means that:

1- You queue a build and it succeeds?
2- You execute the build from VS or cmd-line?
3- Queuing a build while you're connected via RDP also fails, right?

I'm trying to reproduce the issue on my side. I should have some news later today hopefully.

Thanks,
Adrian
Comment 9 Jesse Young 2015-11-19 10:11:10 UTC
Queuing a build via TFS while connected via RDP also fails, however building in Visual Studio as well as building via command line function just fine while in an RDP session on the server.
Comment 10 Chase 2015-11-20 16:59:07 UTC
Seeing similar behavior queuing a build from TeamCity.

Running the command below works fine from Terminal, but results in a licensing error when executed from a build script.

"/Applications/Xamarin Studio.app/Contents/MacOS/mdtool" -v build -t:Build "--configuration:Release|iPhone" HHMobile.sln -p:HHMobile.Container.MT

I'm running the command in Terminal as the same user that the build agent is using.

Reverting to Xamarin Studio 5.9.8.0 and Xamarin.iOS 9.1.0.31 gets rid of the error.
Comment 12 Adrian Alonso 2015-11-23 22:10:17 UTC
@Jesse: Could you please also try to Log Out/Log In with your Xamarin account in the machine where the TFS is running? Please also make sure to do it being logged-in with the same windows user than the TFS Build Agent is running as. Thanks, Adrian
Comment 13 Jesse Young 2015-11-24 12:32:29 UTC
Logged out of the Xamarin account via Visual studio and re-signed back in and am still seeing the issues.
Comment 15 Adrian Alonso 2015-11-25 14:27:39 UTC
@Jesse: Could you please try to create an empty iOS app and a build definition for it? And also use diagnostics output verbosity for the build. Thanks, Adrian
Comment 17 Jesse Young 2015-12-03 15:43:00 UTC
Sorry for the delay, been trying to track this one down on my end.

I updated Xamarin to the latest build (Service Release 0) and I created an empty iOS app, created a build for it and lo and behold the build succeeded just fine.

I went back and tested my previous Xamarin forms app (the one I created to repro this bug and initially) this was still not working but after removing the android project from the solution the project built just fine. However, re-adding the Droid project did not cause the build to fail again.... perplexing.

The issues still plagues the app that I was originally trying to fix though. Not sure if I want to upload the full diagnostics from that build, but it looks like it's consistently failing when calling the "DetectSdkLocations" in Xamarin.iOS.Tasks.dll.
Comment 18 Adrian Alonso 2015-12-03 17:47:10 UTC
It's very weird the behavior you're describing. And are you saying that you're not getting the "Building from the command-line requires a Business license." error with the original app? Could you please at least paste the error that you're now getting?

Thanks,
Adrian
Comment 19 Jesse Young 2015-12-03 18:03:07 UTC
Sorry, I've got 3 apps here that I've used to test and repro this.

1. The production app that I'm building
 - This app is still seeing the same "Building from the command-line requires a Business license."
2. A test Xamarin.Forms app that I built to repro this issue
 - This is no longer seeing issues and is building successfully
 - This is the project I originally submitted this bug with
3. A test Xamarin.iOS app that I built based on what you asked in comment 15
 - This worked immediately when I created it
Comment 20 Adrian Alonso 2015-12-03 18:07:22 UTC
What if you try to build only the iOS project for 1)? Can you try that?
Comment 21 Jon Goldberger [MSFT] 2015-12-03 18:09:38 UTC
Possibly related bug #36181
Comment 22 Jesse Young 2015-12-03 18:29:13 UTC
I removed the android project from solution 1 and it still fails with same error.
Comment 23 Ian 2015-12-04 15:42:25 UTC
We are having exactly the same issue,bug #36181, it appears to be to do with the communication layer not starting (or being lost after the first project has been built). The communication within Visual studio itself appears to fail occasionally on a Mac Pro within a Parallels Windows VM, so loss of communication between separate machines is probably more likely.

Is there a command line option to force the communication layer to spin up, that can be placed in the TFS pre build option? The use of /p:ServerAddress=10.128.103.80 /p:ServerUser=Admin /p:ServerPassword=XXXXXXXXXXXXX causes the business licence required message.
Comment 24 Jon Goldberger [MSFT] 2015-12-04 21:26:26 UTC
*** Bug 36181 has been marked as a duplicate of this bug. ***
Comment 25 Ace Olszowka 2015-12-10 22:04:55 UTC
We found what Ian pretty much found; I've duplicated my comment on the attached bug below:

We're duping it over here too when we're invoking from CruiseControl.NET and our MSBuild script didn't occur until the latest roll.

The problem appears to be that they've made several changes to the _SayHello target (located in Xamarin.iOS.Windows.After.targets, in the normal install location of C:\Program Files (x86)\MSBuild\Xamarin\iOS).

When this update occurred the developer neglected to properly initialize the following variables from within the msbuild script:

$(ServerPort)
$(ServerAddress)
$(ServerUser)
$(ServerPassword)
$(ServerKeychainPassword)
$(GenerateCache)
$(ContinueOnDisconnected)
$(BuildingInsideVisualStudio)

These variables are set when this process is run via Visual Studio. The developer probably did not test running outside of the Visual Studio environment, and thus did not catch the issue.

The question becomes which of these are critical to the operation of this task? Looking at the Task none of these properties are defaulted, thus we'll assume that we need all of them.

First let’s start with features that have been added, the $(ContinueOnDisconnected) appears to be a new and useful property, if the SayHello Task (which is responsible for communicating with the Mac Build Server) fails for any reason this is the value returned, thus setting this to false will ensure that our builds don't attempt to continue on if we can't get to the build server. This is a great addition, and everyone invoking their projects via MSBuild should set this to false so you fail fast.

Next let’s take a look at the $(ServerAddress), this is pretty straight forward, this as you would expect should be set to the address of the mac build server. 

Now we should look at $(ServerPort), unfortunately we don’t get too many clues on what this should be, however it looks like this is defaulted to port 22 (SSH) which would make sense as the “new” remote build host seems to be implemented over SSH. Additionally, the seemly unrelated $(BuildingInsideVisualStudio) also plays into this, you are not allowed to repoint the Port if it is set to false.

Next we should look at the $(ServerUser) property, we can gather based on the fact that this is using SSH it probably should be the user we’ve setup to be our build host as per their documentation, low and behold that seems to work.

Next is $(ServerPassword) and $(ServerKeychainPassword) I’d hate to send these in the clear, so I tried testing without them, much to my surprise it seemed to work! The question is how is this possible? As far as I can tell this should have fallen right over, I’d find it hard to believe that it’d allow me to connect without any type of password, the only thing I can think of is perhaps they are using some ssh key-based login that is squirrelled off somewhere (probably setup when you first use the Visual Studio GUI to perform the pairing to the mac build host). $(GenerateCache) also did not seem to have any affect.

On the plus side it looks like a long standing bug (the one where the IPA was not copied back when building via MSBuild) has been fixed! Rejoice my fellow Build Masters, you can rid yourselves of the pscp hacks to pull back from the ~/Library/Caches/Xamarin/mtbs/builds/AppiOS/<BuildSessionID>/bin/iPhone/Ad-Hoc/<IPAName>

It is interesting to note that you must still be logged into the Mac Build server, failure to do so yields these warnings (and fails if you’ve got ContinueOnDisconnected set to false):
(_SayHello target) -> 
  C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets(54,5): warning : Failed to execute 'ls /usr/bin/mono': ExitStatus=1 [C:\Build\App.iOS.csproj]
  C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets(54,5): warning : ls: /usr/bin/mono: No such file or directory [C:\Build\App.iOS.csproj]
  C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets(54,5): warning : Failed to execute 'ls /usr/bin/mono': ExitStatus=1 [C:\Build\App.iOS.csproj]
  C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets(54,5): warning : ls: /usr/bin/mono: No such file or directory [C:\Build\App.iOS.csproj]
  C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets(54,5): warning : Failed to execute 'launchctl load -S Aqua /tmp/com.xamarin.build.940960d8/app.plist': ExitStatus=112 [C:\Build\App.iOS.csproj]
  C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets(54,5): warning : Could not find domain for  [C:\Build\App.iOS.csproj]
  C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets(54,5): warning : The user 'YourUsername' must be logged in on the mac in order to start the agent. Please make sure the user 'YourUsername' is logged in and try to connect to the mac again. [C:\Build\App.iOS.csproj]C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets(54,5): warning :  [C:\Build\App.iOS.csproj]
  C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets(54,5): warning : The user 'YourUsername' must be logged in on the mac in order to start the agent. Please make sure the user 'YourUsername' is logged in and try to connect to the mac again. [C:\Build\App.iOS.csproj]

Tl;dr; Ensure that your remote user is logged on to the mac build server and set the following msbuild properties to their correct settings: 
$(ContinueOnDisconnected) = false
$(BuildingInsideVisualStudio) = false
$(ServerAddress) = Mac Build Server
$(ServerUser) = Username of user on mac build server
Nothing else seems to matter. Long standing bug involving IPA not getting copied back also fixed.
Comment 26 Ben Beckley 2015-12-15 21:21:02 UTC
Thank you all for the thorough and well composed comments. I am bumping this to the C6SR2 milestone where it will continue to be tracked and investigated.
Comment 27 Jesse Young 2015-12-16 21:57:14 UTC
Been racking my brains against this one for some time and finally found a good repro. I have a "Class Library (iOS)" project in my solution, when this project is set to build for that configuration in triggers the issue. 

Updated repro steps.

1. Create Blank Solution
2. Add new "Blank App (iPhone)" project to solution
3. Add new "Class Library (iOS)" project to solution
4. In the "Blank App (iPhone)" project add a reference to the class library
5. In the solution configuration manager, change active solution configuration to "Ad-Hoc" and active solution platform to "iPhone" and check the box to build the class library you created.
6. Check into TFS, create build, execute build.
Comment 29 Jesse Young 2016-04-05 22:26:05 UTC
4.0.3.214 resolved this. I believe it had something to do with the changes to the licensing models.

Go ahead and close this.
Comment 30 Jose Gallardo 2016-04-11 17:23:49 UTC
Fixed with licensing changes. Thanks for the update!
Comment 31 Shruti 2016-05-19 05:36:24 UTC
As per comment(29) and (30), I am closing this issue.