Internal compiler works, external compiler fails on initiating JavaBuildPreflight

Elements
1

build_report_detailed.txt (36.6 KB)
My build works great using internal Elements (with Fire). Just installed Mono and External Elements for use on CI server. Compiling a short Hello World example using mono from the command line works. I’ve installed the latest stable release of Elements for both internal and external compilers. It is a silver (swift) project.

Here’s the short version. The more detailed build report is attached, but I think this contains the important stuff.

xbuild /var/folders/2f/nsp668zj7ws96k_tcr8mbdm40000gn/T/com.lukedbartolomeo.flashnotederby.fire.temp.sln /nologo /target:Build /verbosity:normal /property:Configuration=Debug /toolsversion:4.0

Build started 5/8/2017 12:53:20 PM.

Project “/var/folders/2f/nsp668zj7ws96k_tcr8mbdm40000gn/T/com.lukedbartolomeo.flashnotederby.fire.temp.sln” (Build target(s)):
Target ValidateSolutionConfiguration:
Building solution configuration “Debug|AnyCPU”.
Target Build:
Project “/Users/hacky/Dev/flashnote android/com.lukedbartolomeo.flashnotederby.elements” (default target(s)):
Target CooperPreflight:
: error : Error initializing task JavaBuildPreflight: Could not load file or assembly ‘RemObjects.Oxygene’ or one of its dependencies
File name: ‘RemObjects.Oxygene’
at System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity) [0x00088] in :0
at (wrapper remoting-invoke-with-check) System.AppDomain:Load (System.Reflection.AssemblyName,System.Security.Policy.Evidence)
at System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef) [0x00000] in :0
at (wrapper remoting-invoke-with-check) System.AppDomain:Load (System.Reflection.AssemblyName)
at System.Reflection.Assembly.Load (System.Reflection.AssemblyName assemblyRef) [0x00005] in :0
at Microsoft.Build.BuildEngine.TaskDatabase.RegisterTask (System.String classname, Mono.XBuild.Framework.AssemblyLoadInfo assemblyLoadInfo) [0x0003b] in :0
at Microsoft.Build.BuildEngine.UsingTask.Load (Microsoft.Build.BuildEngine.TaskDatabase db) [0x000e1] in :0
at Microsoft.Build.BuildEngine.TaskDatabase.GetTypeFromClassName (System.String classname) [0x000d5] in :0
at Microsoft.Build.BuildEngine.BuildTask.get_Type () [0x00016] in :0
at Microsoft.Build.BuildEngine.BuildTask.InitializeTask () [0x00000] in :0
at Microsoft.Build.BuildEngine.BuildTask.Execute () [0x00006] in :0
Build FAILED.
Errors:
/var/folders/2f/nsp668zj7ws96k_tcr8mbdm40000gn/T/com.lukedbartolomeo.flashnotederby.fire.temp.sln (Build) ->
(Build target) ->
/Users/hacky/Dev/flashnote android/com.lukedbartolomeo.flashnotederby.elements (default targets) ->
/Library/Frameworks/Mono.framework/External/xbuild/RemObjects Software/Elements/RemObjects.Elements.Cooper.Common.targets (CooperPreflight target) ->
: error : Error initializing task JavaBuildPreflight: Could not load file or assembly ‘RemObjects.Oxygene’ or one of its dependencies
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.7019810

Thanks to anyone who can help point me in the right direction.

2

This sounds like the external compiler isn’t installed properly. Did you install it via install.sh? What output do you get if you run gacutil -l RemObjects.Oxygene in Terminal? And can you set Build Log Verbosity to “Extreme” and send me the full log — it should emit debug info from Mono why it can’t find the dll.

—marc

3

Thanks for the prompt response!

The Mono installer installed Mono to /Library/Frameworks (using standard installation) which was not in my $PATH. When I ran install.sh, it didn’t fail, but it obviously couldn’t complete the installation 100%.

After adding “/Library/Frameworks/Mono.framework/Versions/Current/bin/” to my $PATH and re-running install.sh, it looks like everything is working fine!

4

curious. so after installing Mono, you could not run mono or gacutil from Terminal out of the box? What version of Mono did you install? Afair, the Mono installer always set this up properly for me, but if they changed that, say, recently, i’d wanna update our script to handle that better…