We've modified our NUnitLite to special-case the native types, so that they
can easily be compared with the standard types, but that doesn't work anymore
when switching to the official NUnit[Lite], so change all asserts to
explicitly convert whenever needed.
## 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.
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
state.
Some of the tests were creating connections when not needed, this
'apparetly' was leaving the internal state of the Networking API in a
bad state in which it would throw a SIGSEGV and will make the connection
of other tests fail. In this case, the Tls tests that use the Network
API.
Cleaning the tests and removing those badly managed connections ensured
that the SIGSEGV would not be thrown and got all the other tests to
work.
This is a blackbox, test now passes without problems.
Fixes: https://github.com/xamarin/maccore/issues/2048
* [Tests] Fix the Network tests.
The pattern used to Cancel then Dispose the connection is wrong and
ended up crashing the tests sometimes. It is a race condition and is
very rare, but makes the tests flaky. The changes ensures that we
Dispose the connection, which internally closes it.
Tests have been added for the NWConnection Close calls.
Also cleaned some on the CWL that were not needed.
The block/delegate passed to NWTxtRecord.Apply is supposed to return a bool.
Not returning anything ends up with random behavior, which causes a test
failure on Catalina:
3) TestApply (MonoTouchFixtures.Network.NWTxtRecordTest.TestApply)
keycount
Expected: 4
But was: 1
at MonoTouchFixtures.Network.NWTxtRecordTest.TestApply () [0x000a3] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/monotouch-test/Network/NWTxtRecordTest.cs:134
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0006a] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/mono/mcs/class/corlib/System.Reflection/RuntimeMethodInfo.cs:395
I've fixed the existing API to return 'true' always in the block callback, to
get consistent behavior, and in addition I've added a new overload that takes
a delegate that returns a bool, which allows the consumer of the API to decide
what to return.
Fixes https://github.com/xamarin/maccore/issues/2036.
Kept the API as it was but added a new handler that will be called when
all the changes from the browser have been done. The old Set* method
could be deleted in a future release and just expose the property.
* [Network] Improve bindings for NWProtocolMetadata.
It turns out the NWProtocolMetadata can contain metadata for different
protocols (Ip/Tls/Tcp). This is important; if someone tries to get a value for
one protocol and the metadata is for another protocol, then they invoke the
wrath of superior beings who will smite that poor someone with uninitialized
memory.
At that point there's not much left but to pray.
I don't like to depend on divine intervention, so I've modified the API here
to check if the metadata's protocol is the required type for the native API
we're calling, and if the check fails, we throw a nice and dependable managed
exception.
This is a functional breaking change; but if there are any lost souls who
likes to pray, they can always re-implement the P/Invokes themselves and skip
the sanity checks.
In addition I've renamed a few properties whose name didn't clearly specify
which protocol type they operate on.
Ref: Apple feedback FB6155967.
Ref: https://trello.com/c/1TW0BSKJ/145-fb6155967-nwipcreatemetadata-returns-uninitialized-metadata-in-ios-13
* Fix casing in exception message.
* [tests] Adjust the SecProtocolMetadataTest according to new knowledge about the Network API.
* Fix alternative property name in obsolete attribute.
* Avoid `ArgumentNullException` in default/empty `SecProtocolMetadata.PeerPublicKey`
* Add two `SecProtocolMetadata.CreateSecret` API - disabled as the current tests (incomplete?) crash in unit tests
* Add basic unit tests for `[Sec|NW]ProtocolMetadata`
* Update xtro
Manuel de la Pena
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto
Jo Shields
Vincent Dondain
Waleed Chaudhry