* Touch.Client references the official NUnitLite package, which means we're using
a non-forked version of NUnit.
* This makes it easier for our .NET 5 effort, since we won't have to port an ancient
version of NUnitLite to .NET 5 (nor will we have to keep using it in our existing
code, we can use more modern NUnit patterns).
* Reference MonoTouch.Dialog from the NuGet package. This also eases the .NET 5 effort,
since we won't have to port MonoTouch.Dialog to .NET 5 (we'll probably still do it
though at some point, but it doesn't have to be done right away), nor build it
ourselves / ship it.
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.
* [monotouch-test] Fix broken UrlRequestTest.Mutability_30744 test.
This test is supposed to assert that setting a header on an immutable
dictionary throws an exception.
The problem is that the tested code always throws an exception: either when
setting the header, or when asserting right after because no exception was
thrown, effectively always passing.
This showed up with current versions of NUnit[Lite], which keeps track of
assertion failures, and fails a test even if those assertion
failures/exceptions are caught in exception handlers.
So remove the whole exception verification logic, and just try to set the
value. We'll see if the test start failing somewhere (I've already tested both
on device and simulator, and no problems found so far).
* Remove a simulator condition.
It works on device for me (iPhone 7 with iOS 11.4.1)... maybe Apple changed
something?
* [tests] Use Assert.Throws instead of the ExpectedException attribute.
The ExpectedExceptionAttribute doesn't exist in newer versions of NUnit[Lite] anymore.
* [monotouch-test] Rework some CaptiveNetwork tests.
They need permissions, and entitlements, and something else I couldn't figure
out, so just assert they're returning null instead.
The latter is much, much, *much* slower when using a recent version of NUnit[Lite].
I have no idea exactly how much slower, because it was so slow that I got
tired of waiting, and stopped the tests.
So use EqualTo instead, since the arrays should be equal in the first place.
Includes support for `UTType`-based `[Field]` in the generator as an
hundred (or so) of them were added. Unit test shows the field-based
properties are working as expected.
* [arkit] Remove fields (from beta2) to fix introspection
* [tests][introspection] AVMutableMediaSelection is as bad as it's non mutable parent
* [tools] Update IsFrameworkBroken (remove CoreAudioTypes and MediaPlayer)
* [tests][monotouch-test] MKPinAnnotationView seems fixed in beta 2
* [tests][xtro] Update ARKit todo (with previous fix)
instead use `Buffer.MemoryCopy`.
Currently only used from `CGDataProvider`. Added unit tests for the
public/indirect, usage of the API (we had none).
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Apple's charts say indirect command buffers are available with MTLGpuFamilyCommon2.
That's not quite so, devices that support MTLGpuFamilyCommon2 may crash when
MTLDevice.CreateIndirectCommandBuffer is called.
So make the conditions for calling CreateIndirectCommandBuffer an intersection
of the previous condition for macOS (MTLFeatureSet.macOS_GPUFamily2_v1) + the
new condition (MTLGpuFamily.Common2) + Xcode 11+ (just to make things
simpler).
I've tested this on all our macOS bots, and it worked on all of them.
If it fails anywhere else (iOS devices), the next patch will remove the entire
test.
Do not allow calling `CFRetain` or `CFRelease` on a null handle as this
will crash the process, instead use `GetCheckedHandle` so a managed (and
catchable) `ObjectDisposedException` can be thrown.
Make `GetCheckedHandle` public so subclasses (outside the platform
assembly) can use it - it's already recommended in some `[Obsolete]`
attributes (but was not made available).
Move the `ObjectDisposedException` thrower into a new `ThrowHelper`
class. This will allow sharing it (to be re-used in future PR).
Add unit tests for `NativeObject`.
As described in the issue, when the credentials for the base auth are set
to be empty the request reaches a timeout.
The inner issue is that when we have empty credentials the query that
is performed to the credentials db of the system throws an exception.
This exception is not raised to our code, but simply prints out in stderr.
When this situation occurs we get in an infinite loop in which we keep
sending the same credentials, we get another challenge, but the OS does
not do the right thing, we believe that we have to provide the creds
again (which are the same) and we get another challenge.. this goes on
an on until we reach the timeout.
Fortunately we know the number of failed challenges and the failure
response. With this information we can deduce if we already sent the
credentials, and if we did, do not set them again. In this case, the OS
sees no credentials in out delegate, uses the default handler and
correctly returns a 401.
fixes: https://github.com/xamarin/xamarin-macios/issues/8342
Fixes: https://github.com/xamarin/xamarin-macios/issues/8344
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* [Foundation] Do not get in an infinite loop with empty creds.
As decribed in the issue, when the credentials for the base auth are set
to be empty the request reaches a timeout.
The inner issue is that when we have empty credentials the query that
is performed to the credentials db of the system throws an exception.
This exception is not raised to our code, but simply prints out in stderr.
When this situation occurs we get in an infinite loop in which we keep
sending the same credentials, we get another challenge, but the OS does
not do the right thing, we believe that we have to provide the creds
again (which are the same) and we get another challenge.. this goes on
an on until we reach the timeout.
Fortunately we know the number of failed challenges and the failure
response. With this information we can deduce if we already sent the
credentials, and if we did, do not set them again. In this case, the OS
sees no credentials in out delegate, uses the default handler and
correctly returns a 401.
fixes: https://github.com/xamarin/xamarin-macios/issues/8342
fixes: https://github.com/xamarin/xamarin-macios/issues/8344
* initial imagio bindings + test project
* remove sample files, update xtro
* clean up
* add new line at eof
* even more cleanup...
* update based on PR feedback
* reformat according to coding standards
* fix all feedback except monotouch tests
* add monotouch-test files
* fix test feedback
* fix PR feedback
* fix timeout in tests, add asserts for status, update return value for APi to CGImageAnimationStatus enum
* fix == asserts
* respond to more pr feedback
* add StrongDictionary, remove Partial
* NSNumber -> nuint for NSUInteger
* add smaller gif
* remove hack.gif from project
* add gif to csproj
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
The _nice_ thing about `NSURLProtocol` is that it does not force the use
of the network - but we inflicted this upon us on tests.
So this updates the test to avoid the network, which should make it
more reliable and not so much influenced by the URL used or the OS
versions where it's executed.
This does not cover as much callback as before. However this it does
test that the NSUrlProtocol is registered correctly (what we care) and
the rest is largely only related the the OS (which is not the target
of our unit tests).
Hopefully fix https://github.com/xamarin/maccore/issues/1956
This optimization can be enabled when it's not possible to use the
managed linker (e.g. **Don't link**) or when the managed linker cannot
remove references to deprecated types that would cause an application
to be rejected by Apple.
References to the existing types will be renamed, e.g. `UIWebView` to
`DeprecatedWebView`, in every assemblies.
The type definition is also renamed (for validity) and all custom
attributes on the types and their members will be removed.
Code inside the members will be replaced with a
`throw new NotSupportedException ();`.
The msbuild test app `MyReleaseBuild` has been updated to test that the
optimization is working as expected (device builds are slow so reusing
this test has little impact in test time).
Basically the test ensure that `UIWebView` is used and cannot be removed
by the compiler (optimization) or the managed linker (since it's
referenced). Since the optimization is enabled then we can `grep` then
final `.app` directory to ensure there's no mention of `UIWebView` inside
any of the files that would be submitted.
The application can be run, by itself, and will turn green if OK, red if
`DeprecatedWebView` can't be found (skeleton replacement for `UIWebView`)
or orange if a `NotSupportedException` is thrown.
Finally introspection tests have been updated to skip over the deprecated
(and renamed) types. It should not be an issue right now, since this
optimization is not enabled by default, but it made testing easier.
so if we optimize (to remove references) the tests will be ignored.
Doing this based on define was wrong since we have different (and more)
configurations executed on devices,
`Default` property was using a nil-handle which is incorrect since
* we don't allow that (this is generally a bad sign)
* it does not map to `OS_LOG_DEFAULT`
Since `Default` was assigned in the type (static) constructor then
the whole type became unusable :(
Header `log.h` shows that the right definition requires us to load a
field and use it.
```
define OS_LOG_DEFAULT OS_OBJECT_GLOBAL_OBJECT(os_log_t, _os_log_default)
```
While `NULL` can actually be used for disabled (not exposed) by this
contradicting (nullability-wise) macro
```
define OS_LOG_DISABLED ((os_log_t _Nonnull)NULL)
```
Also adds unit tests. A more general tests for `.cctor` will be added
to introspection tests in a separate PR.
Fixes https://github.com/xamarin/xamarin-macios/issues/7959
This optimization can be enabled when it's not possible to use the
managed linker (e.g. **Don't link**) or when the managed linker cannot
remove references to deprecated types that would cause an application
to be rejected by Apple.
References to the existing types will be renamed, e.g. `UIWebView` to
`DeprecatedWebView`, in every assemblies.
The type definition is also renamed (for validity) and all custom
attributes on the types and their members will be removed.
Code inside the members will be replaced with a
`throw new NotSupportedException ();`.
The msbuild test app `MyReleaseBuild` has been updated to test that the
optimization is working as expected (device builds are slow so reusing
this test has little impact in test time).
Basically the test ensure that `UIWebView` is used and cannot be removed
by the compiler (optimization) or the managed linker (since it's
referenced). Since the optimization is enabled then we can `grep` then
final `.app` directory to ensure there's no mention of `UIWebView` inside
any of the files that would be submitted.
The application can be run, by itself, and will turn green if OK, red if
`DeprecatedWebView` can't be found (skeleton replacement for `UIWebView`)
or orange if a `NotSupportedException` is thrown.
Finally introspection tests have been updated to skip over the deprecated
(and renamed) types. It should not be an issue right now, since this
optimization is not enabled by default, but it made testing easier.
`Default` property was using a nil-handle which is incorrect since
* we don't allow that (this is generally a bad sign)
* it does not map to `OS_LOG_DEFAULT`
Since `Default` was assigned in the type (static) constructor then
the whole type became unusable :(
Header `log.h` shows that the right definition requires us to load a
field and use it.
```
define OS_LOG_DEFAULT OS_OBJECT_GLOBAL_OBJECT(os_log_t, _os_log_default)
```
While `NULL` can actually be used for disabled (not exposed) by this
contradicting (nullability-wise) macro
```
define OS_LOG_DISABLED ((os_log_t _Nonnull)NULL)
```
Also adds unit tests. A more general tests for `.cctor` will be added
to introspection tests in a separate PR.
Fixes https://github.com/xamarin/xamarin-macios/issues/7959
* [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
Co-authored-by: Alex Soto <alex@alexsoto.me>
* [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
- 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>
There are two important things to look at this:
1. That we do set the cookies that are present in the CookieContainer in
the request. That is, we need to set Cookie headers for all of them.
2. That if we receive a Set-Cookie from the server, the CookieContainer
gets correctly updated else we will have issues since we do not respect
the data sent from the server side.
Tests show both that we are setting the Cookie header and that we honour
the Set-Cookie header.
Fixes: https://github.com/xamarin/xamarin-macios/issues/5665
* 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.
* #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.
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`.
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.
* `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`
* `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.
* [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.
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.
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.
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.
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.
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
Rolf Bjarne Kvinge
Whitney Schmidt
Sebastien Pouliot
Alex Soto
Manuel de la Pena
monojenkins
Whitney Schmidt
Marius Ungureanu
Chris Hamons
Vincent Dondain
Jo Shields
michizhou