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>
Rolf Bjarne Kvinge
Marius Ungureanu
Whitney Schmidt
VS MobileTools Engineering Service 2
Manuel de la Pena
Alex Soto
Haritha Mohan