We recently tried to fix NSDate's conversion operators with DateTime
(3c65ab1756), but unfortunately a corner case
was missed.
The new approach in the above-mentioned commit would get the individual
date/time components for a given date and use the appropriate constructor for
the other type to re-construct the date/time in question.
However, one case was missed: when converting from NSDate to DateTime, we'd
get a fractional number of milliseconds. This fractional number could be
something like 999.99 milliseconds, and when converting that to the int the
DateTime constructor expected for the number of milliseconds, then DateTime
would throw an exception, because the number of milliseconds could only be
between 0 and 999.
I've solved this by not using floating-point math in the computations. We're
now getting the number of nanoseconds from the NSDate (which is a natural
number, and represents the total number of nanoseconds less than a whole
second), and then converting that to the number of milliseconds, microseconds
and ticks that can be used with DateTime using integral math. Unfortunately
DateTime doesn't have a constructor that takes the remaining number of ticks
after all the other fields have been provided, but that can be added
afterwards.
I've also made a few other improvements:
* Improve the validation for the NSDate -> DateTime conversion to detect BC
dates by using the NSDate's Era component (to throw because DateTime only
supports AC dates). Also don't allow a tick later than year 10.000 (DateTime
only supports up to a tick before year 10.000) - but explicitly support
exactly year 10.000, and convert it to DateTime.MaxValue (this is because
due to precision errors NSDate can't actually express 'a tick before year
10.000', it ends up being rounded up to year 10.000 exactly). This means
there are no more magical values in the range validation checks.
* Increase precision in the DateTime -> NSDate conversion by starting with the
sub-second amount of ticks from the DateTime instance (instead of the number
of milliseconds). This allows us to compute the nanoseconds NSDate expects
with much higher precision.
* More tests!
Fixes this test:
MonoTouchFixtures.Foundation.DateTest.DateTimeToNSDate : 2 ms
[FAIL] Precision32022 : System.ArgumentOutOfRangeException : Valid values are between 0 and 999, inclusive.
Parameter name: millisecond
at System.DateTime..ctor (System.Int32 year, System.Int32 month, System.Int32 day, System.Int32 hour, System.Int32 minute, System.Int32 second, System.Int32 millisecond, System.DateTimeKind kind) [0x0002d] in <4d40c65adfc14d7fb19bad9310f3eb2a>:0
at Foundation.NSDate.op_Explicit (Foundation.NSDate d) [0x000b8] in <9cb1e1018c034b75ba5f4ed7b83ba2f2>:0
at MonoTouchFixtures.Foundation.DateTest.Precision32022 () [0x0000c] in <c44b5df5f7b84b69b737e9fd61bddaed>:0
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 <4d40c65adfc14d7fb19bad9310f3eb2a>:0
Fixes https://github.com/xamarin/maccore/issues/2632.
Date and time is difficult.
Ref: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
Ref: the rest of internet...
Fixes:
[FAIL] TestNSurlSessionHandlerCookieContainerSetCookie : Cookies received from server.
Expected: 1
But was: 0
at MonoTests.System.Net.Http.MessageHandlerTest.TestNSurlSessionHandlerCookieContainerSetCookie() in /Users/builder/azdo/_work/3/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 233
[FAIL] TestNSUrlSessionHandlerCookies : Failed to get managed cookies
Expected: True
But was: False
at MonoTests.System.Net.Http.MessageHandlerTest.TestNSUrlSessionHandlerCookies () [0x000aa] in /Users/builder/azdo/_work/3/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:144
Fixes https://github.com/xamarin/maccore/issues/2197.
Fixes:
MonoTouchFixtures.MediaAccessibility.ImageCaptioningTest
[FAIL] GetCaption : Ignore this failure when network is down
at MonoTouchFixtures.MediaAccessibility.ImageCaptioningTest.GetCaption() in /Users/builder/azdo/_work/3/s/xamarin-macios/tests/monotouch-test/MediaAccessibility/ImageCaptioningTest.cs:line 36
Ref: https://github.com/xamarin/maccore/issues/2088.
Fixes:
MonoTouchFixtures.VideoToolbox.VTCompressionSessionTests.TestCallback
[FAIL] TestCallback(True) : timed out
Expected: True
But was: False
at MonoTouchFixtures.VideoToolbox.VTCompressionSessionTests.TestCallback(Boolean stronglyTyped) in /Users/builder/azdo/_work/3/s/xamarin-macios/tests/monotouch-test/VideoToolbox/VTCompressionSessionTests.cs:line 171
[FAIL] TestCallback(False) : timed out
Expected: True
But was: False
at MonoTouchFixtures.VideoToolbox.VTCompressionSessionTests.TestCallback(Boolean stronglyTyped) in /Users/builder/azdo/_work/3/s/xamarin-macios/tests/monotouch-test/VideoToolbox/VTCompressionSessionTests.cs:line 171
at InvokeStub_VTCompressionSessionTests.TestCallback(Object, Object, IntPtr*)
PKPassLibrary.GetPasses randomly returns null for no apparent rhyme or reason
on our bots, so just ignore the test in that case.
Maybe if someone can reproduce locally one day we'll be able to investigate
and figure out what's happening.
Fixes https://github.com/xamarin/maccore/issues/2598.
Ignore certificate chain errors on bots in MessageHandlerTest.RejectSslCertificatesWithCustomValidationCallbackNSUrlSessionHandler.
Fixes https://github.com/xamarin/maccore/issues/2626.
There was a PR race:
1. I created a PR to autoformat monotouch-test code.
2. Another PR added incorrectly formatted code to monotouch-test.
3. The first PR was merged, everything was fine.
4. The second PR was merged (it was green) - but its code hadn't been
autoformatted.
5. Now there's incorrectly formatted code in the repo, which will show up in
every new PR.
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Update conversions from `NSDate` to `DateTime` and `DateTime` to `NSDate` to use date components instead of `SecondsSinceReferenceDate`.
The number of seconds since reference date is inconsistent between `NSDate` and `DateTime`. See the associated bug - converting `DateTime` 1/1/1 to `NSDate` ends up giving you an `NSDate` a couple days off :(
Fixes https://github.com/xamarin/xamarin-macios/issues/6993.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Objective-C has an optimization where creating an empty dictionary would
return the same instance every time (probably to a constant empty
dictionary).
This causes a problem with how we've bound generic dictionaries, because
all
empty dictionaries would have the same native handle, even if we'd bound
them
with different managed types.
This surfaces in unfortunate ways when we try to look up a managed
instance
given a native handle, we find that we already have a managed instance,
but
the managed instance is of the wrong type.
Example code:
var a = new NSDictionary ();
var b = new NSDictionary<NSString, NSString> ();
var c = new NSDictionary<NSString, NSObject> ();
Console.WriteLine ($"a: 0x{a.Handle:X}");
Console.WriteLine ($"b: 0x{b.Handle:X}");
Console.WriteLine ($"c: 0x{c.Handle:X}");
would produce something like:
a: 0x0x7fff80821080
b: 0x0x7fff80821080
c: 0x0x7fff80821080
now for this code:
Runtime.GetNSObject<NSDictionary<NSString, NSString>> (b.Handle)
it would throw an exception like this:
Unable to cast object of type
'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSObject]]'
to type
'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSString]]'
because we'll have the 'c' object (with type `NSDictionary<NSString,
Object>`)
in our dictionary of native handles -> managed instances, and that's not
compatible with the desired return type from GetNSObject
(`NSDictionary<NSString, NSString>`)
This likely happens with all the non-mutable collection types we have a
generic version of (NSArray, NSDictionary, NSOrderedSet, NSSet).
Fixes https://github.com/xamarin/xamarin-macios/issues/16378.
Fixes https://github.com/xamarin/xamarin-macios/issues/13704.
This PR is somewhat simpler to review by ignoring whitespace:
https://github.com/xamarin/xamarin-macios/pull/16491/files?w=1
Backport of #16491
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Objective-C has an optimization where creating an empty dictionary would
return the same instance every time (probably to a constant empty dictionary).
This causes a problem with how we've bound generic dictionaries, because all
empty dictionaries would have the same native handle, even if we'd bound them
with different managed types.
This surfaces in unfortunate ways when we try to look up a managed instance
given a native handle, we find that we already have a managed instance, but
the managed instance is of the wrong type.
Example code:
var a = new NSDictionary ();
var b = new NSDictionary<NSString, NSString> ();
var c = new NSDictionary<NSString, NSObject> ();
Console.WriteLine ($"a: 0x{a.Handle:X}");
Console.WriteLine ($"b: 0x{b.Handle:X}");
Console.WriteLine ($"c: 0x{c.Handle:X}");
would produce something like:
a: 0x0x7fff80821080
b: 0x0x7fff80821080
c: 0x0x7fff80821080
now for this code:
Runtime.GetNSObject<NSDictionary<NSString, NSString>> (b.Handle)
it would throw an exception like this:
Unable to cast object of type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSObject]]' to type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSString]]'
because we'll have the 'c' object (with type `NSDictionary<NSString, Object>`)
in our dictionary of native handles -> managed instances, and that's not
compatible with the desired return type from GetNSObject
(`NSDictionary<NSString, NSString>`)
This likely happens with all the non-mutable collection types we have a
generic version of (NSArray, NSDictionary, NSOrderedSet, NSSet).
Fixes https://github.com/xamarin/xamarin-macios/issues/16378.
Fixes https://github.com/xamarin/xamarin-macios/issues/13704.
Implemented the interfaces for NSOperatingSystemVersion, can now compare
instances and check for equality using operators.
Fixes#15721
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Looks like some of these tests are working in the simulator now.
I also confirmed that ARReferenceObjectTest.MarshallingTest test should be
ignored in the simulator by verifying that Xcode gets the same behavior we do
(i.e. it doesn't work).
Fixes https://github.com/xamarin/xamarin-macios/issues/9531.
For NSArray, implement:
* A ToArray () method that returns an NSArray[].
* A ToArray<T> () method that returns a T[].
* The IEnumerable<NSObject> interface.
For NSArray<T>, implement:
* A ToArray () method that returns a T[].
This should make NSArray much better to work with from managed code.
* Change EnumerateGateways to use the 'static_EnumerateGatewaysHandler'
callback. It looks like this was a c&p error, since the
'static_EnumerateGatewaysHandler' callback was implemented, just never
referenced anywhere.
* Add an overload to EnumerateGateways and EnumerateInterfaces that takes a
callback that returns a bool indicating whether the enumeration should
continue. This mirrors the native API.
* Obsolete the EnumerateGateways and EnumerateInterfaces overloads that take a
void callback (and remove in XAMCORE_5_0).
* Add a test for EnumerateGateways that works (the previous failed, but never
asserted the failure, so it would just silently time out).
Fixes https://github.com/xamarin/xamarin-macios/issues/13772.
Context: dotnet/runtime#68610
Context: https://github.com/xamarin/xamarin-android-tools/commit/0be567a9
In Mono and .NET prior to .NET 8, the
[`System.Environment.SpecialFolder`][0]`.Personal` enum value would refer to
`$HOME` on Unix platforms.
This will be changing in .NET 8, such that
`Environment.SpecialFolder.Personal` will instead refer to
`$XDG_DOCUMENTS_DIR` (if set) or `$HOME/Documents`. This is for "semantic
compatibility" with .NET on Windows.
Replace usage of `Environment.SpecialFolder.Personal` with
`Environment.SpecialFolder.UserProfile`, so that our code continues to work as
expected under .NET 8.
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-6.0
This PR has the AVKit updates and introduces the AVRouting bindings that
are interconnected with AVKit
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Rolf Bjarne Kvinge
Manuel de la Pena
Marius Ungureanu
Whitney Schmidt
VS MobileTools Engineering Service 2
Haritha Mohan
Simon Rozsival
Israel Soto
TJ Lambert