Rename the public fields in CGAffineTransform to:
* Follow our naming convention (public API should always start with an
upper-case letter).
* Use the same names as Apple's version to ease porting Swift/Objective-C
code.
Fixes https://github.com/xamarin/xamarin-macios/issues/13494.
* Remove obsolete API from .NET.
* Change API marked with XAMCORE_4_0 due to naming problems to be in .NET.
* Change API marked with XAMCORE_4_0 due to using non-generic NSDictionary to be
in XAMCORE_5_0 instead (yay!). This is because of #13704, which can make using
generic NSDictionary in API buggy, and I feel it's a bit too risky to change this
for .NET with the time we have available (no time to fix#13704). Additionally,
moving this to XAMCORE_5_0 makes it possible to keep grepping for XAMCORE_4_0 to
see what's left. Update all the CoreData API to be better as defined by our XAMCORE_4_0
define. Mostly using generic NSSet/NSDictionary types instead of the non-generic
ones, and other misc naming improvements.
* Change API marked with XAMCORE_4_0 due to both of the above to do both of the
above - add a version of the naming issue fixed for .NET + a version with the generic
dictionary for XAMCORE_5_0.
* Implement a column-major version of SCNMatrix4 in .NET to match native code.
* This was done by copying the existing SCMatrix4 implementation, and modify it
as required (doing it with conditional compilation in the same file turned out
to be quite messy, so I opted for using different files for legacy Xamarin and
.NET).
* There was one major change: the matrix inversion algorithm is new (copied from
.NET instead), because the legacy Xamarin version showed strange results with
some test values.
* Add setters for SCNMatrix4.Column[0-3] for legacy Xamarin to match the .NET API.
* Add CreateFromColumns methods for legacy Xamarin to match the .NET API.
* Add tests for all the new API.
Fixes https://github.com/xamarin/xamarin-macios/issues/4652.
It's our own enum, and all the API using it have been obsoleted/removed.
There doesn't seem to be any other usage of it on GitHub either (only our own
source code and documentation).
Also remove the Unscaled field, it's removed from the headers, and it was
deprecated before the earliest macOS version we support.
Also also fix a few xtro issues.
* Fix `CGColorConversionInfoTriple` name (missing initial `C`)
* Rename `RectangleFExtensions` to `CGRectExtensions` since the former
name has not been around for a while
* Remove API naming mistakes (already under XAMCORE_4_0)
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Public fields shouldn't start with a lower-cased letter.
Also provide public properties in legacy Xamarin so that we can write
identical code for both, and obsolete the lower-cased fields.
AudioUnit needs a GCHandle in the input callback, which means we have to create it
when SetInputCallback is called (like we already do for SetRenderCallback).
Fixes https://github.com/xamarin/xamarin-macios/issues/13637.
* First version cecil test
* Add missing net6 platform assemblies
* Make it work for Catalyst
* Add namespace switch and clean up code
* Update based on feedback
* Update based on feedback
* Update based on feedback
* Make test pass by default
* Fix bgen tests by fixing GetRefNuGetName
* Update based on feedback
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
* [ObjCRuntime] Fix the DisposableObject.Owns property to return the correct value. Fixes#13646.
Ops...
Also add tests to avoid more oopses.
Fixes https://github.com/xamarin/xamarin-macios/issues/13646.
* Update tests/monotouch-test/AudioToolbox/AudioConverterTest.cs
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
* [Xcode13.2] Bump to Xcode 13.2 RC (#13497)
* [Xcode13.2] Bump to Xcode 13.2 Beta 2
Breaking changes addressed for legacy
* HomeKit
* CallKit
* CoreLocation
* [xcode13.2] Bump to Xcode 13.2 RC and apply feedback
* [AppKit] Fix missing Notifications
* Fix xtro
* [xcode13.2] Bump versions and use stable Xcode 13.2
* [monotouch-tests] Make TestAddingByComponents work on the last day of the year
Happy New Year!!
* NO BOM PLZ!
AutoGeneratedName was a toggle to implement a certain (correct) behavior,
while at the same time not cause breaking changes.
Now that we can do breaking changes in .NET, we can remove the toggle (i.e.
the property), and just always do the right thing (that is: automatically
generate a _unique_ Objective-C name for Model classes, unless a name is
specified manually).
Ref: https://github.com/xamarin/xamarin-macios/issues/5107
We're copying files differently to the bundle now, and we end up doing less
when not building on a Mac, which is why we're not copying Xamarin.iOS.dll
anymore.
Once upon a long time ago we decided to mark the properties in the
UITextInputTraits protocol as required in our API definition, because that way
we'd inline these properties in any class that implemented the
UITextInputTraits protocol, which made calling these properties much easier.
At a later point, we implemented better support for protocols, and now we
automatically generate extension methods for such properties (a corresponding
Get/Set method for the get/set property accessors), so we don't need these
inlined properties anymore.
However, removing them would be a breaking change, so we were stuck with these
redundant inlined properties, until .NET came along.
Ref: 0e80570863
Fixes https://github.com/xamarin/xamarin-macios/issues/5831.
Take into account any Bind attributes on optional property getters and setters
on protocols when generating the Get* and Set* extension methods, so that we
use the right selector.
Fixes https://github.com/xamarin/xamarin-macios/issues/12727.
Don't add FileNativeReferences to the main libraries to link with, because we
pass that list of main libraries to the LinkNativeCodeTask, and we're already
passing the FileNativeReferences for a different task parameter.
This means that we end up adding the file native reference twice to the linker
arguments, and that's wasteful. It can also cause problems if those linker
arguments aren't always computed in the same way (once as a relative path,
once as an absolute path for instance).
Fixes https://github.com/xamarin/xamarin-macios/issues/13503.
Once upon a time there was a single VTCompressionSession.Create method, which
was [driving users insane][1] - they had to manually call CFRetain to avoid
crashes! What an abomination!!
Insane users are clearly not happy users, and we wanted happy users, so time
and effort went into creating a solution: a new Create overload was devised
and [implemented][1], taking extreme care to not break our brave and insane
existing users who had to manually call CFRetain. Because the fix would break
existing users - the now extraneous CFRetain would mean that their apps would
leak memory. *A lot* of it! That's bad, so we decided to make sure that didn't
happen.
Of course, dear old Murhpy wanted a say, so the new Create overload didn't do
as intended. In fact, it had the same insane behavior the old Create overload
had! Ops.
But Murphy decided to have even more fun: the changes were so buggy, that they
in fact fixed the old Create overload! Which from now on wouldn't require the
horrendous manual CFRetain calls... and effectively introducing the leak the
fix was trying so hard to not introduce.
Oh dear Murphy.
Of course he had another trick up his sleeve: in our extreme efforts to help
our users, we added an Obsolete attribute that would tell people to use the
new Create overload.
Let that sink in for a moment: we had an Obsolete attribute on a function that
was (now) perfectly fine, telling users to use a function that was broken.
To get the correct behavior, users would now have to to remove their manual
CFRetain calls, and ignore the obsolete warning on the old (and correct)
Create overload which told users to use the new (and buggy) Create overload.
In other words: still insanity, just a slightly different flavor.
Murphy had a field day!
Time went by, and eventually a sane enough user [reported the insanity to
us][2]. Even better: the user actually provided a fix! Truly, we have some
amazing users.
Unfortunately, the user didn't have access to our code history, and thus was
obviously not able to see the whole picture, and the fix ended up being
incorrect.
Unrelated lesson learned: don't forget your history, otherwise you'll end up
repeating mistakes from the past.
So now came the problem: how to fix all the APIs? In a way that didn't make
our users' existing apps just suddenly start crashing or leaking?
There really was no way, so nothing really happened for quite a while.
Then, an opportunity presented itself: we'd be able to do [widespread breaking
changes][3].
So, hoping that Murphy stays away this sunny winter day, I'm changing both the
new and the old Create overloads to do the right thing. But only in .NET,
where we can do breaking changes! Or at least that's my intention. I've tried
to stave off our dear old friend by adding his arch enemy: unit tests. Which,
of course, Murphy couldn't stay away from, but it seems adding a few
Thread.Sleep calls makes him bored enough to stay away. Hopefully for good...
[1]: 66c50b9a17
[2]: https://github.com/xamarin/xamarin-macios/pull/2070
[3]: https://github.com/xamarin/xamarin-macios/issues/13087
* Capture evaluation output, and write it all to the terminal when something
goes wrong. This way we can see the entire output next to the failure (often
there's a lot of stuff written to the terminal from different threads, and
this way we get all that matters written together).
* Only evaluate one project at a time, to avoid overloading the machine.
* Only execute `git ls-files` once at a time, to avoid overloading the machine.
* Bump evaluation timeout to 5 minutes.
* Also increase the time for git to list files in a directory to 60 seconds.
Hopefully this will fix errors like this:
* `Unable to evaluate the property OutputPath, build failed with exit code 0. Timed out: True`
* `System.Exception: Failed to list the files in the directory /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test3403 (TimedOut: True ExitCode: 0)`
This fixes a problem where we'd build the same project reference from
dotnet-shared.csproj in parallel, and each build would stomp on eachother
(because we'll now clone the project references in dotnet-shared.csproj).
This als required updating project files to use MSBuildThisFileDirectory
instead of MSBuildProjectDirectory, which makes it easier for xharness to
inline/process these files, because MSBuildThisFileDirectory is easy to know
when processing a file, while MSBuildProjectDirectory depends on the calling
project, which complicates matters significantly.
A fix in MonoTouch.Dialog was also required.
New commits in migueldeicaza/MonoTouch.Dialog:
* migueldeicaza/MonoTouch.Dialog@59fbf5b [dotnet] Shared project files don't need the DefaultTargets/ToolsVersion/xmlns attributes.
Diff: 4d0e0a9a5f..59fbf5bb1b
Fixes https://github.com/xamarin/maccore/issues/2527.
If NSFunctionKey isn't in Mac Catalyst in legacy Xamarin, it shouldn't be in
.NET either, so adjust the conditional logic accordingly.
Also make the NSFunctionKey enum a non-native enum in .NET, like it's in the
headers.
Remove Runtime.Arch and ObjCRuntime.Arch from Mac Catalyst, because they don't
apply for a Mac Catalyst app (which is neither a simulator environment, nor a
device environment).
This means that code using these APIs will have to be re-evaluated to
determine what's the correct behavior for Mac Catalyst.
Also update our tests accordingly.
Fixes https://github.com/xamarin/xamarin-macios/issues/10312.
* Change dotnet-linker to only care about whether we're actually trimming anything or not.
* Allow LinkMde/MtouchLink to not be set if TrimMode is set.
* Detect if any assemblies are linked or not by checking the global TrimMode
property + any TrimMode properties on assemblies.
Fixes https://github.com/xamarin/xamarin-macios/issues/13518.
named 'Info.plist', and assume that's the app manifest.
That doesn't quite work when we end up with multiple 'Info.plist' entries in any
of those item groups (one example being a framework as a BundleResource - all frameworks
have an Info.plist, and there's no good way to distinguish what the developer's intention
was).
So:
1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest
detection.
2. Add a public 'AppBundleManifest' property that specifies the app manifest
(this is just a renamed version of our previously private '_AppManifest' property).
This makes it possible for app developers to:
* Disable automatic app manifest detection.
* Still have an app manifest by specifying it manually.
* Disable automatic app manifest detection, but also not specify an app manifest
manually (so no custom app manifest at all).
Also:
* Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing
with the new 'AppBundleManifest' property.
Symlinks to directories are treated the same as other symlinks (as files), not
as directories. This way we don't end up re-creating a directory hierarchy
when we only have to create a symlink.
* Change all XAMCORE_4_0 conditions to NET conditions.
* Add numerous Release attributes that xtro started complaining about.
* Misc other minor API changes/updates.
We are in a situation where:
1. .NET MAUI is still in preview
2. We need dotnet/runtime fixes for MAUI, but we don't necessarily want all fixes to go into the .NET 6 service release.
The solution is to simplify use different builds/packs from dotnet/runtime.
Ref: https://github.com/xamarin/xamarin-android/pull/6542
* [tools] Unify Application.link_flags and Application.gcc_flags from mtouch and mmp into Application.CustomLinkFlags.
* [tests] Update mtouch tests according to mtouch changes.
* [ObjCRuntime] Remove deprecated availability attribute API from .NET.
They're quite useful for binding code though, so instead of removing them completely,
make them binding-only attributes (like numerous other binding attributes we have)
for .NET.
* [src] Remove removed attributes from the list of attributes that should be removed by the linker.
* [tests] Update tests to not use the old attributes for .NET.
There can't be any files in the root directory of the app bundle for macOS and
Mac Catalyst, otherwise code signing will fail. The problem is that Mono will
create a crash report in the current directory if the process crashes, and the
current directory is the root directory of the app bundle, which means that if
running an app crashes, the next build will likely fail because of the crash
report.
We had logic to detect this and remove any crash reports, but our crash report
detection pattern wasn't good enough and let some files through. This PR
updates that pattern, and also improves the code to report warnings for any
other files in the app bundle's root directory.
* Remove System.nint and System.nuint from .NET
* Add support for C#'s nint/nuint types to the generator.
* Accept IntPtr/UIntPtr as target types for BindAs attributes for NSNumber conversions.
* Fix a few APIs to take/return NativeHandle instead of IntPtr.
Fixes https://github.com/xamarin/xamarin-macios/issues/10508.
* [monotouch-test] Ignore a few tests in non-ARM64 simulators.
Some tests fail when running on an M1, but in a x64_86 mode, so just ignore
those unless we're running on ARM64 (this will currently exclude them on
x86_64 hardware too, but that'll eventually not be a problem anymore when
there's no more x86_64 hardware, and just checking for ARM64 is easier than
checking for x86_64 mode on an ARM64 CPU).
* Make more legacy projects unsafe.
* [Foundation] Make numerous CFArray and NSArray APIs take/return NativeHandle instead of IntPtr.
* [src] Fix a lot of other cases of IntPtr -> NativeHandle.
This is just fallout from the CFArray/NSArray in the previous commit.
Check for the x64 version of .NET to see if it's installed if the default
dotnet location doesn't exist (the x64 version will exist on an ARM64 mac when
installing the x64 version of .NET).
Also allow the .NET unit tests to be executed using any recentish version of
.NET.
Add a new struct, ObjCRuntime.NativeHandle, which will be used to represent
native handles for .NET (instead of using IntPtr). The main purpose is to be
able to use 'nint' as a number in API while not being prevented from using
native handles as well.
One example is NSMutableString, which has a constructor that takes a single
'nint capacity' parameter. With this change, we'll also be able to have a
constructor that takes a native handle in .NET - otherwise we'd have two
constructors with the same signature, because a C# 'nint' is just an 'IntPtr'.
This change required numerous changes pretty much everywhere. The work is
split up in commits as well as I was able to, and each commit explains what it
does.
Fixes https://github.com/xamarin/xamarin-macios/issues/13126.
* Make the .NET project files for BundleResources and EmbeddedResources follow
the pattern of all the other test projects.
* Move the LangVersion and AllowUnsafeBlocks propertieso to the shared project
file.
Change the logic to detect if an API is available to:
* First check if there are any applicable UnavailableOSPlatform attributes,
and only if an applicable attribute is found, then state that the API is
unavailable (we can't ascertain that an API is available from an
UnavailableOSPlatform attribute, only that it's unavailable).
* Once we know there are no applicable UnavailableOSPlatform attributes, we go
on to check for applicable SupportedOSPlatform attributes, and if one is
found, then we can say whether the API is available or not.
* If neither attributes were found, and we're building for Mac Catalyst, then
repeat the two above checks for iOS instead.
* If still nothing, then assume the API is available (while incorrect, it's
how our attributes are currently implemented).
This fixes introspection showing numerous test failures on older OS versions,
because we were detecting availability wrong - we were assuming that if
there's an UnavailableOSPlatform attribute whose version didn't match the OS
version, that the API was available (test case that proves this logic is
incorrect: OS version = 1.0, API introduced in 2.0, API unavailable in 3.0
- we'd detect that OS version 1.0 < unavailable in 3.0, and say "yay, we're
not unavailable, so we must be available!").
This turned out a bit complicated, because we're lipo'ing together both the simulator
and device slices, and that doesn't work anymore when ARM64 is both a simulator and
a device architecture. The solution is a custom lipo logic that doesn't include the
simulator version of the ARM64 architecture in the final binary.
* [tests] Create a libtest.xcframework and libtest2.xcframework
* [tests] Make bindings-test and bindings-test2 use an xcframework instead of plain static library
* [msbuild] Add support for xcframeworks with static libraries in them.
* List the frameworks libtest needs.
* [tests] Update .NET unit tests according to test project changes.
* [tests] Add new test to verify that packing an old-style binding project doesn't work.
* [src] Remove the Xamarin.iOS.dll reference assembly for Mac Catalyst.
Xamarin.iOS.dll won't be compatible with Mac Catalyst in .NET 6 (because there
won't be any backwards compatibility), so we don't need the assembly that has
type forwarders to Xamarin.MacCatalyst.dll.
* Bump MonoTouch.Dialog
New commits in migueldeicaza/MonoTouch.Dialog:
* migueldeicaza/MonoTouch.Dialog@4d0e0a9 Remove usages of UIWebView when compiling for Mac Catalyst.
Diff: 5a05c6912e..4d0e0a9a5f
* [tests] There's no NSFileProviderPage in Mac Catalyst.
* [tests] Fix CBUUID link sdk test to work correctly on Mac Catalyst.
* [dotnet] Show an error if an app developer tries to publish a simulator architecture.
* We can't publish a simulator build, so show an error in that case.
* We can't change the default runtime identifier when publishing (to a
publishable runtime identifier), because by the time we know we're
publishing, it's too late to change the runtime identifier. This means that
it'll be required for app developers to specify a runtime identifier when
publishing to a mobile platform, since the current default runtime
identifier is for a simulator build.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/12997.
* Fix typo and improve naming.
* [dotnet] Don't use '_UsingDefaultRuntimeIdentifier', it's already used elsewhere in .NET
* [src] Add missing availability attributes in a few places.
* [src] Don't add availability attributes to error enums.
* [introspection] Change version check for Mac Catalyst to be 'greater than'.
We have a tests that verifies that the availability attributes for an API
doesn't state that the API was deprecated before or when it was introduced.
This sounds reasonable, except that Apple has introduced and deprecated entire
frameworks in the same Mac Catalyst version (probably because Apple decided to
port an already deprecated framework to Mac Catalyst).
Our test for this scenario was a bit too eager; this change will make it so
that (for Mac Catalyst only), we accept APIs that are introduced and
deprecated in the same Mac Catalyst version (not not APIs that were deprecated
before they were introduced).
* [AppKit] Change NSTextViewDelegate.DraggedCell to use the recommended signature for .NET
The 'textView:draggedCell:inRect:event:' selector has been deprecated since
macOS 10.6, so just replace this with the recommended alternative.
* [generator] Make sure code compiles for parameter names that match C# keywords.
Verifies that:
* There shouldn't be any (IntPtr) or (IntPtr, bool) constructors.
* The (NativeHandle) or (NativeHandle, bool) constructors should not be public.
* The constructors correctly chain to the base constructor according to our usual
pattern: the (IntPtr) ctor must chain to the self/base (IntPtr, bool) constructor
passing 'false' for the owns parameter.
* The constructors don't have any extra code in them (barring a few exceptions).
* There should be no public (IntPtr) constructor, at most there should be a
protected one for NSObject subclasses. There should be no such constructors
for classes that just implement INativeObject.
* There should be no public (IntPtr, bool) constructor at all, they should all
be internal.
* If changing the visibility or removing the ctor is a breaking change, then
make it happen for .NET only.
* We don't want availability attributes for enums that represent errors,
because the code would end up unnecessarily complex to avoid warnings.
* We even have other tests to verify as much (cecil tests).
* Remove the watchOS project, we don't support watchOS for .NET at the moment.
* Rename shared.targets to shared.csproj to match all the other test projects.
* Move a bit more code into the shared project file (shared.csproj).
* Add a Makefile for each platform.
The former has been removed from the headers, so it's thoroughly deprecated,
and the latter is no longer needed anymore since it was only used by the
former.
Delete the 'osx.pending' file, it's not used. It looks like it should have
been removed in fffaba2414 (where the *.pending
files for the other platforms were removed).
Otherwise we'll create a CGImage with a zero Handle, which is usually not the
right thing to do. Still, keep the old behavior for legacy Xamarin for the
sake of backwards compat.
* Use proper dependency tracking, so that we'll only rebuild what needs to be rebuilt
when rebuilding. This required using a few stamp files. It also improves parallel
builds.
* Remove *.raw files before running xtro-sharpie, and only for the current platform.
This makes sure rebuilds of just some of the platforms work correctly (because
the *.raw files for other platforms are still around when needed).
* Build the u2todo project file instead of manually calling csc.
* LAContext.MaxBiometryFailures is available in macOS, just deprecated, so mark
it as such.
* Remove deprecated code from .NET.
* Update xtro definitions.
Fixes:
MonoTouchFixtures.UIKit.FontTest
CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.
[FAIL] NullFonts : WithSize
Expected: not null
But was: null
at MonoTouchFixtures.UIKit.FontTest.NullFonts() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/UIKit/FontTest.cs:line 165
* [tools] Extract the logic to parse OSPlatformAttribute platform names to a separate file/class.
* [introspection] Migrate .NET code to use the new .NET-style availability attributes.
This also means using the 'ApplePlatform' enum instead of the 'PlatformName'
enum, because the latter will be removed in .NET.
* [FileProvider] Exclude some deprecated API from .NET.
* [AVFoundation] Adjust availability attribute for AVCaptureStillImageOutput.HighResolutionStillImageOutputEnabled.
* Update tests.
* Unify the signed and unsigned implementations. We lose some type-safety (because
we have to use 'object' as the unifying type between long and ulong), but we minimize
code duplication, so the code becomes easier to maintain.
* Add an additional check for managed enum values that show up in the native header,
but aren't available on the current platform.
This makes it easier to iterate over all the *_SDK_VERSION variables in
template code, because they're all named using the standard platform names we
use elsewhere.
There are numerous checks that don't make much sense to report for deprecated
API, so skip those. This also required updating a few .ignore and .todo files.
* [tools] HomeKit was added to Mac Catalyst in 14.0, so mark it as such.
Fixes this launch crash when executing on macOS 10.15:
dyld: Library not loaded: /System/iOSSupport/System/Library/Frameworks/HomeKit.framework/Versions/A/HomeKit
Referenced from: /Users/runner/work/1/s/artifacts/mac-test-package/tests/./linker/ios/dont link/dotnet/MacCatalyst/bin/Debug/net6.0-maccatalyst/maccatalyst-x64/dont link.app/Contents/MacOS/dont link
Reason: image not found
* [introspection] Skip the default SKView constructor on all platforms, not only macOS.
Fixes a crash on Mac Catalyst.
* Fix SKView skipping logic.
* Mac.Is32BitMavericks is always false (we only run on 64-bit macOS), so remove corresponding code.
* Mac.IsElCapitanOrHigher is never used; remove
* Remove a few unused Mac.Version_* fields.
The logic seems to want to verify MPSPredicate on maOS 10.14, but not on macOS
10.15+. But checking for macOS 10.14 is always successful on macOS 10.15+,
which means that we can't check for macOS 10.14 before checking macOS 10.15.
So I moved the macOS 10.14 check to after the macOS 10.15 check, but that made
the macOS 10.14 check redundant, because both branches of the condition did
the same thing, so I removed the whole check.
Fixes this introspectionf failure:
[FAIL] DefaultCtorAllowed : 1 potential errors found in 1387 default ctor validated:
Default constructor not allowed for MetalPerformanceShaders.MPSPredicate : Could not initialize an instance of the type 'MetalPerformanceShaders.MPSPredicate': the native 'init' method returned nil.
* Stop using AvailabilityBaseAttribute, this type will disappear in .NET.
* Handle System.Runtime.Versioning.SupportedOSPlatformAttribute instead of our own availability attributes for .NET.
* Add tests (somewhat hacked together, but they work).
The FSEventStreamCreate method takes a pointer to a structure with context information,
which contains a user-defined pointer value in addition to a few callbacks. Previously
we were passing the GCHandle as a pointer to this structure, which is obviously quite
wrong (as evidenced by a native crash when calling FSEventStreamCreate).
Changes:
* Modify the code to provide the expected context structure instead with the GCHandle
as a field in that structure.
* Add a release callback to the context structure to release the GCHandle.
* This avoids the need for storing the GCHandle as a field in the FSEventStream instance.
* It also avoids also the need for overriding Dispose to release said GCHandle.
* Modify the callback code to use the [UnmanagedCallersOnly] attribute for .NET
(ref: #10470).
This was a regression introduced in 8c99bdc9ad.
Fixes https://github.com/xamarin/xamarin-macios/issues/13325.
The supposed handle for system sounds is an uint, which does not match the
IntPtr handle INativeObject uses, so remove the INativeObject interface from
the SystemSound class.
* Remove the SslCipherSuite enum from .NET, it's complicated to implement
correctly on macOS for both x64 and arm64, and it's also obsolete, so just
remove it.
* Change the type for NSUrlSessionTaskTransactionMetrics.NegotiatedTlsCipherSuite
to be TlsCipherSuite instead of SslCipherSuite for .NET (this is in fact the
correct value according to the headers).
Fixes https://github.com/xamarin/xamarin-macios/issues/11498.
* Change all XAMCORE_4_0 defines to NET defines to get the new API version in
.NET.
* Remove some dead code.
* Change all the old-style [Availability] attributes to new-style [Obsoleted]
or [Deprecated].
* Adjust tests.
Fixes when building with XAMCORE_4_0:
> uikit.cs(6775,3): error CS0246: The type or namespace name 'UITextWritingDirection' could not be found (are you missing a using directive or an assembly reference?)
> uikit.cs(6597,3): error CS0246: The type or namespace name 'UITextWritingDirection' could not be found (are you missing a using directive or an assembly reference?)
> uikit.cs(6601,41): error CS0246: The type or namespace name 'UITextWritingDirection' could not be found (are you missing a using directive or an assembly reference?)
Fixes https://github.com/xamarin/xamarin-macios/issues/6573.
* Make CGPDFObject a common subclass for the CGPDF[Array|Dictionary|Stream]
classes, and keep the object lifetime code there.
* Enable nullability and fix code accordingly.
* Use 'is' and 'is not' instead of '==' and '!=' for object identity.
* Use 'nameof (parameter)' instead of string constants.
* Make any (IntPtr) constructors internal for .NET
* Simplify block creation code a bit.
* [CGImageMetadataTag] Subclass NativeObject + numerous other code updates
* Subclass NativeObject to reuse object lifetime code.
* Enable nullability and fix code accordingly.
* Use 'is' and 'is not' instead of '==' and '!=' for object identity.
* Use the null-safe NativeObjectExtensions.GetHandle extension method to get
the handle instead of checking for null (avoids some code duplication).
* Use 'nameof (parameter)' instead of string constants.
* Use the 'Runtime.GetNSObject<T> (IntPtr, bool)' overload to specify handle
ownership, to avoid having to call NSObject.DangerousReleaes manually later.
* Remove the (IntPtr) constructor for .NET
* Fix nullability attribute.
* [tests] Don't dispose a property value.
It ends up being the object instance we've stored elsewhere, which we don't
expect to be disposed.
* [ObjCRuntime] Add a non-deprecated internal system-version checking API and use it everywhere.
The PlatformHelper class is deprecated, so implement a new version that isn't
deprecated, and which shares a similar API between all platforms - the Check*
methods includes the name of the platform, because that makes it clearer which
version we're talking about from the call site. There's a quirk though:
there's no separate ChecktvOS or CheckMacCatalyst, because the system version
is the same as for iOS, so we can just use 'iOS'.
For macOS we can now use NSProcessInfo.ProcessInfo.OperatingSystemVersion to
determine the OS version, because it's supported in all versions of macOS we
support for .NET.
Fixes issues such as this when building with XAMCORE_4_0:
> CoreMedia/CMSync.cs(590,11): error CS0103: The name 'PlatformHelper' does not exist in the current context
* Bring back PlatformHelper.CheckSystemVersion, but only for !NET.
* [tests] Remove 32-bit macOS logic, it's long dead.
* [introspection] Implement OS version check using 'NSProcessInfo.ProcessInfo.IsOperatingSystemAtLeastVersion' for macOS.
* [monotouch-test] Use TestRuntime.[Check|Assert]XcodeVersion instead of PlatformHelper.CheckSystemVersion.
* Subclass NativeObject to reuse object lifetime code.
* Enable nullability and fix code accordingly.
* Use 'is' and 'is not' instead of '==' and '!=' for object identity.
* Use the null-safe NativeObjectExtensions.GetHandle extension method to get
the handle instead of checking for null (avoids some code duplication).
* Use 'nameof (parameter)' instead of string constants.
* Call 'GetCheckedHandle ()' (which will throw an ObjectDisposedException if
Handle == IntPtr.Zero) instead of manually checking for IntPtr.Zero and
throwing ObjectDisposedException.
* Use the 'Runtime.GetNSObject<T> (IntPtr, bool)' overload to specify handle
ownership, to avoid having to call CFObject.CFRelease manually later.
* Use Array.Empty<T> instead of creating an empty array manually.
* Remove the (IntPtr) constructor for .NET.
* [xharness] Bump to the latest version of Microsoft.DotNet.XHarness.iOS.Shared (1.0.0-prerelease.21479.1).
* [xharness] Handle an exceptional condition when we fail to enumerate simulators.
* [xharness] Use new xharness API to select which simulators to use.
This also required bumping xharness.
* Bump again.
* Bump yet again.
* [xharness] Bump and fix according to API break.
* [xharness] Stop the listener before cancelling it.
Cancelling it doesn't do anything if the listener has connected, and that's
usually the case. This prevents subsequent logic from reading incomplete logs.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Update dependencies from https://github.com/dotnet/installer build 20211022.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.1
* Update dependencies from https://github.com/dotnet/installer build 20211022.16
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.16
* Update dependencies from https://github.com/dotnet/installer build 20211023.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21523.8
* Update dependencies from https://github.com/dotnet/installer build 20211024.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21524.1
* Add a dependency to Microsoft.NETCore.App.Ref.
That way we match what XA did here: 16c1226dde
It also makes Maestro update our NuGet.config for us, which additional feeds we seem
to need to build.
* [dotnet] Use all the sources in the NuGet.config when installing workloads.
* Update dependencies from https://github.com/dotnet/installer build 20211025.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21525.3
* Add dependency on Microsoft.AspNetCore.App.Ref.
* Update dependencies from https://github.com/dotnet/installer build 20211026.10
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21526.10
* [tests] Disable the implicit FSharp.Core reference.
Fixes this:
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: Unable to find a stable package FSharp.Core with version (>= 6.0.1)
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 792 version(s) in dotnet-tools [ Nearest version: 6.0.2-beta.21519.1 ]
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 46 version(s) in dotnet-public [ Nearest version: 6.0.0 ]
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in xamarin-impl
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb-1
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-1
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-2
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-4
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-5
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in Dotnet arcade
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in dotnet6
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in macios-dependencies
* [tests] Use a specific FSharp.Core version.
* Update dependencies from https://github.com/dotnet/installer build 20211027.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21527.11
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes this test failure on macOS 10.14:
MonoTouchFixtures.WebKit.WKPreferencesTest
[FAIL] TextInteractionEnabledTest : Getter
Expected: No Exception to be thrown
But was: <Foundation.ObjCException: NSInvalidArgumentException: -[WKPreferences setTextInteractionEnabled:]: unrecognized selector sent to instance 0x7fa228f12640
at (wrapper managed-to-native) ObjCRuntime.Messaging.void_objc_msgSend_bool(intptr,intptr,bool)
at WebKit.WKPreferences.set__OldTextInteractionEnabled (System.Boolean value) [0x0002c] in /Users/builder/azdo/_work/1/s/xamarin-macios/src/build/mac/mobile/WebKit/WKPreferences.g.cs:482
at WebKit.WKPreferences.set_TextInteractionEnabled (System.Boolean value) [0x00000] in /Users/builder/azdo/_work/1/s/xamarin-macios/src/WKWebKit/WKPreferences.cs:32
at MonoTouchFixtures.WebKit.WKPreferencesTest+<>c__DisplayClass0_0.<TextInteractionEnabledTest>b__0 () [0x00000] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/WebKit/WKPreferencesTest.cs:19
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 /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/RuntimeMethodInfo.cs:395
--- End of stack trace from previous location where exception was thrown ---
at NUnit.Framework.Internal.ExceptionHelper.Rethrow (System.Exception exception) [0x00006] in <d392db2fb3d64f4fa564a7b744fc7801>:0
at NUnit.Framework.Internal.Reflect.DynamicInvokeWithTransparentExceptions (System.Delegate delegate) [0x00013] in <d392db2fb3d64f4fa564a7b744fc7801>:0
at NUnit.Framework.Internal.ExceptionHelper.RecordException (System.Delegate parameterlessDelegate, System.String parameterName) [0x00067] in <d392db2fb3d64f4fa564a7b744fc7801>:0 >
* Submodule MonoTouch.Dialog.
Submodule MonoTouch.Dialog, so that we can easily build it using .NET. This
submodule will become redundant when/if we publish a .NET version of
MonoTouch.Dialog, but until that happens we need it at least for our own test
suites.
This also means we have to copy our NuGet.config and global.json files to the
MonoTouch.Dialog project directory so that we point msbuild to use our local
build.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@cbda703 [Touch.Client] Use MonoTouch.Dialog from a submodule. (#109)
Diff: 3345db2f4e..cbda703583
* Use relative path for submodule.
And fix indentation and set the branch name.
* Don't use 'RootTestsDirectory' when it might not be defined yet.
* [tests] Our test projects don't need to reference MonoTouch.Dialog directly.
The projects get the MonoTouch.Dialog reference indirectly through the
Touch.Client project reference.
* [tests] Only validate unique errors in the .NET unit tests.
* [tests] No need to reference System.Json anymore, that's handled directly in the MonoTouch.Dialog project.
* [tests] Reference nunit.framework.targets so we get a workaround for an NUnit issue everywhere.
* [msbuild] Only try to create a package if we're able to create an app bundle.
This fixes an issue where a library project would try (and fail) to create a
package when 'CreatePackage=true' (which could be set for the executable
project, but inherited by the library project since the executable project
depends on it).
* [tests] Adjust PackTest.BindingXcFrameworksProject to not set the AssemblyName property.
MSBuild ends up being very confused when the project we're trying to build
depends on other projects, because AssemblyName is set for all the projects
being build, and MSBuild complains about ambiguous projects:
> error: Ambiguous project name 'bindings-xcframework-test'
* [net6] Fix ILStrip'ed apps to actually work again
- In a late minute change to the ILStrip PR (https://github.com/xamarin/xamarin-macios/pull/12563) a change to support XVS support broke execution of Apps that were stripped
- Applications were broken because none of the stripped assemblies were actually copied into the bundle
- However, the tests still passed, because all assemblies that were there had no IL (zero assemblies total)
Now why did this happen?
- The stripped assemblies were changed to return via an msbuild Output Element
- Output Element can return an Property or ItemGroup, depending if you use the PropertyName or ItemName attributes
- Unfortunately I used PropertyName, when I expected an ItemGroup. So I silently had a property created instead.
- Thus zero items were added to the list of files to copy into the bundle
- Which was undetected as the test did not confirm files were copied in, and manual tests were not run so late into the PR (3 weeks after PR was opened)
How was it fixed?
- Correctly using ItemName on Output created a valid item group to reference
- However, that still failed with an absurdly confusing error:
PATH/Microsoft.NET.Publish.targets(277,5): error MSB3024: Could not copy the file FILE to the destination file PATH, because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles.
- After a splunking through netcore targets, I found the metadata on these assemblies references really matters. Without it, they are not processed correctly at all.
- Thus, I updated ILStripBase to clone the existing metadata when changing the original assembly reference to the stripped path
- Finally, I corrected the test to assert that required files are copied in. I also manually ran our device test.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Subclass NativeObject to reuse object lifetime code. This isn't for CFType
itself, but all its subclasses.
* Add a public default constructor to maintain compat, but remove it for XAMCORE_4_0.
* Add an internal (IntPtr, bool) constructor to follow the NativeObject pattern.
* Enable nullability and fix code accordingly.
* Use CFString.CreateNative/ReleaseNative instead of other means to create
native strings (the fastest and least memory hungry option).
* Use 'nameof (parameter)' instead of string constants.
The deadlock goes like this:
1. Thread A holds the framework_peer_release_lock lock, and tries to lock the
refcount_mutex lock.
2. Thread B holds the refcount_mutex, and is waiting for the GC to complete
3. Thread C is trying to lock the framework_peer_release_lock while running
the GC.
The fix is in thread A, by not doing anything at all with the
framework_peer_release_lock lock locked.
The code contains extensive comments explaining the situation and the solution.
Fixes https://github.com/xamarin/xamarin-macios/issues/13066.
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
* Subclass NativeObject to reuse object lifetime code.
* Enable nullability and fix code accordingly.
* Use 'is' and 'is not' instead of '==' and '!=' for object identity.
* Use CFString.CreateNative/ReleaseNative instead of other means to create native
strings (the fastest and least memory hungry option).
* Use 'nameof (parameter)' instead of string constants.
* Call 'GetCheckedHandle ()' (which will throw an ObjectDisposedException if
Handle == IntPtr.Zero) instead of manually checking for IntPtr.Zero and throwing
ObjectDisposedException.
* Use CFArray helper methods to create arrays (and implement some helper methods
that didn't exist).
* Add a few tests for the new CFArray helper methods.
* Don't execute .NET tests in the 'legacy' targets (it's wasteful because
we're already executing those .NET tests elsewhere).
* Fix reporting failures in the legacy tests.
This makes it easier to iterate over the platforms we're building for, because
we can use "macOS" to compute the variable names we're interested in (like we
already can for iOS, tvOS, watchOS and MacCatalyst).
* Create all INativeObject subclasses using 'Runtime.GetINativeObject<T>' instead
of 'new T ()'. Although it's somewhat slower, it automatically handles any IntPtr.Zero
handles, and it also makes the generator code simpler. If something turns out to
be a performance problem, we can always add custom static creation methods (like
some of the existing types already have).
* This makes it so that the zero pointer check logic in the generator isn't necessary
anymore.
* The most important part is where we use IntPtr as the marshalling type for returned
INativeObjects in blocks (instead of the INativeObject class - which doesn't make
sense really, because I have no idea how that's marshalled).
Example:
```diff
diff --git a/build/dotnet/ios/generated-sources/ObjCRuntime/Trampolines.g.cs b/build-new/dotnet/ios/generated-sources/ObjCRuntime/Trampolines.g.cs
index 97e58f3a91b..8a40748de8b 100644
--- a/build/dotnet/ios/generated-sources/ObjCRuntime/Trampolines.g.cs
+++ b/build-new/dotnet/ios/generated-sources/ObjCRuntime/Trampolines.g.cs
@@ -214,7 +214,7 @@ namespace ObjCRuntime {
} /* class NIDAVAudioEngineManualRenderingBlock */
[UnmanagedFunctionPointerAttribute (CallingConvention.Cdecl)]
[UserDelegateType (typeof (global::AVFoundation.AVAudioIONodeInputBlock))]
- internal delegate global::AudioToolbox.AudioBuffers DAVAudioIONodeInputBlock (IntPtr block, uint frameCount);
+ internal delegate IntPtr DAVAudioIONodeInputBlock (IntPtr block, uint frameCount);
//
// This class bridges native block invocations that call into C#
//
@@ -223,11 +223,11 @@ namespace ObjCRuntime {
[Preserve (Conditional = true)]
[global::System.Diagnostics.CodeAnalysis.DynamicDependency ("Handler")]
[MonoPInvokeCallback (typeof (DAVAudioIONodeInputBlock))]
- static unsafe global::AudioToolbox.AudioBuffers Invoke (IntPtr block, uint frameCount) {
+ static unsafe IntPtr Invoke (IntPtr block, uint frameCount) {
var descriptor = (BlockLiteral *) block;
var del = (global::AVFoundation.AVAudioIONodeInputBlock) (descriptor->Target);
AudioToolbox.AudioBuffers retval = del (frameCount);
- return retval;
+ return retval.GetHandle ();
}
} /* class SDAVAudioIONodeInputBlock */
internal sealed class NIDAVAudioIONodeInputBlock : TrampolineBlockBase {
@@ -249,7 +249,7 @@ namespace ObjCRuntime {
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
unsafe global::AudioToolbox.AudioBuffers Invoke (uint frameCount)
{
- var ret = invoker (BlockPointer, frameCount);
+ var ret = Runtime.GetINativeObject<global::AudioToolbox.AudioBuffers> (invoker (BlockPointer, frameCount), false);
return ret!;
}
} /* class NIDAVAudioIONodeInputBlock */
```
* Add an (IntPtr, bool) constructor so that AudioUnit works with Runtime.GetINativeObject.
* Keep track of ownership, so that AudioUnit doesn't free the native resources
when it doesn't own them.
* Update a test to verify that calling 'AVAudioIONode.AudioUnit' multiple
times and disposing the result between them works (this fails if AudioUnit
doesn't keep track of ownership).
Now that macOS runs on ARM64 (and also the simulators soon), we need to have to same logic for all platforms.
Fixes:
Introspection.iOSApiPInvokeTest
[FAIL] Could not find the field 'objc_msgSend_stret' in /usr/lib/libobjc.dylib
[FAIL] Could not find the field 'objc_msgSendSuper_stret' in /usr/lib/libobjc.dylib
[FAIL] SymbolExists : 2 errors found in 5300 functions validated: objc_msgSend_stret, objc_msgSendSuper_stret
Expected: 0
But was: 2
at Introspection.ApiPInvokeTest.SymbolExists() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/introspection/ApiPInvokeTest.cs:line 182
Fixes this when running our test suites on macOS 10.14:
dyld: Library not loaded: /System/Library/Frameworks/AuthenticationServices.framework/Versions/A/AuthenticationServices
Referenced from: /Users/runner/work/1/s/artifacts/mac-test-package/tests/./introspection/dotnet/macOS/bin/Debug/net6.0-macos/osx-x64/introspection.app/Contents/MacOS/introspection
Reason: image not found
make[2]: *** [exec-mac-dotnet-x64-introspection] Abort trap: 6
I recently deleted the generated makefile support for building and running our
test suites. It turned out that it was used for building the packaged
Xamarin.Mac tests, so it wasn't as unused as I thought.
So fix the building and packaging of Xamarin.Mac tests to not use the
(non-existent) makefile targets, but instead replicate it with manual make
code.
Also take the opportunity to add packaging and execution of the .NET versions
of these test suites we execute on other macOS versions (both for macOS and
the Mac Catalyst).
* [devops] Use stricter matching when finding the Xamarin.Mac pkg link.
Otherwise the branch name in any package could end up matching the pattern we
were looking for:
XM_PACKAGE=https://bosstoragemirror.blob.core.windows.net/wrench/tests-package-xamarin-mac-tests/15759261d425ae08494b0a26862a0b1356c5f8ec/5268864/package/Microsoft.iOS.Bundle.15.0.101-ci.tests-package-xamarin-mac-tests.68.pkg
is just clearly wrong.
This fixes a problem where the build from the different projects could stomp
on eachother in the obj/bin folders. It's technically possible to make this
work by setting up custom [Base][Intermediate][OutputPath] properties in the
project files, but the simplest solution is to just make sure there's no more
than a single project per directory.
Add support for 'dotnet pack', by:
1. Add a workaround for the fact that as soon as a project has a
'NativeReference' item, .NET's MSBuild logic wants to include a
'Native.$(AssemblyName).manifest' file in the NuGet. This obviously breaks,
because we don't create such a file, so we work around it by removing the
file in question from the corresponding item groups.
2. Add any binding resource packages to the NuGet.
3. Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12631.
Augment the CreateBindingResourcePackage to support creating a zipped binding
resource package (which is just a zipped version of the binding resource
package). This can either be manually chosen by the new 'Compressed' property,
or automatically detected (create a zipped version when there's a symlink in
the binding resource package).
The default is to not create a zipped version in legacy Xamarin, and
automatically detect for .NET.
The problem this is trying to solve is when creating a NuGet package - NuGet
doesn't handle symlinks correctly and it's not possible to create a NuGet with
symlinks. Instead we need to create a zipfile with all the binding resources.
The default has been chosen so that we automatically create a zip file when
it's required for .NET, while still maintaining old behavior with legacy
Xamarin.
We don't need to compile project-level assets for every RuntimeIdentifier in
multi-rid builds, we can instead compile them just once in the outer build.
There is also a correctness issue here: we can't compile assets more than once
and expect to get the exact same compiled result every time (in particular
actool seems to be adding random bytes in to the compiled output), and this
creates a problem when trying to merge the different runtime-specific compiled
output into a universal binary.
We accomplish this by:
* Processing these assets in the outer build, before we execute the
rid-specific inner builds.
* Store the paths to the assets we've processed in a file.
* In the inner builds, we read that file, and remove any matches from the
corresponding item group.
* Make sure to copy the compiled assets to the app bundle at the end of the
outer build.
These are the assets we currently handle this way:
* BundleResource
* ImageAsset
* InterfaceDefinition
* SceneKitAsset
* Collada
* TextureAtlas
* CoreMLModel
Also:
* Add a new test case (AppWithResource) that contains all these different
types of assets.
* Add support for the ScnTool task on Mac Catalyst (which the new test case
revealed was missing).
Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
* MTLCopyAllDevices returns a retained object, so we need to release it.
* MTLCopyAllDevicesWithObserver returns an observer (no need to provide one). This
means we can obsolete the 'ref NSObject' overload (the API doesn't make sense),
and instead add an 'out NSObject' overload.
* The returned observer from MTLCopyAllDevicesWithObserver is retained, so we must
release it.
* The returned array from MTLCopyAllDevicesWithObserver is a retained object, so
we need to release it.
* Simpify the supporting block code for the calls to MTLCopyAllDevicesWithObserver.
* Clean up the block we passed to MTLCopyAllDevicesWithObserver.
We need to strongname our MSBuild assemblies, so that different versions
can be loaded side-by-side (one example being having both a legacy and a
.NET project in the same solution).
This required setting a version for Xamarin.iOS.Tasks.dll and
Xamarin.Mac.Tasks.dll, otherwise strong-naming won't work properly (all
versions of an assembly would have the same identity).
Also sign the corresponding test assemblies, since they poke into the
internals of the task assemblies.
Fixes https://github.com/xamarin/xamarin-macios/issues/9835.
Removes the following warning during the builds:
```
warning CS8767: Nullability of reference types in type of parameter 'host' of 'bool NSHost.Equals(NSHost host)' doesn't match implicitly implemented member 'bool IEquatable<NSHost>.Equals(NSHost? other)' (possibly because of nullability attributes)
```
Test was added to ensure that we did not throw an exception.
- Added the marshaling attr and a test to ensure it is ok.
- Fix the cecil MarshalAs test to not skip over types when checking.
This revealed multiple tests failures that needed fixing.
fixes: https://github.com/xamarin/maccore/issues/2519
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
For executable projects, we must run the linker (otherwise we won't produce
something that can be executed).
We'll enable the linker by default in these cases, but if the developer has
manually disabled the linker (if the linker fails to execute for any reason,
it will suggest that the developer disables it), then we should show an error
explaining why.
Fixes https://github.com/xamarin/xamarin-macios/issues/12372.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@9e6e29f [Xamarin.MacDev] Return valid iOS/macOS versions when converting betweeen iOS and macOS versions for Mac Catalyst.
Diff: 41d91e0de0..9e6e29f2a4
This PR resolves a crash when running the linker on publishing iOS extensions.
The crash would occur here in failing to resolve corelib.
The reason this would fail was System.Private.CoreLib.dll was not in input_assemblies.
This was because we were passes the set of reference assemblies not the expected 'real' ones, and those do not include CoreLib.
After a bunch of digging, this was because _ComputeManagedRuntimePackAssembliesIfSelfContained target was not being set as a condition of _ComputeAssembliesToPostprocessOnPublish.
_ComputeManagedRuntimePackAssembliesIfSelfContained happened to be the place these were added, and wasn't being set since it has a condition of $(SelfContained) == 'true'
Now confusingly SelfContained WAS being set to true, but only in the targets file, which was too late, as it was checked in a 'global' property group outside of a target.
This means we'd fail to set SelfContained until after the condition, and not run.
This was verified by setting /p:SelfContained=true to true.
I also looked at removing the condition above, since https://github.com/dotnet/runtime/issues/54406 is fixed, however this caused project that didn't set RuntimeIdentifier to fail.
Properly synchronize access to the current writer in the generator tests'
ThreadStaticTextWriter class.
Should fix this random failure:
Error Message:
System.NullReferenceException : Object reference not set to an instance of an object.
Stack Trace:
at Xamarin.Tests.ThreadStaticTextWriter.WriteLine(String value) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTool.cs:line 478
at System.IO.TextWriter.SyncTextWriter.WriteLine(Object value)
at System.Console.WriteLine(Object value)
at Xamarin.Tests.BGenTool.Execute() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTool.cs:line 235
at Xamarin.Tests.BGenTool.AssertExecute(String message) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTool.cs:line 207
at GeneratorTests.BGenTests.BuildFile(Profile profile, Boolean nowarnings, Boolean processEnums, IEnumerable`1 references, String[] filenames) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 780
at GeneratorTests.BGenTests.BuildFile(Profile profile, Boolean nowarnings, Boolean processEnums, String[] filenames) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 766
at GeneratorTests.BGenTests.BuildFile(Profile profile, String[] filenames) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 756
at GeneratorTests.BGenTests.VSTS970507() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 650
Fixes this warning:
> Xamarin.Shared.targets(992,3): warning MSB6002: The command-line for the "BTouch" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "BTouch" into multiple calls with fewer parameters per call.
It's not tested, and thus has probably already bitrotted. If we add support
for watchOS to .NET in the future, it would likely be easier to start from
scratch (copying some of the other platforms), than having incomplete and
bitrotted code.
* Automatically include *.ttf, *.ttc and *.otf in .NET projects as BundleResource
items (if these files are found within the Resources/ subdirectory).
* Add support for a 'RegisterFont' metadata on BundleResource items, where if set
to 'true', we'll register the font file in the Info.plist as required by the target
platform.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12536.
We either use the html web page, or for .NET tests there are custom makefile
logic.
This avoids having to maintain the makefile generation to keep up with our new
tests, and it fixes numerous warnings like this:
Makefile-mac.inc:56: warning: overriding recipe for target 'build-mac-modern-macOS'
Makefile-mac.inc:41: warning: ignoring old recipe for target 'build-mac-modern-macOS'
Makefile-mac.inc:59: warning: overriding recipe for target 'clean-mac-modern-macOS'
Makefile-mac.inc:44: warning: ignoring old recipe for target 'clean-mac-modern-macOS'
Makefile-mac.inc:62: warning: overriding recipe for target 'exec-mac-modern-macOS'
Makefile-mac.inc:47: warning: ignoring old recipe for target 'exec-mac-modern-macOS'
Makefile-mac.inc:65: warning: overriding recipe for target 'run-mac-modern-macOS'
Makefile-mac.inc:50: warning: ignoring old recipe for target 'run-mac-modern-macOS'
MonoTouch.NUnit.UI.MacRunner.MainAsync will try to invoke things on the main
thread, and at the same time execute a runloop, and if the runloop isn't
executing on the main thread, we end up with a deadlock, where we keep waiting
on the main thread to process stuff enqueued by the background thread, while
the main thread is waiting for the background thread to finish.
Solve this by fixing the F# code to call
MonoTouch.NUnit.UI.MacRunner.MainAsync on the main thread.
Fix parsing extra bundler arguments where a space separates the name and the
value of the argument, like this: '--xml file.xml' (as opposed to
'--xml:file.xml' or '--xml=file.xml').
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1385946.
* [dotnet-linker] Remove workaround for a dotnet/runtime issue wrt the AOT compiler.
The dotnet/runtime issue has been fixed.
Ref: https://github.com/dotnet/runtime/issues/55733
* [tests] Set the _BundlerVerbosity property instead of MtouchExtraArgs/MonoBundlingExtraArgs to increase verbosity.
This fixes a problem where a test project would try to set the
MtouchExtraArgs/MonoBundlingExtraArgs properties, and it would fail because
the MtouchExtraArgs/MonoBundlingExtraArgs properties were already set from the
command line (and in MSBuild, properties that are set from command line
arguments can't be changed later).
In particular we have logic to pass --dlsym:+nunit.framework.dll for
monotouch-test, and that would just be ignored.
This matters because we use the library defined by the P/Invoke to determine
which frameworks to link with, and if we get it wrong, things like this may
happen:
Undefined symbols for architecture arm64:
"_AudioObjectGetPropertyData", referenced from:
wrapper_managed_to_native_AudioUnit_AudioUnit_AudioObjectGetPropertyData_uint_AudioUnit_AudioObjectPropertyAddress__uint__intptr__uint__uint_ in Xamarin.MacCatalyst.dll.o
because we though that the AudioObjectGetPropertyData function was in the
AudioUnit framework, and not in CoreAudio where it really is, and thus we
didn't link with the CoreAudio framework.
Also add an introspection test to verify that the library our P/Invokes point
to is correct.
* Update to use EnableSGenConc instead of MtouchEnableSGenConc (either works,
the former is the new future).
* Set EnableSGenConc as a top-level property, so we make sure it's set no
matter how the project is executed.
This makes it so that this setting work for .NET projects, where we're not using project configurations.
Skip:
* Any Thumb variation (Thumb code isn't supported anymore in .NET).
* Any AssemblyBuildTarget variation (compiling assemblies to dylibs [fastdev]
or frameworks - neither is supported/implemented for .NET).
This trims down the test list a bit.
This is to set the -dlsym:-nunit.framework.dll option, because nunit.framework.dll
contains a P/Invoke to a function that doesn't exist.
For some reason this is more of a problem in tvOS projects than iOS projects
(although it happens for iOS projects as well).
from Sebastien: "most filters are key-based natively (not-NSObject subclasses)) and we expose them as C# _user-type_ CIFilter-subclasses in recent years _most_ filters have also been exposed natively as protocols (not classes), we expose them as `*Protocol` interface types `CIRAWFilter` is a special case, it's a native `CIFilter` subclass so we're not using [CoreImageFilter] and [CoreImageFilterProperty] attributes to define it which also means we cannot use the "extra" tests to validate the filter properties. So we skip it here. Do not fear it's still tested, like any _normal_, NSObject subclass we have bound :-)"
Apple does this in their headers:
#define DISPATCH_ALIAS_V2(sym) __asm__("_" #sym "$V2")
dispatch_queue_t
dispatch_queue_create_with_target(const char *_Nullable label,
dispatch_queue_attr_t _Nullable attr, dispatch_queue_t _Nullable target)
DISPATCH_ALIAS_V2(dispatch_queue_create_with_target);
Which means that the native compiler will call
'dispatch_queue_create_with_target$V2' when the source code says to call
'dispatch_queue_create_with_target'.
The only place I've run into this problem, is when building for tvOS (device),
and targetting exactly tvOS 10.0 (neither earlier or later), in which case the
linker fails:
Undefined symbols for architecture arm64:
"_dispatch_queue_create_with_target", referenced from:
wrapper_managed_to_native_CoreFoundation_DispatchQueue_dispatch_queue_create_with_target_string_intptr_intptr in Xamarin.TVOS.dll.o
I filed this as a feedback with Apple some time ago [1], and Apple resolved it
as by design, saying "These symbols are renamed, please use the SDK."
Now I ran into it again with .NET, and it's become a bit more important, since
tvOS 10.0 is the earliest tvOS version we support, which means it'll be more
likely that customers use _exactly_ 10.0 as their target tvOS version. So I
looked into it again, and as far as I can tell, we can just call the '$V2'
variant instead of the original name everywhere.
Apple does the same thing for two other functions, but we haven't bound any of
those, so this only affects 'dispatch_queue_create_with_target' for us.
[1]: Bug ID 48076044: Can't reference 'dispatch_queue_create_with_target' when min tvOS version is exactly 10.0
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
We either have defaults or MSBuild properties for the most important values that
were previously required to be in the Info.plist, so now it doesn't make sense anymore
to require an Info.plist, when for simple cases it will just be an empty file.
This allows us to simplify some of our test projects and remove a few empty Info.plist files.
Add test case to verify that we pass the right bundle identifier to
DetectSigningIdentity when we're using a partial app manifest to set the
bundle identifier.
This proves that #12051 is already fixed.
* Add support for the SupportedOSPlatformVersion MSBuild property, and write
it to the Info.plist for the corresponding minimum OS version.
* If there are any minimum OS version in the Info.plist, we'll now show an
error if it doesn't match SupportedOSPlatformVersion.
This unfortunately means that if there's any minimum OS version in any
Info.plist, then that will most likely have to be moved to the
SupportedOSPlatformVersion property (or removed entirely if that's the right
choice), since it's unlikely to match the default value for
SupportedOSPlatformVersion. However, this was deemed to be the best option for
the future (it's a one-time pain during migration).
Also add new tests, update existing tests, and update the templates.
Fixes https://github.com/xamarin/xamarin-macios/issues/12336.
Fixes this error when running on M1 (and Rosetta):
MonoTouchFixtures.CoreFoundation.BundleTest.TestGetBundleIdNull : 0.9134 ms
[FAIL] TestIsArchitectureLoadable : arm64 Expected => false
Expected: False
But was: True
at MonoTouchFixtures.CoreFoundation.BundleTest.TestIsArchitectureLoadable() in xamarin-macios/tests/monotouch-test/CoreFoundation/BundleTest.cs:line 375
* Update dependencies from https://github.com/dotnet/installer build 20210826.20
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21426.20
* Update dependencies from https://github.com/dotnet/installer build 20210827.35
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21427.35
* Update dependencies from https://github.com/dotnet/installer build 20210828.23
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21428.23
* Update dependencies from https://github.com/dotnet/installer build 20210830.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21430.3
* Update dependencies from https://github.com/dotnet/installer build 20210831.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21431.4
* Update dependencies from https://github.com/dotnet/installer build 20210901.9
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21451.9
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21430.2 (parent: Microsoft.Dotnet.Sdk.Internal
* [tests] Adjust path changes for tvOS
* Update dependencies from https://github.com/dotnet/installer build 20210902.10
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21452.10
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21430.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Looks like macOS/dotnet is not quite the legacy build (which works)
* Update dependencies from https://github.com/dotnet/installer build 20210903.10
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21453.10
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21452.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210904.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21454.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21452.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210904.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21454.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21452.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210906.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21456.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21452.4 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
* [xharness] Unify the list of test projects for .NET between iOS and macOS.
* [xharness] Don't enable all .NET tests if .NET is enabled.
Some tests (such as device tests) have additional checks that must be honored as well.
* [xharness] If a test is ignored, then it doesn't matter what the corresponding build task is doing.
A build task can be shared between multiple tests, and it can be building for
another (enabled) test. This happens for iOS 32-bits and 64-bits simulator:
the app is built once, but have two different tests running.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Rolf Bjarne Kvinge
Sebastien Pouliot
Rachel Kang
Manuel de la Pena
TJ Lambert
Alex Soto
Přemek Vysoký
dotnet-maestro[bot]
Chris Hamons
Filip Navara