The generator tests is a standard C# library, and can use the system msbuild
just fine.
Fixes this build problem when building the tests using the command line:
xamarin-macios/external/mono/external/ikvm/reflect/Emit/ILGenerator.cs(119,20): error CS0433: The type 'Stack<T>' exists in both 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
Mono did remove all the tests in a number of assemblies on
ios/tvos/watchos. With a recent change, we report test runs with no
tests as a failure (correctly since it will bring up issues with the
runners).
In this case, the tree assemblies have to be ignored because they trully
do not have tests and the runners are doing the right thing.
Fixes: https://github.com/xamarin/maccore/issues/1652
We can't assume that the cached `lipo` output is part of the `.app`
since the directory for the later could be different.
E.g. we build two .csproj in out `mmptest` inside the same directory
and they share the same `obj` directory (used for caching) but have
different output directories
```
./obj/Release/mmp-cache/libmono-native.dylib
./bin/Release/UnifiedExample.app/Contents/MonoBundle/libmono-native.dylib
./bin/Release/XM45Example.app/Contents/MonoBundle/libmono-native.dylib
```
Without an update building the XM45 project would not include the
**required** `libmono-native.dylib` library and would crash when
executed.
This might be a race issue when dealing with the trust of the certs,
there is not much information in
https://github.com/xamarin/maccore/issues/1645 except the fact that we
are getting a null exception.
In this fix, we will first ensure that we did get the exception, later
confirm the exception type. To improve the debugging of the test, next
time it fails, we will get the content string to try and understand what
happened with the validation (did we return part of the stream or
headers when we shouldn't?)
It means that on watchOS they'll exit if the screen turns off.
I have no idea why we set it up like this in the first place, it's been like
this since we created the mscorlib tests ([1]).
[1]: 76e15036e8
Trying to find a simulator will mark the test as a failure if the simulator
couldn't be found, and we don't want that to happen to ignored tests.
This should fix an issue where xharness seems to try to run the 32-bit
simulator tests when asked to run only device tests.
If a report already exists, it's probably because a previous attempt failed
for some reason. This is no reason to not try again, overwriting the previous
attempt.
So far this only applies to `QTKit`...
XM will now, by default, avoid natively link with QTKit unless it's
instructed to so explicitly using `--link-prohibited-frameworks`
ref: https://github.com/xamarin/xamarin-macios/issues/6039
It causes problems with the mscorlib test project, which can't be launched properly.
I'm not sure what's the underlying cause, but here are some of the symptoms:
* The watch app actually shows up fine on the device, but:
* mlaunch isn't notified about the new process, so it thinks the app didn't
launch.
* The new process doesn't receive any environment variables we try to give it,
which for instance means that it won't auto-start the tests upon launch.
* If we ask mlaunch to attach with lldb, mlaunch will ask watchOS to launch
the process in a suspended state while lldb attaches. Yet the watch app
shows up on the device as if not asked to be suspended upon launch.
It seems that the dash (I assume, because I haven't investigated this very
deeply, I just happened to find a solution that worked) makes watchOS launch
the app as if tapped, instead of launched from an IDE.
The strangest part is that this only happens with the mscorlib test project,
not any of the other test projects we run on the watch, and they all have
dashes in their bundle identifiers... yet replacing the dash with another
character (underscore, letter, removing it altogether) all made things work as
expected.
Basic application (size) for doing an `HttpClient.GetAsync`, release/llvm, 64bits only
- NSUrlSessionHandler (master): 6.4 MB
- NSUrlSessionHandler (PR#5936): 7.7 MB
- NSUrlSessionHandler (this PR): 6.4 MB
The size increase occurs because of the reference to .net `X509*` types.
This brings a lot of additional code, including managed cryptographic
code, inside the application - even when the feature is **not** used.
The solution is to expose an API that only use native (OS) types, which
are mostly already part of the application. This has a very low impact
on existing applications.
It's still possible to hook back to .NET validation if needed (it should
not in most cases) but, in this case, the extra price will only be
_paid_ if used (and can be lower if the code is needed by something else
from the application).
In comparison using other `HttpClient` handler produce app sizes of
- HttpClientHandler (managed): 10.4 MB
- CFNetworkHandler: 6.8 MB
Based on/supersede https://github.com/xamarin/xamarin-macios/pull/5733
Fix https://github.com/xamarin/xamarin-macios/issues/4170
The entire Xml parsing code has been changed to make the following
improvements:
1. Simplify the logic.
2. Ensure that the tests are not added more than once in the human text
log.
3. Do not use the APIs that load the entire tests into memory. XmlReader
is used to read the file and parse the results.
Fixes: https://github.com/xamarin/xamarin-macios/issues/6072
Fixes: https://github.com/xamarin/maccore/issues/1632
* [apidiff] Add rule to get mono-api-info.exe and mono-api-html.exe.
This fixes an issue when bumping mono: when bumping mono, the already
downloaded mono archive isn't applicable (because we've changed to the
previous commit, which has the previous mono hash, whose archive hasn't been
downloaded).
So add a rule to get mono-api-info.exe and mono-api-html.exe, by downloading
the current mono archive.
* [apidiff] Change the name of the unzip stamp and download dir to contain the hash.
This way the logic doesn't get confused when the hash changes (or there's an
old unzip stamp in the directory), and things are downloaded again as
expected.
* [apidiff] Make make not delete temporary files.
Things end up confused if temporary files have been removed by make, but our
stamp file that the temporary files are still there is present.
* [apidiff] No need to make everything depend on the bundled zip.
If everything that needs the bundled zip already depends on it.
* [apidiff] Restore original hash before calculating api diff.
This makes it less annoying when the api diff calculation changes, because
with the previous behavior they were impossible to test in a PR, since any
changes wouldn't take effect until after the PR was merged.
We have a 13-hour timeout for running the tests [1], but that won't work if
the timeout for the entire Jenkins pipeline is lower, so adjust the timeout
for the entire Jenkins pipeline to be more than the sum of all the nested
timeouts.
[1] 94fe39b118 (diff-68c8473bbe1d4346ecff3d74522a31f8R675)
Rolf Bjarne Kvinge
Alexander Köplinger
Manuel de la Pena
Sebastien Pouliot
Marius Ungureanu
Sebastien Pouliot
Chris Hamons
Marius Ungureanu