Context: https://travis-ci.org/mono/Embeddinator-4000/jobs/471012684
Context: https://travis-ci.org/mono/Embeddinator-4000/jobs/471026456
Context: https://travis-ci.org/mono/Embeddinator-4000/jobs/471037351
First issue we are hitting is a missing version of Cake on MyGet:
Unable to find version '0.23.0' of package 'Cake'.
https://www.myget.org/F/cake/api/v3/index.json: Package 'Cake.0.23.0' is not found on source 'https://www.myget.org/F/cake/api/v3/index.json'.
To fix this:
- Let's remove `MyGet.config` and just use NuGet
- Update Cake to 0.31, I recently used that version on another project
Next issue is that the build will not work using JDK 10:
Compiling binding code...
Invoking: /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home
Invoking: /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/bin/javac
...
Fatal Error: Unable to find package java.lang in classpath or bootclasspath
To fix this we should use the `-v 1.8` switch on every call to `java_home`.
Next issue is that we aren't specifying a version with the `#tool`
directive:
The 'tool' directive is attempting to install the 'NUnit.ConsoleRunner' package
without specifying a package version number.
After that we were hitting issues where Xamarin.iOS\Mac\Mono were having trouble being provisioned, so I bumped them all to current stable.
Then a few test fixes, including some from https://github.com/mono/Embeddinator-4000/pull/714 originally.
This fixes Jenkins and part fixes the other builds. @jonathanpeppers will look at those later
Context: https://help.github.com/articles/dealing-with-line-endings/
If you work on this repo on Windows, you quickly see the `.gitattributes` are not setup right for development on Windows.
1. Certain files had mixed line endings, which causes Visual Studio to prompt to adjust.
2. Running `premake` yields Windows line endings on Windows, and so every `*.csproj` file appears to have changes.
`xamarin-android` has a well-used `.gitattributes` file, so I used it as a starting point and added an entry for `*.cake` files.
The way it works (as I understand it):
- `git` stores everything with unix line endings
- on checkout, clients convert the line endings according to settings in the `.gitattributes` file
So, for example:
- All `*.csproj` files will have Windows line endings, as Visual Studio expects (both Mac and Windows)
- `*.cs` files will have Windows line endings on Windows, and unix line endings on Mac
- `Download-Xamarin-Android` needs to "copy" from temp, since the bots have temp in `D:\` and you can't do a "move" operation across drives
- Added a `Jenkins` cake target to replace `AppVeyor`
- Switch to Android API Level 26 and `TargetFrameworkVersion` v8.0 by default. Jenkins PR bots did not have an option to provision API 24.
- Updated to Android Support Libs 26.x
Changes for latest Android Studio + Windows
- Updated `.gitignore`
- Removed files we don't need to check into source control
- Changed option for max heap size that was erroring on Windows
- Use `--stacktrace` option when running gradle, so we get error messages
- Updated Android test project to API 26, and support lib 26.x
TODO in future PRs:
- Drop everything that says "AppVeyor"
- Restored: partial missing of extension support + bitcode enabling for iOS
- Fix quoting issue somewhat unrelated to original PR
- [cake] Use DeleteDirectories to work around cake bug https://github.com/cake-build/cake/issues/2135
This is not optimal, since an `NSArray` of enums can't be done
without turning everything into `NSNumber`.
However the current code does not compile and that's worse that
an suboptimal API.
Fix https://github.com/mono/Embeddinator-4000/issues/561
Test projects failing to build on Linux on TravisCI, perhaps this will
fix it? This seems to be happening since #616, but I think it is a change on
the TravisCI build bots.
Changes:
- FSharp Android project shouldn't have `AndroidUseLatestPlatformSdk` on
- We don't need System.ValueTuple
- The `Build-C-Tests` Cake task should also copy `FSharp.Core.dll` as using
the system one doesn't seem to be working reliably on TravisCI
Fixes#582
- Added a test case to repro #582
- Improved upon `System.CodeDom` logic, to use more specific type names
via `CodeTypeReference` instead of strings
- no longer need `using System;`
- Improved upon the number of assemblies that `Resource.designer.dll`
references. We only need to reference input assemblies that contain
`Resource` classes generated by Xamarin.Android.
- Updated approval tests to match the new generated code
As reported in #530, there are some cases where libraries use
`MonoPackageManager.setContext`, which has a “vestigial”
implementation/comment in Xamarin.Android.
I added this method and a couple quick tests for future validation.