* [msbuild] Provide the correct value for the operating system for tvOS and watchOS to a few tasks. Fixes#6200. (#7226)
The problem with #6200 was that we'd pass -mios-version-min=x.y to the metal
tool even for tvOS apps. This fixes it so that now pass -mtvos-version-min.
Fixes https://github.com/xamarin/xamarin-macios/issues/6200.
* [msbuild] Add support for Metal in the simulator. Fixes#7392. (#7983)
This will spot cases like https://github.com/xamarin/xamarin-macios/issues/7959
where a type (static) constructor can fail at runtime, leading to
`TypeLoadException`
Ideally it's covered by it's own tests but it's better covered twice
than never :)
On iOS 64bits [1] simulator we hit some failures [2], later, if the
`.cctor` is executed. It's not a big deal to avoid those types since
we it will be executed on devices later.
[1] API not present on 32bits
[2] Fixing the following triggers similar failures for `DCDevice`
```
ApiClassPtrTest.VerifyClassPtr: class_ptr and RegisterAttribute are different: NFCIso15693CustomCommandConfiguration
Expected: 0
But was: 140735471513712
ApiSelectorTest.StaticMethods: 7 errors found in 2788 static selector validated:
CoreNFC.NFCIso15693ReaderSession : readingAvailable
CoreNFC.NFCNdefMessage : ndefMessageWithData:
CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithString:
CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithURL:
CoreNFC.NFCNdefPayload : wellKnownTypeTextPayloadWithString:locale:
CoreNFC.NFCNdefReaderSession : readingAvailable
CoreNFC.NFCReaderSession : readingAvailable
Expected: 0
But was: 7
```
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Ignore Xamarin.MMP.Tests.WarningTests.MM0135 on macOS 10.15+, because this
test requires Xcode 9.4, which doesn't work on macOS 10.15+.
Fixes https://github.com/xamarin/maccore/issues/2035.
As per the documentation of the VSTS test uploader (https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/test/publish-test-results?view=azure-devops&tabs=yaml#attachments-support)
the tests support the addition of attachments. We want to be able to
access the logs of the different tests runs, this is achieved the
following way:
1. Move TouchUnit to use NUnit V3 which allows to add attachments.
2. Once the tests are ran, add the attachments to the following nodes:
1. The very first test-suite. This will allow to have the logs for
succesul tests.
2. Add logs to failing tests. Reduces the number of clicks to be done
to access to the logs when a test case fails.
3. Modify the assembly name of the test-suit to match the name of the
application. This ensures two things.
1. We have a consistent name for the file column in VSTS, that can be
used to see recurrent failing tests.
2. The name is more readable, since if not, it will contain the UUID
of the device.
Logs are not added to succesful tests because it will have the following
problems:
* Larger data storage usage.
* Longer upload time. The addtion of the logs per tests (succesful or
failed) was tested and resulted in an upload time LONGER than 6 hours
for all TouchUnit, NUnit blc tests and xUnit bcl tests.
In order for this to be useful, the task in the pipeline SHOULD NOT
merge test runs. We should have a test run PER application so that we do
not mix the logs.
Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
One of the reason why we lost the TestReport was because the xml added
from the new code did not use the same name for the log as the expected
one (https://github.com/xamarin/xamarin-macios/pull/7835/files#diff-03773861bcef485bf343300f31b60b0eR374).
If we are going to be using the description as a way to decide what is
going to be done with it, lets use static vars so that we do not have
logs added with the wrong name.
* [xcode11.4] Add xcode 11.4 b1 initial support
* [xtro] re-enable PDFKit
* Disable watchOS and fix xtro
Unfortunately watchOS simulator hangs when we try to deploy to it
and it keeps our tests timing out. Disabling for now until we
can investigate more.
Disables PDFKit on xtro in macOS
* [jenkins] Switch to use the catalina bot group (#7819)
* Bump maccore to get fix for launching the simulator for watch apps.
New commits in xamarin/maccore:
* xamarin/maccore@546270c8f9 [Xamarin.Hosting] Fix the name of the notification we get when the simulator has launched. (#2145)
Diff: 55957e908d..546270c8f9
* [tests] Diable watch due to time out, enable 10,15,4 in intro, fix min version
* Bump macios-binaries to get updated binary mlaunch as well.
New commits in xamarin/macios-binaries:
* xamarin/macios-binaries@f8c6e63 Bump mlaunch to xamarin/maccore@546270c8f9
Diff: eb6980e8b6..f8c6e63228
* [msbuild] Reflect ibtool changes in our tests
Looks like Apple reverted some changes introduces in Xcode 11
in ibtool, for more context see xamarin/xamarin-macios#6970
* [mtouch] Workaround strange behavior of realpath.
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Add code to write the TestReport when we have xunit results. Also
refactored code for the NUnit format to not use LINQ, it will use less
memory and in the future we can move to async (not now since it might
raise other problems).
fixes: https://github.com/xamarin/xamarin-macios/issues/7826
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
We ping the tcp listener to know that we have a tcp connection, that is
written in the xml logs, which means that parsing will not work. Ignore
the ping, parse xml, and make sure that the xml that will be consume by
vsts is valid.
This PR also fixes https://github.com/xamarin/maccore/issues/827 which does not longer happen.
Looks like we have issues with the internet sharing in the VSTS bots,
this means that now that we always try to parse the XML on CI, we get an
exception, catch it and do not show the results.
The workaround simply tries to read the xml, if possible, we will parse
it, else deal with the text only log. The fix will show the results, but
it is a workaround for a configuration issue in the CI.
Unify the harness properties to just look at InCI and remove all the
other ones. There is no real need to have differences between jenkins
and VSTS and Wrench is gone.
We used to test only on Jenkins, and if the build version had jenkins on
it, rather than doing so, just check if we are in the CI by looking if
BUILD_REVISION is present in the env.
Use the xml parsing helper methods to decide if the xml can be parsed
and if we will be able to generate the report. That way we avoid an
exception that makes the CI noise.
After this commit we will have more application but they will be the
appropiate size so that they can be built with the linker for iOS 32b.
It is important to note that the following apps WILL CONTINUE to fail
since the dlls need to be splitted in mono:
* mscorlib tests
* Mono BCL tests group 5 - Which is monotouch_System.Core_xunit-test.dll
and is too large.
If forcing a managed type for a particular native handle, we must ensure we're
always successful.
This means creating another managed instance even if there already is an
existing instance for the native handle. This is not optimal, but the
alternative is worse: some functionality can be completely broken otherwise
(such as NSSavePanel⁄NSOpenPanel may stop working).
If creating multiple managed instances for the same native handle ends up
being too problematic, we'll probably have to add full support for this
scenario (see #7442).
Fixes https://github.com/xamarin/xamarin-macios/issues/7441.
Turn older #7165 prototype into an experimental feature. It can be
enabled by adding `--optimize=experimental-xforms-product-type` to the
**Additional mtouch arguments** of the project.
ref: https://github.com/xamarin/xamarin-macios/pull/7165
The latest SDK version and the latest OS version does not necessarily have to
match (for instance the iOS 13.2 SDK can support both iOS 13.2 and iOS 13.3),
so keep track of them separately.
Also use the latest OS version to determine which simulator to run, instead of
the latest SDK version (Xcode 11.3 ships with the iOS 13.2 SDK but only has an
iOS 13.3 simulator, not an iOS 13.2 simulator).
Fixes https://github.com/xamarin/maccore/issues/2066.
When working on https://github.com/xamarin/maccore/issues/940 we noticed
that clone the array would be a better approach.
The CFArrayCreateCopy add some nice things:
* The pointer values from theArray are copied into the new array.
* The values are also retained by the new array.
* The count of the new array is the same as theArray
* The new array uses the same callbacks as theArray. [IMPORTANT]
Whith this in, we can have a better fix for https://github.com/xamarin/maccore/issues/940
Uncommented the sources and update some mistakes after following the
sample provided by Apple. Initially tests were going to be added but
they resulted to be to flacky and would make the CI red too often to be
adding value.
Porting the sample will ensure that it works are the bindings are not
broken.
Rolf Bjarne Kvinge
monojenkins
Alex Soto
Manuel de la Pena
Pramit Mallick