Context: https://issuetracker.google.com/issues/68753324
The Windows' SDK tools v26 `lint.bat` tool installed to
`$(AndroidToolchainDirectory)\sdk\tools\bin` appears to be broken, so
a all tests which use it are failing.
This can be worked around -- allowing the `lint`-based tests to pass
on Windows -- by setting the `%JAVA_OPTS%` environment variable.
Hopefully this is a temporary workaround until a new version of the
SDK tools comes out that fixes this issue.
One other thing to note here is that the Android SDK installed by
Visual Studio uses the SDK tools version 25.x, which does not appear
to have this issue on windows.
Context: https://github.com/Microsoft/msbuild/blob/master/src/Shared/BuildEnvironmentHelper.cs#L511
`xabuild.exe` did not support building .NET standard projects. It turns
out a `$MSBuildSDKPaths` environment variable needed to be set for locating
the `Sdks` directory. On Windows, this path is relative to Visual Studio /
MSBuild, but on Mac I had to hardcode the path to .NET Core. It seems to
use the same path on Linux as well.
Context: https://github.com/mono/mono/pull/5925
Mono's IL interpreter will be enabled by default in mono once the
above PR merged. Xamarin.Android doesn't need an IL interpreter --
we have a JIT! -- so disable the interpreter so that it doesn't
impact the size of `libmonosgen-2.0.so`.
This method was not using the full path to the project directory, and so
it wasn't actually deleting anything. This caused test failures on
Windows in tests such as `ManifestTest.Bug12935`. This particular test
was modifying the contents of `AndroidManifest.xml`, and checking the
results of the build afterward. Since the project files were not
deleted, changes to the `AndroidManifest.xml` were not getting written
to disk during the test.
Context: 806082f26b
`generator` will extract method parameter name information from a
variety of sources, including JavaDoc documentation -- via
`$(JavaDocPaths)`, `$(JavaDoc7Paths)`, `$(JavaDoc8Paths)`,
`$(DroidDocPaths)`, and `@(JavaDocJar)` (after extracting the `.jar`
file) -- all in an effort to avoid the default parameter names of
`p0`, `p1`, etc.
Java.Interop@806082f2 updated `generator` so that it would *also*
extract method parameter name information from `api.xml`-formatted
XML files:
```xml
<api>
<package name="my.example">
<class name="MyType">
<method name="myMethod" returns="void">
<parameter name="value" type="java.lang.String" />
<!-- ... -->
```
What's desired is a way to provide an `api.xml`-formatted file to the
`<ClassParse/>` task so that the generated `api.xml` contains the
desired parameter names.
Remove the `ClassParse.JavaDocPaths`, `ClassParse.Java7DocPaths`,
`ClassParse.Java8DocPaths`, `ClassParse.DroidDocPaths`, and
`ClassParse.JavaDocs` properties, replacing them with a new
`ClassParse.DocumentationPaths` property, and pass *all* of the old
values *alongside* `@(JavaDocIndex)` for
`ClassParse.DocumentationPaths`.
Thus, to manually specify method parameter names via an
`api.xml`-formatted file:
1. Add the file to the `.csproj`, and
2. Set the **Build action** to `@(JavaDocIndex)`
The `api.xml`-formatted file will then be provided to `<ClassParse>`,
and the desired names will be used in generated code.
*Note*: `@(JavaDocIndex)` is *only* supported when
`$(AndroidClassParser)` is set to `class-parse`. It cannot be
used with the older `jar2xml` parser, and attempting to do so will
result in an error of some sort. (No idea what it is, we haven't
tested this scenario to see what the error will be.)
`obj/Debug/Profile.g.cs` is getting regenerated on every build,
forcing `Xamarin.Android.Build.Tasks.csproj` to rebuild *every* time.
It looks like the `IncrementalClean` target is the culprit, in that
it deleted `obj/Debug/Profile.g.cs` file after the build completed.
The fix here is to add the *absolute path* of `Profile.g.cs` to
`@(FileWrites)`. (Non-absolute paths still result in the
`IncrementalClean` target removing the file.)
Update `$(_GenerateProfileClass)` so that it's an absolute path.
Added `NUnit.results` label to the default time performance definition
file. It matches NUnit line with results, which is printed out at the
end of the NUnit driven test.
This will add `NUnit.results-$(Configuration)` columns to the `Bcl`,
`Jcw`, `Locale`, and `Runtime merged` plots at:
https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/plot/Tests%20times/
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=60444
We should NOT ever pass a `//uses-sdk/@android:minSdkVersion` value
that is greater than the `//uses-sdk/@android:maxSdkVersion` value.
It results in the following error:
Min API Level (10) > max API Level (8)
We should check the values and use the minimum value for
`//uses-sdk/@android:minSdkVersion`.
Commit 855ad009 added logic to detect if a test had a native crash and to
retry the test. There was a flaw in the logic such that it would
run every test twice...
Fix that.
Other Android projects (such as test APKs), set `$(TargetFrameworkVersion)`
by importing `Configuration.props` and using `$(AndroidFrameworkVersion)`.
`$(AndroidUseLatestPlatformSdk)` should also be set to `false`.
Not sure why this hasn't caused any issues yet, I first noticed this
causing a failure on PR #997.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=60473
In the case when the URL doesn't contain any query elements we
optimized for speed and memory by not using `UrlBuilder` to do the
encoding work on the URL. However, it causes problems with URLs
that are sent pre-encoded.
Remove the optimization and rely on `UrlBuilder` in all cases.
Turns out `lint.bat` does not always return a version number.
It returns stuff like
lint: version unknown
lint: unknown version
not very helpful. So we need to handle that case and return a
empty verison.
Rather than trying to ALWAYS unset the ReadOnly flag, lets only
do it if the directory is read only. Also use `EnumerateFiles()`
rather than `GetFiles()` to get the `.jar` files.
`EnumerateFiles()` is more efficient.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=60324
If an `android.jar` file does *not* exist for a target platform we
should raise a normal error. Instead we throw a
`NullReferenceException`.
…/xamarin-android/bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Common.targets: error : Error executing task GetJavaPlatformJar: Value cannot be null.
Parameter name: path1
Error executing task GetJavaPlatformJar: System.ArgumentNullException: Value cannot be null.
Parameter name: path1
at System.IO.Path.Combine (System.String path1, System.String path2) [0x00003] in <4656b2b94f914437bce672312dd9e44b>:0
at Xamarin.Android.Tasks.GetJavaPlatformJar.Execute () [0x00188] in <3fa51b5c8b554c02b4c7f549bcabde77>:0
at Microsoft.Build.BuildEngine.TaskEngine.Execute () [0x00000] in <cbad9a49d2cc4e87ad2241615dd4666c>:0
at Microsoft.Build.BuildEngine.BuildTask.Execute () [0x0008d] in <cbad9a49d2cc4e87ad2241615dd4666c>:0
Oops.
The cause is that
`AndroidSdkInfo.TryGetPlatformDirectoryFromApiLevel()` can return
`null`, which is by design. We need to handle that in the places
where it's called, and provide an XA5207 error message when
`TryGetPlatformDirectoryFromApiLevel()` returns `null`.
Use mono's `external/linker` submodule reference instead of including
our own, separate, `linker` submodule reference.
This way we are more consistent with xamarin-macios, which also uses
mono's linker submodule.
Sometimes when running `Xamarin.Android.Build.Tests`, mono crashes:
Stacktrace:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) object.__icall_wrapper_mono_gc_alloc_obj (intptr,intptr) [0x00000] in <4fdc5ed61a074cafb49fa42deb20d521>:0
at (wrapper alloc) object.AllocSmall (intptr,intptr) <0x000fa>
at System.IO.FileSystemEnumerableIterator`1<TSource_REF>.CreateSearchResult (System.IO.Directory/SearchData,Microsoft.Win32.Win32Native/WIN32_FIND_DATA) [0x00023] in <4fdc5ed61a074cafb49fa42deb20d521>:0
# Actual stack trace doesn't *really* matter, and is basically random
...
Native stacktrace:
0 mono 0x000000010d9df481 mono_handle_native_crash + 257
...
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
This is decidedly Not Good™.
However, a significant percent of the time, the crash *also* isn't
reproducible: a re-run of the build+tests will result in all tests
passing. However, a re-run can take upwards of 2-6 *hours* --
depending mostly on whether the PR has a mono bump -- so it is
undesirable to re-run builds just to see if it's a "random" error.
Instead, update `Builder.BuildInternal()` so that if it determines
that mono crashed -- via the `Got a SIGSEGV…` message -- then we'll
re-try the crashing command. (Just once!)
This should hopefully reduce the number of test failures we need
to investigate.
The *downside* is that the #runtime team would dearly love to know
about these crashes, so *they* can investigate. This is *partially*
supported by emitting the following message into the build output
when a native crash is detected:
Native crash detected! Running the build for … again.
This is less than ideal, and may be improved in the future.
If the build fails we get a generic message to look at the
`build.log`. This is a pain because the build log is HUGE! and takes
ages to find the problem.
It seems NUnit does not include the `FailedBuildException.BuildLog`
property. Override the `Exception.StackTrace` property to include the
`FailedBuildException.BuildLog` data.
On Windows after formatting my machine (don't ask),
`PrepareWindows.targets` was failing with:
System.InvalidOperationException: Could not determine Android SDK location.
Looking into it, there appear to be two things wrong:
* `PrepareWindows.targets` should import `Configuration.props`
* The incoming properties are `$(AndroidSdkDirectory)` and
`$(AndroidNdkDirectory)` not `$(AndroidSdkPath)` and
`$(AndroidNdkPath)`.
I'm not quite sure how this *ever* worked, unless `AndroidSdkInfo`
was able to find *some* Android SDK on your machine, e.g. from a
prior Xamarin install.
I have been told that the `prepare-image-dependencies.sh` script
should also install `mono`, to ensure that the required mono exists.
Add a `@PKG_URLS@` variable to `prepare-image-dependencies.sh.in` to
support downloading and installing our minimum specified mono version.
Additionally, I discovered that `xbuild` bugs are still around; I just
keep forgetting their specifics. Case in point:
[Jenkins build #712][xa712] uploaded
[`prepare-image-dependencies.sh`][sh], and it's not good:
[xa712]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/
[sh]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/712/Azure/processDownloadRequest/xamarin-android/prepare-image-dependencies.shhttps://dl.google.com/android/repository/build-tools_r26.0.1-macosx.zip sdk/build-tools\$(XABuildToolsFolder)
...
https://dl.google.com/android/repository/android-15_r03.zip sdk/platforms\android-15
MSBuild properties contained within item metadata -- specifically
`%(AndroidSdkItem.DestDir)` -- aren't fully expanded, resulting in the
above value of `$(XABuildToolsFolder)`, which *should* be `26.0.1`.
Similarly, some install paths are using `\` (backslash) when they
should contain `/` (forward slash).
Jenkins has been updated to explicitly use `msbuild`:
$ make prepare-image-dependencies MSBUILD=msbuild
However, `\r` characters now appear in
`prepare-image-dependencies.sh`. Fix this by having the
`PrepareImageDependencies` target emit the MSBuild-generated file into
an intermediate file, then fix it up using **tr**(1).
Finally, correct the `brew install` command so that any errors are
ignored, for if a brew package is already installed, re-installing it
will result in an error.
Context: https://github.com/xamarin/xamarin-android/blob/master/tools/scripts/xabuild#L105
`xabuild`, the shell script, has some logic to set MSBuild properties
for `AndroidSdkDirectory` and `AndroidNdkDirectory`. The issue here is
on Windows, `xabuild.exe` is not invoked from this shell script. So we
need to replicate the logic in C# in `xabuild.exe`, but not break what
was fixed in #977.
Changes:
* Check for `ANDROID_SDK_PATH` or `ANDROID_NDK_PATH` environment
variables
* Run `Paths.targets` via a new MSBuild process, the same way as
`tools/scripts/xabuild`
* Set the `AndroidSdkDirectory` and `AndroidNdkDirectory`
properties in the config file if they are not blank
* `AndroidSdkDirectory` and `AndroidNdkDirectory` can still be
overridden by a user, because incoming values supersede what is
found in the config file
The `BuildAppCheckDebugSymbols()` test does not take into account
that when building in debug mode on monodroid the assemblies
are not embedded in the apk. As a result when trying to get
`Library1.pdb` from the apk we get a `null` back. This causes
a `NullReferenceException` when we try to get a length.
The fix is to look in the `assets` directory if we can't get
the file from the `.apk`. This will allow the test to work in
both xamarin-android and monodroid.
We are investigating building Xamarin.Android atop
Visual Studio Team System (VSTS) in addition to our current Jenkins
setup, and one of the issues we're running into is "bootstrapping":
VSTS is configured to create a "fresh" VM for each build.
**Pro**: It should allow builds to be more reliable, as previous build
artifacts won't be present, and thus won't cause/hide errors.
**Con**: *Previous build artifacts are not present*. Previous build
artifacts such as *downloading and extracting* the Android NDK & SDK,
using `brew` to install dependencies, building MXE...
Ensuring that the dependencies are installed through `make prepare`
can be quite time consuming. What we want is a way to ensure that the
"build image" -- *what's already installed* when the VM boots --
contains all of our desired dependencies.
Furthermore, we *don't* want to have the responsible parties checkout
and build xamarin-android in order to determine what the dependencies
should be.
Attempt to square this circle by adding a new
`make prepare-image-dependencies` target, which processes
`@(AndroidSdkItem)`, `@(AndroidNdkItem)`, `@(AntItem)`, and
`@(RequiredProgram)` to create a `prepare-image-dependencies.sh`
script which will download and install the required dependencies.
The generated shell script does *not* take the state of the machine
running `make prepare-image-dependencies` into consideration. This
allows the target to be executed on one machine, and the output run
on another.
$ make prepare-image-dependencies
# creates `prepare-image-dependencies.sh`
*Note*: `make prepare-image-dependencies` does not currently deal
with MXE. (Building MXE on the VSTS VM is *very* time consuming, so
it's something we need to take care of. It is not *yet* dealt with.)
Fixes: https://devdiv.visualstudio.com/DevDiv/XamarinVS/_queries?id=512752%2F&triage=true&_a=edit
The DesignTime build is generally run before any nuget packages
have been restored. As a result we end up with empty cache files.
Because those files exist and are considered uptodate, when the
main build finally happens they are not re-generated.
This causes errors like
error: Error: No resource found that matches the given name: attr 'colorAccent'.
on a new default template.
The DesignTime build should have its own set of cache files which
do not conflict with the main build. This way when the main build
runs the cache files will not be in place.
FixesL https://bugzilla.xamarin.com/show_bug.cgi?id=60080
In a previous attempt to fix an intellisense build (1cd582ec) we
caused this issue. The DesignTime build does NOT like our AsyncTask
as it locks the IDE.
This commit puts the old code back in place which skips the task
if we are in DesignTime mode. But so we can easily test it, we
emit an message that our test can pick up to ensure we are doing
the correct thing. Without the message we have no way of knowing
if the task is skipped.
Commit 8643ded9 tried to make sure `xbuild` worked like `msbuild`
when it came to `'$(DebugType)' == 'None'`. The "fix" however
was not correct.
When `$(DebugType)` is `None` under `msbuild`, it changes to
`portable` and `$(DebugSymbols)` gets set to `true`. Additionally,
when `$(DebugType)` is *empty* it gets set to `portable` but then
`$(DebugSymbols)` is left alone.
So we need to get `xbuild` to do the same. Otherwise we get the
wrong runtimes. But by the time we get to
`Xamarin.Android.Common.targets` it is too late to change the
`$(DebugSymbols)` value: `xbuild` does not use the changes.
So we need to do this before `xbuild` gets a chance to set the
value of `$(DebugSymbols)`.
The trick is to alter the properties in
`Xamarin.Android.CSharp.targets` and
`Xamarin.Android.FSharp.targets` *before* we `<Import/>`
`Microsoft.*.targets`.
On jenkins is appears we are getting a situation where we
are picking up an empty directory for the FrameworkPath.
As a result we always get 0 when trying to pick up the
runtime that are available. So tests which check the runtimes
fail.
This commit adds a check for a 'libmono-android.release.so' file
so can ensure the required files exist in the folder. Also added
code to pick up the `CONFIGURATION` environment variable from
the Makefile.
The `dl.` CDN has more backends than `dl-ssl.` and is generally faster.
Also, change ant download to use HTTPS (in preparation for the world where plain
http is gone :P)
Context: https://github.com/nunit/nunit/releases/tag/3.7.1
Context: commit 6687dac5
The release notes for NUnit 3.7.1 mention a hang with parallelized
tests, so it is worth a try to see if updating fixes it the hangs
that we experienced and tried to workaround in 6687dac.
Attempt to quasi-"optimize" `Builder.BuildInternal()`: if we're going
to read `buildLogFullPath` a line at a time *anyway* -- to collect
the log file for later parsing into `Builder.LastBuildOutput` -- then
we should also do any associated line-oriented parsing as well.
Update `buildLogFullPath` processing to use a `StringBuilder` instead
of string concatenation, and search for the `Time Elapsed` message
while reading the file, instead of separately, *after* having read
the entire build log into memory.
Commit 8643ded9 added support for running the tests in `msbuild`.
Part of that change was altering the behaviour of `xbuild` to
match that of `msbuild`, regarding the way they handle
`$(DebugType) == "None"`.
The commit altered `Xamarin.Android.Common.targets` to reset
`$(DebugType)` to `portable` if `None` is detected. It also resets
`$(DebugSymbols)` to `false` in the same senario.
As a result the code these some tests which do the same thing
should not longer be required. Remove this redundant code.
The introduction of `xabuild` in commit f9d15dd2 omitted a design
requirement: `xabuild` needs to be runnable on a machine which does
*does not* have a xamarin-android build environment. The idea is that
e.g. Windows developers could download a Jenkins-built
`oss-xamarin.android*.zip` file, extract it, and run
`bin\Debug\bin\xabuild.exe` to use the extract artifacts *without*
requiring system-wide installation via `setup-windows.exe`.
This not-very-well-stated requirement brought along two mistakes:
1. `xabuild.exe` should *not* set the `$(AndroidSdkDirectory)` and
`$(AndroidNdkDirectory)` MSBuild properties. It *can't*; it could
be executed on ~any machine, in particular one which hasn't built
xamarin-android, so setting these properties to "build-tree"
values doesn't make sense and will fail.
2. Even if (1) weren't the case, commit f9d15dd2 still allowed the
`Xamarin.Android.Build.Tests` unit tests to use `xbuild` as the
MSBuild engine, via the `tools/scripts/xabuild` script.
This script *does not* always set `$(AndroidSdkDirectory)` or
`$(AndroidNdkDirectory)`.
As a result of (2), many unit tests *fail*:
Error executing task ResolveSdks: System.InvalidOperationException: Could not determine Android SDK location. Please provide `androidSdkPath`.
at Xamarin.Android.Tools.AndroidSdkInfo..ctor (System.Action`2[T1,T2] logger, System.String androidSdkPath, System.String androidNdkPath, System.String javaSdkPath) [0x0008e] in …/xamarin-android/external/xamarin-android-tools/src/Xamarin.Android.Tools.AndroidSdk/AndroidSdkInfo.cs:28
at Xamarin.Android.Tasks.MonoAndroidHelper.RefreshAndroidSdk (System.String sdkPath, System.String ndkPath, System.String javaPath) [0x00021] in …/xamarin-android/src/Xamarin.Android.Build.Tasks/Utilities/MonoAndroidHelper.cs:111
at Xamarin.Android.Tasks.ResolveSdks.RunTask () [0x001a0] in …/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/ResolveSdksTask.cs:157
at Xamarin.Android.Tasks.ResolveSdks.Execute () [0x00002] in …/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/ResolveSdksTask.cs:130
at Microsoft.Build.BuildEngine.TaskEngine.Execute () [0x00000] in …/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/TaskEngine.cs:134
at Microsoft.Build.BuildEngine.BuildTask.Execute () [0x0008d] in …/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/BuildTask.cs:101
Update `xabuild` to *never* explicitly set `$(AndroidSdkDirectory)`
and `$(AndroidNdkDirectory)`, and update `Xamarin.Android.Build.Tests`
to *always* explicitly provide these MSBuild properties. This allows
unit test execution to be more reliable, and will prevent
`xabuild.exe` from looking at "random" non-existent directories.
The `Xamarin.Android.Build.Tests` NUnit tests recently started
hanging after the tests were done.
Run tests with a single worker as a workaround until we figure out
why, unblocking Jenkins.
There are cases in which diagnostic MSBuild output is not including
important information such as `$(MSBuildExtensionsPath)`.
To help debug situations like this, if `MSBuildApp.Main` returns a
non-zero exit code, we can print the contents of xabuild.exe's config
file to the console.
Commit 286b9c28 added extra item to `@(_FilesToRegister)` as part of
the `IncrementalClean` target.
Unfortunately, one of the values omitted the `$`, resulting in an
"invalid" property name reference.
This commit fixes that issue.
Context: 8643ded9
Context: 286b9c28
Context: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/700/testReport/
`Xamarin.ProjectTools` was updated in commit 8643ded9 to use `msbuild`
(via `xabuild`) *by default*, and commit 286b9c28 updated
`Xamarin.ProjectTools` to further use `msbuild`/`xabuild` when the
`$USE_MSBUILD` environment variable is *not* `0`, and to continue
using `xbuild` when `$USE_MSBUILD` is `0`.
Meaning before 8643ded9 `xbuild` was used for
`Xamarin.Android.Build.Tests` execution, and afterward `msbuild`
was used. (This change wasn't explicitly clear to some.)
"Revert" this behavior; use `xbuild` *by default* for
`Xamarin.Android.Build.Tests` execution, by updating the
`RUN_NUNIT_TEST` make `define` so that the `$USE_MSBUILD`
environment variable is exported to the *value of* the
`$(USE_MSBUILD)` make variable, IFF it's not the empty string.
If `$(USE_MSBUILD)` *is* the empty string, export `USE_MSBUILD=0`,
which will cause `xbuild` to be used.
What his means is that a default unit test invocation:
make run-all-tests
will use `xbuild` to run `Xamarin.Android.Build.Tests`. However,
if `msbuild` is *explicitly opted into*, then `msbuild` is used:
$ make run-all-tests MSBUILD=msbuild
# -or-
$ make run-all-tests MSBUILD=some/path/to/msbuild USE_MSBUILD=1
Furthermore, if/when we change the default MSBuild engine to
`msbuild` in the future -- by altering
`build-tools/scripts/msbuild.mk` to set `MSBUILD=msbuild` and
`USE_MSBUILD=1` by default -- then `make run-all-tests` will
*implicitly* follow suit.
With luck, "reverting" to `xbuild` use will allow the
[current `Xamarin.Android.Build.Tests` failures][xa700t] -- all 20 of
them -- to be "fixed" until such time as all
`Xamarin.Android.Build.Tests` tests *actually* pass with `msbuild`.
[xa700t]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/700/testReport/
The test failed locally for me with:
```
…/xamarin-android/bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Common.targets:
error : '…/android-sdk-macosx/build-tools/23.0.0/apksigner' does not exist.
You need to install android-sdk build-tools 26.0.1 or above.
```
which is weird since it's looking into the 23.0.0 build tools which
doesn't have apksigner even though the test specifies build tools 26.0.1.
Turns out the test had a typo, it used `AndroidBuildToolsVersion`
instead of `AndroidSdkBuildToolsVersion` so it fell back to 23.0.0 :)
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=60185
Newer versions of NDK don't include API 4 anymore but two of our tests specified
that they required that particular version to build. This caused the tests to
fail because the android-4 platform path was nowhere to be found.
Bump the minimum SDK version to 9 (which is the lowest platform included in the NDK
as of now)
Sometimes out TimeOut tests fail if the build is a bit slow.
This is because we time the entire process of starting a new
process to bringing in ALL the output data.
So lets parse the build.log and pull our the reported MSBuild
"Time Elapsed" if we can.
There was a spelling mistake in the DesignTime build timing test.
Also it was reporting the wrong time! So this commit fixes that.
It also makes the test `NonParallelizable`, this is because when
its run in parallel with a bunch of other tests the timing is usually
off and the test fails.
There are circumstances when we don't want to use the latest
and greatest version of mono. On the CI servers we will want
to keep to certain versions so that we have a stable build.
But on developer machines we will want to allow the developer
to ignore such checks.
This commit adds support for `$(MonoRequiredMaximumVersion).
By default this proeprty is ignored. But on build systems we should pass:
/p:IgnoreMaxMonoVersion=False
to ensure that the max version is applied and we run against
a stable version of mono.
We need to output the Lint tool Path we use and the Lint Tool
version for diagnostic purposes. So if it does fail we have
the information we need to correct the issue.
Commit 8643ded reworked the msbuild tests to use msbuild. But
there was a problem with the logic.
string.IsNullOrEmpty (useMSBuild) || useMSBuild == "0"
well the Environment variable USE_MSBUILD will ALWAYS be empty.
Because we never set it. so the logic should be
!string.IsNullOrEmpty (useMSBuild) && useMSBuild == "0"
so that if it is set it has to be "0" to allow xbuild to be
used.
Also one of the tests was using `RunningMSBuild` before it was
calculated. So it was always false. So just added some logging to
print what we are using to the console. This forces `RunningMSBuild`
to be calculated.
One final issue was with the intermediate .pdb files being cleaned
up by `IncrementalClean`. Turns out we had a fix for the .mdb files
in `Xamarin.Android.Windows.targets`. So the solution there was to
add the same work around for .pdb files.
Jonathan Peppers
Bernhard Urban
Alexander Köplinger
Jonathan Dick
Radek Doulik
Dean Ellis
Marek Habersack
Atsushi Eno
Jonathan Pryor