When the autoformatter runs into the '%...%' pattern in *.cs files, it
will re-format the text (to '% ... %'), but that breaks our text replacement
logic. So instead use a valid C# identifier as a replacement token, in which
case the autoformatter won't confuse our replacement logic.
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.
Unify the code for the following constructors:
* NSAttributedString (NSData data, NSDictionary options, out NSDictionary resultDocumentAttributes, ref/out NSError error);
* NSAttributedString (NSUrl url, NSAttributedStringDocumentAttributes options, out NSDictionary resultDocumentAttributes, ref/out NSError error);
* NSAttributedString (NSData data, NSAttributedStringDocumentAttributes options, out NSDictionary resultDocumentAttributes, ref/out NSError error);
These functions use 'ref' arguments instead of 'out' arguments for mobile
platforms (likely due to the generator not having proper 'out' parameter
support when these functions were implemented), so improve to use 'out'
parameters in XAMCORE_5_0 (and macOS, where they already use 'out'
parameters).
Also fix nullability.
Ref: https://github.com/xamarin/xamarin-macios/issues/15216
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:
[FAIL] Bug12221 : System.AggregateException : One or more errors occurred. (Response status code does not indicate success: 403 (Forbidden).)
----> System.Net.Http.HttpRequestException : Response status code does not indicate success: 403 (Forbidden).
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean )
at System.Threading.Tasks.Task.Wait(Int32 , CancellationToken )
at System.Threading.Tasks.Task.Wait()
at LinkSdk.AsyncTests.Bug12221() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/linker/ios/link sdk/AsyncTest.cs:line 25
at System.Reflection.MethodInvoker.InterpretedInvoke(Object , Span`1 , BindingFlags )
--HttpRequestException
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage , CancellationToken )
at LinkSdk.AsyncTests.<>c.<<LoadCategories>b__0_0>d.MoveNext() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/linker/ios/link sdk/AsyncTest.cs:line 16
One important detail is the change from calling 'Wait ()' to calling
'GetAwaiter ().GetResult ()': this is to avoid the AggregateException in the
stack trace above.
Fixes https://github.com/xamarin/maccore/issues/2570.
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*)
Unify the code for the following functions:
* NSAttributedString.GetData[FromRange]
* NSAttributedString.GetFileWrapper[FromRange]
These functions use 'ref' arguments instead of 'out' arguments for mobile
platforms (likely due to the generator not having proper 'out' parameter
support when these functions were implemented), so improve to use 'out'
parameters in XAMCORE_5_0 (and macOS, where they already use 'out'
parameters).
Also fix nullability.
Ref: https://github.com/xamarin/xamarin-macios/issues/15216
The 'initWithFileURL:options:documentAttributes:error:' was deprecated in iOS
9, and a new alternative (initWithURL:options:documentAttributes:error:) was
added. At the time, we implemented automatic detection of the current OS, and
would choose one version or the other depending on which was available.
We won't support anything below iOS 9 anymore, which means that keeping the
backwards-compatible constructor is useless, so just remove the corresponding
code and expose the new alternative directly.
On another note, this constructor uses a 'ref NSError' argument instead of an
'out NSError' on mobile platforms (likely due to the generator not having
proper 'out' parameter support when this constructor was implemented), so
improve to use 'out' parameters in XAMCORE_5_0 (and macOS, where it already
uses 'out' parameters).
Ref: https://github.com/xamarin/xamarin-macios/issues/15216
* Print the load average every 15 minutes. Also print a full process list if
the load average > 10.
* Print a full process list of the system every hour.
* Print a summary to stdout at the end of the test run.
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
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.
When the autoformatter runs into the '%...%' pattern in *.cs files, it
will re-format the text (to '% ... %'), but that breaks our text replacement
logic. So instead use a valid C# identifier as a replacement token, in which
case the autoformatter won't confuse our replacement logic.
Ignore certificate chain errors on bots in MessageHandlerTest.RejectSslCertificatesWithCustomValidationCallbackNSUrlSessionHandler.
Fixes https://github.com/xamarin/maccore/issues/2626.
There was a typo in the target name for creating the html report for .NET
('report-dotnet' vs 'dotnet-report').
Also print out the full path the html report when it's created, makes it much
easier to open the file from the command line because I can c&p the entire
path.
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>
Fixes this test in .NET 8:
AesCreate: System.Security.Cryptography.Algorithms,
Expected: String starting with "System.Security.Cryptography.Algorithms, "
But was: "System.Security.Cryptography, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
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.
The Xamarin.MacDev.Tasks.sln solution is built with dotnet, while other projects
are still built with msbuild. This becomes a problem when generating Errors.designer.cs,
because depending on the runtime the output is different.
This means that the Errors.designer.cs will sometimes randomly change (depending
on which project re-generated the file), leaving the file modified in git. This is
quite annoying, but it also breaks the api comparison, which depends on the build
not leaving modified files behind. So for now, we generate Errors.designer.cs separately
for Xamarin.MacDev.Tasks.sln to not conflict with the mtouch version.
Also fix capitalization in numerous places to be consistent (it's Errors.designer.cs,
not Errors.Designer.cs).
Fixes this:
Making all in frameworks
/bin/sh: .libs/tvos-arm64/FrameworksInRuntimesNativeDirectory1.dll: No such file or directory
make[2]: *** [.libs/tvos-arm64/FrameworksInRuntimesNativeDirectory1.dll] Error 1
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>
This test requires another platform to be enabled in addition to the current
platform being tested: that other platform is iOS when testing macOS, and
macOS for all other platforms.
This can be seen in the target frameworks for the referenced library projects:
MacCatalyst/Library.csproj: <TargetFrameworks>net$(BundledNETCoreAppTargetFrameworkVersion)-macos;netstandard2.1</TargetFrameworks>
iOS/Library.csproj: <TargetFrameworks>net$(BundledNETCoreAppTargetFrameworkVersion)-macos;netstandard2.1</TargetFrameworks>
macOS/Library.csproj: <TargetFrameworks>net$(BundledNETCoreAppTargetFrameworkVersion)-ios;netstandard2.1</TargetFrameworks>
tvOS/Library.csproj: <TargetFrameworks>net$(BundledNETCoreAppTargetFrameworkVersion)-macos;netstandard2.1</TargetFrameworks>
We can't process a common-fx.ignore file for a given framework if that
framework isn't included in any of the platforms we're building for.
Example: we can't process common-AppKit.ignore when only iOS is enabled,
because none of the errors listed in common-AppKit.ignore will be reported for
an iOS build.
Hopefully this fixes some of the recurrent build problems where we'd fail to
restore nuget packages.
Ref: https://github.com/xamarin/maccore/issues/2620
I wasn't able to execute ilrepack.exe with .NET, so that continues to be
executed with mono.
This makes it possible to run xtro consistently when not all platforms are
enabled.
Fixes https://github.com/xamarin/xamarin-macios/issues/12769.
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.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.
This PR adds support for Mac and MacCatalyst. Apple says that these
platforms are now supported; framework's headers does not specify them
but do not deny them either, so let's see what intro says about this.
I'm just creating this PR to test it against intro once we can build the
branch.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Rolf Bjarne Kvinge
Manuel de la Pena
Marius Ungureanu
Whitney Schmidt
VS MobileTools Engineering Service 2
Alex Soto
Haritha Mohan
Simon Rozsival
Israel Soto
Chris Hamons