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.
TouchUnit uses Console.Out as the writer when the TCP connection cannot
be performed. The BCL tests were not doing so and were crashing.
With this change, when ran locally, if the TCP connection is not done,
we will use Console.Out as TouchUnit and the file will be parsed by
xharness correctly.
Updating the msbuild tasks to use netstandard2.0 requires us to bump NUnit to 3+.
This requires:
* A few code changes due to breaking API changes in NUnit.
* Changes in xharness and a makefile to cope with the new location for the
NUnit console runner (I added a helper script to make things slightly
easier).
* [monotouch-test] Improve reachability test.
Give up.
Different versions of OSes report different flags. Trying to
figure out which OS versions have which flags set turned out to
be a never-ending game of whack-a-mole, so just don't assert
that any specific flags are set.
Some of the fixes done for the warnings have breaking changes. Move back
to int and ensure that we do not have any compilation errors (we are
using -Werror).
Fixes: https://github.com/xamarin/xamarin-macios/issues/7509
It's possible for a nuget to have dependencies that will bring satellite
assemblies into a project.
When doing so the satellite assemblies are copied to the right output
(e.g. `Debug`) directory, so they work fine at runtime. However it's
not 100% fine at build time, e.g. msbuild won't detected them as
satellite assemblies.
Something similar happens with `mtouch` (and `mmp`) since the satellite
assemblies won't be found inside a (culture-named) subdirectory from the
original assembly location. In our case this means the assemblies won't
be copied into the .app bundle (since we don't run from `Debug`) and
localization won't work properly.
The solution is to check for both the (culture-named) subdirectories
from the assembly location (like before) and, if nothing is found, also
try to locate them in the _build_ (like `Debug`) directory - so if
something else (nuget or custom build scripts) tried to outsmart the
build logic then we'll still bring those satellite assemblies in the
app bundle we produce.
https://github.com/xamarin/xamarin-macios/issues/7113
1. Instead of fetching the managed response's cookies twice, and then
comparing them to themselves, fetch the managed response's cookies once and
then the native response's cookies once, and compare that. This way the
test does what it's actually supposed to do!
2. Don't pass if we fail to get the managed response's cookies.
3. Improve assertions to verify the actual cookie content as well.
4. Improve diagnostics if an exception was thrown by checking for the
exception first instead of failing due to something else being different
(since the underlying cause of the difference is the exception, that's what
will have the most information about the failure).
5. Use httpbin.org instead of microsoft.com, since microsoft.com does UA
sniffing and returns different results between the http handlers :/
## Miscellaneous fixes
* Fixed
`/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/builds/mono-ios-sdk-destdir/ios-sources/external/linker/src/linker/Linker.Steps/OutputStep.cs(110,15): error CS0246: The type or namespace name ‘OutputException’ could not be found (are you missing a using directive or an assembly reference?) [/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/mmp/mmp.csproj]`
* Changed the name of the method that is used from linker. Because of this commit 6be26771b9
* Added `OutputException.cs` file on `mtouch.csproj`.
* Removing enter_gc_safe and exit_gc_safe because now it's already gc_safe in this part of code, after a mono change.
* Added known exceptions to LLVM exception list.
* Needs `ifdef` because of this https://github.com/mono/mono/pull/17260.
* Bump MIN_MONO_VERSION to 6.8.0.41 and point MIN_MONO_URL to the PR.
* Add ENABLE_IOS=1 and ENABLE_MAC=1.
* Added switch to disable packaged mono build
* [Tests] Ignore tests that fail on 32b.
Ignore the test on 32b, and filled issue: https://github.com/mono/mono/issues/17752
* [Tests] Ignore a couple of tests causing OOM.
Hopefully fixes https://github.com/xamarin/maccore/issues/1659 for good.
* Ignore `MM0135` test on Catalina+ because it needs Xcode 9.4.
* [monotouch-test] Add null checks for teardown when test didn't run because of a too early OS version.
* [CFNetwork]: Http 2.0 requires OS X 10.11 or later.
Check whether `_HTTPVersion2_0` is available and fallback to HTTP 1.1 otherwise.
## Bring HttpClient from CoreFX
* #7346
* This bumps Mono to use https://github.com/mono/mono/pull/17645 (which is the 2019-10 backport
of https://github.com/mono/mono/pull/17628).
* The big user-visible change is in regards to certificate validation, everything below are just
some minor adjustments to tests.
### SocketsHttpHandler
CoreFX uses a completely new `HttpClientHandler` implementation called `SocketsHttpHandler`,
which you can find at https://github.com/dotnet/corefx/tree/release/3.0/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler.
Since this is not based on the web stack anymore, it does not use any of the related APIs such
as `ServicePointManager` or `WebException`.
### Certificate Validation Changes
There is a new API called `HttpClientHandler.ServerCertificateCustomValidationCallback`.
- https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.servercertificatecustomvalidationcallback?view=netframework-4.8
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Unix.cs (L154)
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Windows.cs (L383)
The `ServicePointManager.ServerCertificateValidationCallback` is no longer invoked and on
certificate validation failure, `AuthenticationException` (from `System.Security.Authentication`)
is thrown instead of `WebException`.
At the moment, the `NSUrlSessionHandler` still uses it's own validation callback and also still
throws `WebException` on failure; we should probably look into making this consistent with the
other handlers.
### Minor adjustments related to internal Mono APIs
* `HttpContent.SerializeToStreamAsync()` is now `protected` (changed from `protected internal`).
- src/Foundation/NSUrlSessionHandler.cs: changed overload accordingly.
- src/System.Net.Http/CFContentStream.cs: likewise.
* `HttpHeaders.GetKnownHeaderKind()` is an internal Mono API.
There is a new internal API called `System.Net.Http.PlatformHelper.IsContentHeader(key)`
which exists in both the old as well as the new implementation.
The correct way of doing it with the CoreFX handler is
`HeaderDescriptor.TryGet (key, out var descriptor) && descriptor.HeaderType == HttpHeaderType.Content`
### Minor adjustments to tests.
* `HttpClientHandler.MaxRequestContentBufferSize` is now longer supported, you can set it to
any non-negative value, the getter will always return 0.
See c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Core.cs (L18).
- tests/linker/ios/link sdk/HttpClientHandlerTest.cs: removed assertion from test.
* `HttpMessageInvoker.handler` is a `protected private` field - in the CoreFX handler, it is
called `_handler` and `private`. This is accessed via reflection by some of the tests, which are
now using the new name.
- tests/mmptest/src/MMPTest.cs: here
- tests/mtouch/MTouch.cs: here
* tests/monotouch-test/System.Net.Http/MessageHandlers.cs:
Adjust `RejectSslCertificatesServicePointManager` to reflect the certificate validation
changes described above.
- FIXME: There was an `Assert.Ignore()` related to `NSUrlSessionHandler` and macOS 10.10;
I removed that to reenable the test because the description linked to an old issue in
the private repo that was referenced by several "Merged" PR's, so it looked to me that
this might have already been fixed - and I also didn't see why it would fail there.
**Problem**
32 bit tests could only be executed with 64 bit tests. E.g: `run-ios-32-tests` didn't work on its own, only `run-ios-tests,run-ios-32-tests` worked
**Solution**
- Change the logic so that 32 bit tests are only looking for `IncludeiOS32` and 64 bit tests only `IncludeiOS64`
- To keep `run-ios-tests` and `skip-ios-tests` working, hack `SetEnabled` so `IncludeiOS` also sets `IncludeiOS32` and `IncludeiOS64`.
Otherwise the way the code is currently organised we'd have to use `skip-ios-32-tests` and `skip-ios-64-tests`.
Keep 'CallContextSecurityData' around since it's quite small (and the
normal linker logic will be able to deal with it if unused) and allows
the use of `Thread.CurrentPrincipal`
Also add unit test.
Fix https://github.com/xamarin/xamarin-macios/issues/7321
and drop the manual, error prone, conversion code.
The fact that this is also used as a `[Flag]` enum does not mean smart
enum could not be used [1]. The flag code only needed to be updated to
use the smart enum generated code.
[1] https://github.com/xamarin/xamarin-macios/issues/7317
Added unit tests.
`Create` methods give ownership of the object, so in this case, owns=true. Prevents leak of CFHTTPAuthentication
Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-Authored-By: Manuel de la Pena <mandel@microsoft.com>
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 linking tests do use a number of endpoints.
As with PR https://github.com/xamarin/xamarin-macios/pull/7418 we want
to have all the endpoints in a single place to update them if the server
side does give us problems.
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.
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.
Use a single point where the different enpoints can be found so that
if they need to be updated (server issues or other) it is a simple
change that will affect all tests in monotouch-tests
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
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
If we are getting errors (500,401..) do not mark a link all test as a
failure, but as inconclusive. Update the urls since msdn is giving always a 500.
Fixes: https://github.com/xamarin/maccore/issues/2056
* [tests] Add make target to manually launch a device test run for the current commit.
* Upload a manifest that can be found using only the hash, and use it to find the packages.
Alex Soto
Manuel de la Pena
monojenkins
Rolf Bjarne Kvinge
Sebastien Pouliot
Jo Shields
Vincent Dondain
Pramit Mallick
Marius Ungureanu
michizhou