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.
The existing property implementation use `=` (not `=>`) which means that
the call is executed only once (in the `.cctor`).
```csharp
public static NSBundle UIBundle { get; } = Runtime.GetNSObject<NSBundle> (EventKitUIBundle ());
```
While a shorter syntax (good) it becomes easy to miss the difference
while reviewing pull requests (bad) or later when reading the code.
Also the documentation on `EventKitUIBundle` [1] is unclear. It mention
it's based on _user preferences_ which can be interpreted as something
that change at runtime. This would mean the returned pointer can be
different between calls and that we can't cache it from the static
constructor (since we would only return the original one).
So the correct (safe) code would be:
```csharp
public static NSBundle UIBundle { get; } => Runtime.GetNSObject<NSBundle> (EventKitUIBundle ());
```
but that's still hard to review so the older, self explanatory, syntax is
used.
[1] https://developer.apple.com/documentation/eventkitui/2866511-eventkituibundle?language=objc
Copy test projects to a temporary directory before using them for tests. This
makes sure tests don't leave a dirty working tree (because some tests modify
the on-disk test code).
We'll also start running tests using SDK-style project files, and this way
it's much easier to run tests twice, once using the old format and once using
the new format, and then compare the results.
Most of the changes are related to making the test projects and code
relocatable.
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.
This fixes an issue related to single quotes and that the fact that mono's behavior
regarding quoting them has changed (by not using single quotes).
This becomes an issue when running with dotnet.
Mono.Posix comes with a native library, and that makes IL merging much more
complicated, especially when Mono.Posix comes from a nuget. So remove the
Mono.Posix dependency, and instead write the 2 P/Invokes we need manually.
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.
This reverts commit 80825d6b6d.
Tests breaks under macOS 10.15.
Also some of the changes I requested on the original PR were not
made and several methods are missing validation. There might be
other stuff too (only found this out while looking at the test
failure).
* [registrar] Fixes NSString trampoline code generation in static registrar
Fixesxamarin/xamarin-macios#7733
This was introduced as a side effect of commit 8425129, we
used to generate `id foo` instead of the full block signature
in the trampoline code used by the static registrar, this is
the reason we never caught this condition before.
Added registrar test.
* Move tests to the appropiate test file
We need to make sure that the iOS SDK and the iOS version do match the
ones present in Xcode.
* Add new variables to track the target version.
* Add method to get the target version.
* Modify mtouch to check agains the target framework rather than the
SDK.
This will allow to keep track of three independent things:
1. The SDK max version.
2. The Simulator max version.
3. The target version of the device.
This had to be added becuase 13.2 has targets to 13.2 but simulators for
13.3
Fixes: https://github.com/xamarin/xamarin-macios/issues/7705
* Fix fetching author's name + email for failure reporting by running git in
the directory where the repo actually is.
* Don't fail the build if we fail to generate/upload artifacts.json, instead
show the failure everywhere and continue as if nothing happened. There seems
to be a random issue with GitHub where a network request fails, and there's
no need for that to fail the entire build.
* Bump Xamarin.MacDev.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@210c664 Adds net451 to Xamarin.MacDev.csproj
* xamarin/Xamarin.MacDev@64db365 [winios] Changes provisioning profiles default path
* xamarin/Xamarin.MacDev@d34430a Switch to short-form projects and build for both net461 and netstandard2.0. (#68)
Diff: 0f578f51e6..210c664e56
* [msbuild] Update to latest Mono.Cecil.
The older version doesn't support netstandard2.0.
No code changes were required.
* [msbuild] Remove unused usings.
* [msbuild] Make ILMerge work when building for netstandard2.0.
Also unify/deduplicate the ILMerge logic between Xamarin.iOS and Xamarin.Mac.
* [msbuild] Build for netstandard2.0 in addition to net461.
* [msbuild] Use custom project configurations to support running the tests for both netstandard2.0 and net461.
Use custom project configurations to support running the tests for when the
tasks assembly is built for netstandard2.0 and net461.
* [tests] Make command-line based 'make test-ios-tasks' run tests for both netstandard2.0 and net461.
* [xharness] Add test configuration to run iOS MSBuild tests using either netstandard2.0 or net461.
* [msbuild] Make the netstandard2.0-buils task assemblies the default.
* [msbuild] ILRepack lib assemblies, not ref assemblies.
Ask MSBuild to copy lib assemblies to the output folder when building for
netstandard2.0, this way we can easily find the actual implementation
libraries to pass to ILRepack.
* [msbuild] Merge System.Text.Encodings.Web.dll as well.
* [xharness] Fix build of MSBuild tests for iOS.
Bump maccore so that a status is posted when the device tests cannot be
scheduled. Update the JenkinsFile to make sure that the required token
is passed to the launch.sh script.
* [xharness] Fix two compiler warnings.
Fixes these warnings:
Jenkins.cs(538,37): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.
Jenkins.cs(877,14): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.
* [xharness] Simplify async code a bit.
* [msbuild] Convert to short-form csproj.
* [msbuild] Make asserts more useful.
* [msbuild] Make tests ignore the actual location of the test assembly.
* [msbuild] Short-style projects default to deterministic builds, which is not compatible with wildcard versions.
* [msbuild] Adjust test.
* Update .gitignore.
* Bump NUnit.ConsoleRunner version.
* [msbuild] Fix indentation.
* [msbuild] Simplify csproj.
In the DDFun pipeline case `cat: tmp.p: No such file or directory` so the `P` variable cannot be set and that's failing vsts-device-tests-set-status.sh
These tests were checking if mtouch is called (or not) by checking for the
full installed path to mtouch. When running the tests locally, we're using the
locally built mtouch, and thus the path is different and the tests failed.
Instead check for a smaller substring that is present in both cases.
The callback is missing the url wich is useful information to have when
trusting a cert. We do the following:
1. Allow users to use the old callback, but state it as Obsolete.
2. Add a new delegate that will take the url.
3. A cert is accepted if one of the callbacks accepts it. The general
callback is a superset of the url one.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7413
- https://devdiv.visualstudio.com/DevDiv/_queries/edit/1041456/
- On Windows the GenerateManifests target will sometimes run and do the wrong thing
as we overload their usages of @(NativeReference). Stub it as a no-op
- Also stub out targets XVS were stubbing.
- https://github.com/xamarin/xamarin-macios/issues/5738
- There are a number of managed exceptions Apple can throw at you during
debugging, such as expanding a NSColor in the wrong colorspace
- Throwing a managed exception is a nicer debugging experience, and
during debug we don't care about any performance penality.
This change allows to ignore the use of cookies and cookie containers in
the NSUrlSessionHandler. There are two different cookie containers to
consider:
1. The native NSHttoCookieStorage.
2. The managed CookieContainer.
If the native one is set to null, the native code will not use a cookie
storage, which is used as a flag to ignore the managed one.
There is an interesting situation, we allow different types of sessions.
From the cookie storage point of view, Default and Background sessions
are the same, but Ephemeral is not, since we only want to store in ram
the cookies and do not share them.
This supposes a problem because Apple does not provide any API that will
allow to determine the session type use in the configuration. The
workaround has been to hide the direct native call for the configuration
and add an enum value that can later be accessed in the
NSUrlSessionHandler. Of course things cannot be that easy. When a
session is created with the configuration, it creates a copy, and the
internal session configuration does not longer have the flag, therefore,
we need to store the session type in the handler.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7659
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
Commits are:
* [domain] Don't add NULL runtime to runtimes list (#18265) dc5902c243
* [eglib] Don't define _FORTIFY_SOURCE on Cygwin builds (#18312) 5f0704ce37
* Socket.BeginMConnect() should not attempt connections on unsupported address families. 99e3aed6ec
* [2019-10] [metadata] Size 0 Blob heap is ok when resolving assembly refs (#18338) 2faea92a92
* [FileSystemWatcher] Fix wrong behaviour when move multiple files out of watched folder on mac (#41963) df42020fe6
Complete diff is: bfcac9bd30...df42020fe6
The order of the check matters, we only skip with a sim && not on
xcode11.
The other whay around will do the wrong short circuit. Since if we are
not on Xcode11 we will always skip, including device, which is not
correct.
Fixes: https://github.com/xamarin/xamarin-macios/issues/6243.
The 32bits **debug** binaries are now too big for Apple's native linker
to process, which gives us (non useful) build errors on the bots.
This will still run the release builds configuration of the tests since
they are smaller and still within the limits of the tooling.
TL&DR
* re-apply the fix to cache.cs from https://github.com/xamarin/xamarin-macios/pull/7544
* which was reverted in https://github.com/xamarin/xamarin-macios/pull/7589
* since it regressed mscorlib/sim testing in xharness (for other reasons)
* Final part to fix https://github.com/xamarin/xamarin-macios/issues/7514
This was the ~night~ day before christmas... amd a tough nut to crack!
Thanksfully we had a good test case (inside #7514) and then xharness
regressed one test in consistent, reproducible manner.
xharness builds mscorlib tests twice (32 and 64 bits) even if it's a
fat application (could be reused). That should not be a huge problem
since the 2nd build should be identical and the cache should be (re)used.
An earlier attempt fixed this (comparison was true for the wrong
reasons [1]) but the fix did not end up with the same arguments !?! and
was reverted.
This is the diff between the first and second builds:
```diff
--- /Users/poupou/a.txt 2019-12-23 09:55:01.000000000 -0500
+++ /Users/poupou/b.txt 2019-12-23 09:55:01.000000000 -0500
@@ -182,5 +182,5 @@
-r=/Users/poupou/git/xamarin/xamarin-macios/builds/downloads/ios-release-Darwin-8f396bbb408b5758fccb8602030b9fa5293ce718/ios-bcl/monotouch/tests/Xunit.NetCore.Extensions.dll \
' --target-framework=Xamarin.iOS,v1.0' \
--root-assembly=/Users/poupou/git/xamarin/xamarin-macios/tests/xharness/tmp-test-dir/mscorlib/bin/mscorlib/iPhoneSimulator/Debug-unified/com.xamarin.bcltests.mscorlib.exe \
- ' -v -v -v -v' \
+ ' -v -v' \
@/Users/poupou/git/xamarin/xamarin-macios/tests/xharness/tmp-test-dir/mscorlib/obj/iPhoneSimulator/Debug/response-file.rsp \
```
Since they are not identical the cache is invalidated (which is normal,
cache-wise) and produce an output app that is incorrect (and crash
32bits).
Now there is code to ignore verbosity options (both `-v` and -q`) since
they will not affect what `mtouch` generates. However this was broken
because mtouch's response-file parser is quite basic and stricter the the
specification
spec: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/response-file-compiler-option
issue: https://github.com/xamarin/xamarin-macios/issues/7644
That failed in two different ways
1. note the extra space before the first `-v` in the diff (before the `'`
quote). That skipped the line.
2. there are multiple `-v` in the same line, again that make the
filtering skip the line.
*Unknowns*
It's too close to xmas/vacation so I might not find the reasons/issues
for the following, unanswered questions...
1. Why is the re-build app bundle failing at runtime when p/invoking ?
Something is not regenerated (symbol maps?) ?
2. Why xharness 2nd build has more verbosity than the first one (likely
harmless) ?
[1] the original cache.cs issue (prequel)
issue w/test case: https://github.com/xamarin/xamarin-macios/issues/7514
first attempt: https://github.com/xamarin/xamarin-macios/pull/7544
While incorrect the first attempt to fix `cache.cs` was a logical, if
not entirely complete, fix. Without it this is what we _currently_ cache:
```
/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mtouch/mtouch.exe \
```
and that does not include any of mtouch's arguments, that can change
between executions and (should) invalidate the cache.
In this case it means the cache is used (no difference) but this does
**not** parse the content of the **response file** which is obviously
wrong (and we do have code to process it).
On the original issue's test case this is what makes the difference
between using the same *old* nuget assembly after an update (and fail)
by itself and also because the updated framework was not copied (due
to the 2nd part of the bug report wrt `copyfile`).
OTOH re-using (incorrectly) the cache is what makes xharness's mscorlib
unit tests works right now :(
Some types are not available in any 32bits iOS versions. We are _mostly_
(but not always) throwing a `PlatformNotSupportedException` when they are
used. However we're missing cases where we can reduce the generated code.
This is one (of a few) occurrences.
New generated code looks like:
```csharp
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
static readonly IntPtr class_ptr;
static readonly IntPtr class_ptr = Class.GetHandle ("ARFaceGeometry");
```
Beside the obvious `Class.GetHandle` call removal, this has the nice,
side benefit of removing several `.cctor` from the assembly (that were
only needed to set this field).
This reduce the code size for the 32bits version of Xamarin.iOS.dll [1]
```
Before: 16,338,944
After: 16,255,488
Diff: 83,456
```
[1] While this might not sound very useful, since it's going away, its
becoming a problem (because it's not going away fast enough) since we're
not able to build some (non-linked) test suites anymore due to size
constraints (and Apple's `ld` branching limit).
Sebastien Pouliot
Manuel de la Pena
Rolf Bjarne Kvinge
Vincent Dondain
Chris Hamons
Alex Soto
Bruno Garcia
Waleed Chaudhry
Pramit Mallick
Marius Ungureanu