Use already existing logic in the Configuration class to find files on disk.
Also remove some dead code and use Path.Combine instead of string
concatenation to compute paths.
Fixes https://github.com/xamarin/maccore/issues/2553.
The static registrar usually stores a compressed version of metadata tokens in
the generated code. However, when there are many assemblies in the app (>127),
we can't use the compressed version anymore, and fall back to a full version.
In this case, we weren't comparing type metadata tokens correctly when looking
for a type in our table of types, and thus we weren't finding the type we were
looking for.
The result is an exception like this:
> Can’t register the class MyClass when the dynamic registrar has been linked away.
In the generated table of types we're storing the full metadata token, which
includes a few bits indicating which type of token it is (in this particular
case a TypeDef token). When going through the table looking for a type, we
need to compare with those few bits set on the input type token as well to
find what we're looking for.
Also make it possible to use the remove-dynamic-registrar optimization on
macOS (which is useful by itself, but it also makes adding a test case
easier).
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1476585.
Fixes https://github.com/xamarin/xamarin-macios/issues/11641.
* Enable nullability and fix code accordingly.
* Augment it to be able to take multiple files to strip at the same time.
* Strip in parallel.
* Execute using xcrun (ref: #3931)
* Pass the full path to the executable file to strip, to make command lines
easier to copy-paste.
* Remove test that is now outdated. We have other tests that run strip
anyways, so this shouldn't be a problem.
Introduce `FSEventStreamCreateOptions` to avoid a slew of .ctor overrides, and make it easier to specify `DeviceToWatch` and `SinceWhenId`. `SinceWhenId` was previously only exposed on the "low level" .ctor, and it's a rather important parameter for supporting events that may have happened while the application was not running.
Make the existing constructors wrap `FSEventStreamCreateOptions` to avoid API break.
This is a followup to #14318. When using device-relative watches, files can be tracked via a tuple of their device ID and inode instead of paths. #14318 exposes inode data on `FSEvent`.
Implements support for `FSEventStreamCreateFlags.UseExtendedData`, fixing #12007.
When `.UseExtendedData` is specified, the event data type changes from `CFString` to `CFDictionary`; the dictionary contains the path (`path` key) and inode (`fileID` key) information for the file and may be extended in the future with other fields. Previously this was crashing because we assumed `CFString` always.
Further add a convenience constructor for monitoring a single path, add the missing `UnscheduleFromRunLoop` APIs, and add `SetDispatchQueue` to allow using dispatch queues directly instead of run loops.
Finally, this PR adds a fairly exhaustive file system test which covers the existing (non-extended) and fixed (extended) creation modes, along with using a dispatch queue instead of run loop.
Fixes https://github.com/xamarin/xamarin-macios/issues/12007
Make the CollectBundleResourcesDependsOn property public, so that custom
targets can inject themselves into the build early enough to add additional
BundleResource or Content items (by adding their custom target's name to the
CollectBundleResourcesDependsOn property).
Fixes https://github.com/xamarin/xamarin-macios/issues/11984.
The new tests do not have a display and that makes certain mac tests
fail. Added a new TestRuntime function to let us know if we are on vsts
and ignore accordingly.
fixes https://github.com/xamarin/maccore/issues/2546
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes two test failures on tvOS with all optimizations enabled:
MonoTests.System.Net.Http.MessageHandlerTest.DnsFailure
[FAIL] DnsFailure(System.Net.Http.SocketsHttpHandler) : Exception
Expected: instance of <System.Net.Http.HttpRequestException>
But was: <System.MissingMethodException: No parameterless constructor defined for type 'System.Net.Http.SocketsHttpHandler'.
at System.RuntimeType.CreateInstanceMono(Boolean , Boolean )
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean )
at System.Activator.CreateInstance(Type )
at MonoTests.System.Net.Http.MessageHandlerTest.GetHandler(Type ) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 50
at MonoTests.System.Net.Http.MessageHandlerTest.<>c__DisplayClass3_0.<<DnsFailure>b__0>d.MoveNext() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 76>
MonoTests.System.Net.Http.MessageHandlerTest.RejectSslCertificatesServicePointManager
[FAIL] RejectSslCertificatesServicePointManager(System.Net.Http.SocketsHttpHandler) : System.MissingMethodException : No parameterless constructor defined for type 'System.Net.Http.SocketsHttpHandler'.
at System.RuntimeType.CreateInstanceMono(Boolean , Boolean )
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean )
at System.Activator.CreateInstance(Type )
at MonoTests.System.Net.Http.MessageHandlerTest.GetHandler(Type ) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 50
at MonoTests.System.Net.Http.MessageHandlerTest.RejectSslCertificatesServicePointManager(Type ) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 405
at System.Reflection.RuntimeMethodInfo.Invoke(Object , BindingFlags , Binder , Object[] , CultureInfo )
The default constructor doesn't work (it's already obsolete).
Fixes:
Xamarin.Mac.Tests.DelegateAndDataSourceTest
[FAIL] DelegateAndDataSourceAllowsNull : 1 failing types
1 failing types:
PassKit.PKPaymentAuthorizationViewController: Could not initialize an instance of the type 'PassKit.PKPaymentAuthorizationViewController': the native 'init' method returned nil.
It is possible to ignore this condition by setting ObjCRuntime.Class.ThrowOnInitFailure to false.
at Xamarin.Mac.Tests.DelegateAndDataSourceTest.DelegateAndDataSourceAllowsNull () [0x0026c] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/ObjCRuntime/DelegateAndDataSourceTest.cs:90
CHIP framework seems to not be stable yet from Apple's side
each xcode update it brings breaking changes and it is also
not documented anywhere so let's disable it for now and
we can re-enable it in the future once it is stable.
It exists, but does nothing on Mac Catalyst.
"This framework ignores calls from Mac apps built with Mac Catalyst."
Ref: https://developer.apple.com/documentation/arkit?language=objc
Also augment xtro to not be confused when encountering lines starting with '#'
that has no other text.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Set NSImageRep DrawInRect hints as nullable
* Add nullable attributes to NSString DrawAtPoint/DrawInRect/StringSize
* Fix xtro test failure
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Fixes:
Introspection.ApiCMAttachmentTest
[FAIL] CheckFailAttachments : System.InvalidOperationException : Could not create the new instance for type CGEvent.
at Introspection.ApiCMAttachmentTest.GetINativeInstance(Type t) in xamarin-macios/tests/introspection/ApiCMAttachmentTest.cs:line 498
at Introspection.ApiCMAttachmentTest.CheckFailAttachments() in xamarin-macios/tests/introspection/ApiCMAttachmentTest.cs:line 572
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
* Check implementation assemblies instead of reference assemblies.
* Try to print the source code location for failing API (this required processing
the implementation assemblies, because the reference assemblies don't have debug
information where the source code location is stored).
* Don't report API that has [EditorBrowsable (None)] attributes, presumably we
decided to keep these for compatibility, while highly discouraging their
continued use. Also stop doing this for the next time we can do a breaking
change, maybe we can remove these APIs then.
* Don't report API that has [UnsupportedOSPlatform ("...#.#") attributes (with
a version number), presumably this is API that is still valid for some OS
versions.
* Enable the test for all APIs (no ignores anymore). It's green!
Fixes https://github.com/xamarin/xamarin-macios/issues/13621.
This also requires updating the xtro definitions, because sharpie now finds
many more Mac Catalyst frameworks than before (and we haven't bound those
frameworks yet).
Generate a proj file that contains variables for the current pch and assembly,
and include this proj file in the main xtro-sharpie project file. This way we
can use these variables for the pch and assembly arguments in the run
configurations, so we don't have to update the project file every time these
change (in particular the pch file changes name with every Xcode bump).
The [Culture ("en")] attribute means: only run this test if the culture is
"en". This usually meant not running this test (apparently we don't run often
with culture = "en"), leading to outdated tests that happened to fail when
actually run under culture = "en" (such as on older macOS bots).
So change these tests to actually change the culture to "en" (by using the
SetCulture attribute), and also fix them.
* Add to Mac Catalyst. Fixes#13931.
* Manually include CoreTelephony headers in xtro. There's no umbrella header
in CoreTelephony 😡😞
* Fix availability attributes
* Only CTCall and CTCallCenter are deprecated in the CoreTelephony API.
* None of these APIs are obsolete, just deprecated.
* Add Mac Catalyst attributes.
One curious fact is that the PCSC framework interferes with compiling CTCarrer.h:
In file included from /private/var/folders/43/h027tm1n101cdrq2_b6n9n2m0000gn/T/n0b0byrt.h:163:
/Applications/Xcode_13.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/CoreTelephony.framework/Headers/CTCarrier.h:62:41: error: reference to 'BOOL' is ambiguous
@property (nonatomic, readonly, assign) BOOL allowsVOIP __OSX_AVAILABLE_STARTING(__MAC_NA,__IPHONE_4_0);
^
/Applications/Xcode_13.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/PCSC.framework/Headers/wintypes.h:59:18: note: candidate found by name lookup is 'BOOL'
typedef int16_t BOOL;
^
/Applications/Xcode_13.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/include/objc/./objc.h:78:18: note: candidate found by name lookup is 'BOOL'
typedef bool BOOL;
^
1 error generated.
but since we don't bind the PCSC framework, we can just ask ObjectiveSharpie
to exclude it.
Fixes https://github.com/xamarin/xamarin-macios/issues/13931.
Hoping that one day we'll have a System.Numerics.Matrix3x3 type we can replace our
RMatrix3 type with:
* Add all API in OpenTK.Matrix3 that also exists in equivalent form in System.Numerics.Matrix4x4.
* Remove all API that doesn't exist in equivalent form in System.Numerics.Matrix4x4.
For NMatrix2 and NMatrix3:
* Change the fields to be M## instead of R#C# (this is how System.Numerics does
it, and also how we do it in other matrix types).
* Add obsolete and hidden R#C# versions of the fields to ease migrating existing
code to .NET (but let's try to remove these in xamcore 5).
* Add properties in legacy Xamarin recommending users to use the new naming.
* A few other API additions to add equivalent API to the matrix types in System.Numerics.
For CGAffineMatrix:
* Add obsolete and hidden versions of the legacy field names to .NET to ease
migrating existing (but let's try to remove these in xamcore 5).
Fixes https://github.com/xamarin/xamarin-macios/issues/14125.
* Remove ObjCRuntime.nfloat (in favor of System.Runtime.InteropServices.NFloat).
* Automatically add a reference to the System.Runtime.InteropServices.Internal
package, so that developers get the new NFloat API (with operators) we've
added post .NET 6 (but don't do this for .NET 7).
* Automatically add a global using alias for
System.Runtime.InteropServices.NFloat -> nfloat. This is not behind the
usual `ImplicitUsings` condition our other implicit usings are, because
they're off by default for existing projects, and the main target for the
global using alias for nfloat is upgraded projects.
* Automatically generate a global using alias (like above) in the generator
for all code the generator compiles.
* Update xtro entries to reference System.Runtime.InteropServices.NFloat
instead of ObjCRuntime.nfloat.
* Add a workaround for a hopefully temporary issue with .NET/CoreCLR where the
wrong runtime pack is selected otherwise (without the new NFloat API, so
nothing works at runtime).
Ref: https://github.com/xamarin/xamarin-macios/issues/13087
* Using `NativeHandle` avoids implicit casts [1]
* Do not expose `IntPtr` as the type for the `SuperClass` handle
[1] likely not an issue with JIT/AOT optimization, less sure for the
interpreter. No harm in not having those in the product assembly.
* Remove the code behind for AVCaptureConnection.SupportsVideoMinFrameDuration
and AVCaptureConnection.SupportsVideoMaxFrameDuration. The codebehind looks like
a workaround for Apple renaming the selector, but from history it looks like that
happened before the earliest version of iOS we support today, so this can be expressed
in an api definition now without any code behind.
* Add these fields to macOS, where they're not even deprecated (like they are on
other platforms).
* Remove conditional code in api definition, and distribute [No*] attributes as
required.
* Remove the AVCaptureConnection.AudioChannels property from .NET, it doesn't do
anything useful.
This way it's easier to copy-paste the path to the these files from terminal output
and open/run it (with a relative/partial path you'll need to know the current directory,
which is just an annoying thing to figure out sometimes).
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
Add support for the PublishFolderType metadata on Content and BundleResource
items, which makes it possible to change the location in the app bundle for
these items (this was possible to do before with the Link metadata), but most
importantly it also makes it possible to choose to *not* bundle these items in
the app bundle (which was not possible before with the Link metadata, nor any
other means).
At first I thought setting CopyToPublishDirectory /
CopyToOutputDirectory=Never would accomplish that, but it turns out we don't
honor those, and since we already have this behavior of ignoring
CopyToPublishDirectory / CopyToOutputDirectory in legacy Xamarin, I didn't
want to change it in .NET.
So I added support for honoring the PublishFolderType metadata instead, which
is new and we already support for other item groups. This is accomplished by
adding all Content and BundleResource items with PublishFolderType set to the
ResolvedFileToPublish item group (where we already handle any
PublishFolderType values), and then we ignore such Content and BundleResource
items in our CollectBundleResources task.
Also update the documentation and add tests.
There's no corresponding System.Runtime.InteropServices.NFloat.CopyArray method in .NET.
It turned out that the API where we used CopyArray don't need to use CopyArray at all, the same can be accomplished faster and simpler by using unsafe code.
Not embedding third-party libraries in the binding assembly is the future, and
let's try to enable it by default starting with .NET.
Fixes https://github.com/xamarin/xamarin-macios/issues/12530.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
inside it's _only_ caller and remove the API.
Remove old test that was already not useful (since the method could not
be removed anyway for quite a while).
As a part of the breaking changes in .NET, we introduced a new type,
`ObjCRuntime.NativeHandle`, to represent native handles.
This meant that constructors taking taking `IntPtr handle`:
```cs
public class MyUIViewController : UIViewController {
protected MyUIViewController (IntPtr handle)
: base (handle)
{
}
}
```
would have to be ported to take `NativeHandle handle`:
```cs
public class MyUIViewController : UIViewController {
protected MyUIViewController (NativeHandle handle)
: base (handle)
{
}
}
```
The unfortunate part is that there will be no compiler warnings or errors
flagging this, so users won't know to do it unless they either read the
documentation (🤣) or run into the problem, googles for a while, runs into
someone else who had the same problem, and applies their (probably broken)
fix.
So we change our logic to:
1. Look for and use an `(IntPtr)` (or `(IntPtr, bool)`) constructor in .NET if
the `NativeHandle` version isn't found.
2. Show a warning.
3. Some time in the future maybe remove this hack/workaround.
Fixes https://github.com/xamarin/xamarin-macios/issues/14046.
fixes#13160
- remove unused types
- use System.Numerics when possible
- move own created types from OpenTK namespace to CoreGraphics
- create missing types in CoreGraphics namespace
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Removing attributes for mellite
* Remove existing attributes
* Attribute Conversion
* Reverting changes to Security/Enums.cs and Security/SecureTransport.cs since they are API source
* Revert "Removing attributes for mellite"
This reverts commit eea2898870.
* Fixing Verifies, Moving Obsolete, Adding missing conversion
* Adding in removed comments and messages
* Removing unused NET Attributes
* Removing duplicated comments
* Removing not needed availability
* Remove todos
* removing other not needed availability
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Make the Bug2000_NSPersistentStoreCoordinator test use a test file name that
contains the process id, so that multiple test processes at the same time
don't stomp on eachother.
Fixes https://github.com/xamarin/maccore/issues/2515.
We must set `ResolveAssemblyConflicts=true` before loading
Microsoft.Common.targets (which is loaded by Microsoft.CSharp.targets),
because otherwise we won'd do any conflict resolution at all, since the
variable isn't 'true' when it needs to be.
Also add test.
Fixes https://github.com/xamarin/xamarin-macios/issues/11691.
This makes us render this:
public delegate nfloat NSTableViewColumnWidth(NSTableView tableView, nint column);
instead of this:
public delegate nfloat NSTableViewColumnWidth(NSTableView tableView, IntPtr column);
Fixes https://github.com/xamarin/xamarin-macios/issues/14107.
Fixes race condition where finalized objects are resurrected by the finalizer and for a brief moment `Runtime.TryGetNSObject`/`Runtime.GetNSObject` would return them even though a new instance is supposed to be used. In multi-threaded scenarios this would result in reused objects (same native handle) to suddenly become invalid when the UI thread processes the delayed finalization.
Fixes#13921
Implement the UIResponderStandardEditActions protocol, move the
corresponding API from UIResponder there, and make sure UIResponder implements
the new UIResponderStandardEditActions protocol (which should make this move a
non-breaking change, since the protocol is inlined in UIResponder).
Include all files in the project's Resources subdirectory as BundleResource
items (except .DS_Store files, which are pretty omnipresent on macOS).
Also, contrary to the other default includes, add a condition so files are
only included if we have a resource prefix (typically "Resources"), otherwise
the entire hard drive might be included, and that's not really what we want.
Fixes https://github.com/xamarin/xamarin-macios/issues/13808.
When exception marshalling was originally implemented, for backwards
compatibility concerns it was only turned on by default for platforms that
really needed it (watchOS).
However, exception marshalling is by far the safest option, so in .NET we're
enabling it by default for all platforms (it's still possible to disable it
for those who wants to).
Ref: https://docs.microsoft.com/en-us/xamarin/ios/platform/exception-marshaling
We have a problem that's shown up a few times, where we're given an instance
of a native type, where the closest bound managed type is a type declared as
[Abstract] in the api definition. In this case, we want to create an instance
of the [Abstract] type to wrap the native instance, but that hasn't been
possible because the managed type is abstract.
Note: this is totally fine from the OS perspective: it might have created an
instance of a private subclass we haven't bound (or it might even be a public
subclass we just haven't bound yet).
The fix is to:
* Stop making [Abstract] classes in the api definition abstract classes in the generated code.
* Make the default constructor default to "protected" visibility for [Abstract] classes.
This way we can still create instances of these types at runtime when we need
them, but they must be subclassed in order to create a managed instance of
them.
Additionally I also had to make abstract members virtual for such types
(because otherwise the type would have to be abstract as well), and instead
throw a "You_Should_Not_Call_base_In_This_MethodException" in the
corresponding method implementations.
Fixes https://github.com/xamarin/xamarin-macios/issues/4969.
This makes diagnosing what happens much easier in some cases.
Exhibit A, pre fix:
*** Terminating app due to uncaught exception 'ObjCRuntime.RuntimeException', reason: 'Failed to lookup the required marshalling information.
Additional information:
Selector: conformsToProtocol:
Type: ViewController
Exhibit B, post fix:
*** Terminating app due to uncaught exception 'ObjCRuntime.RuntimeException', reason: 'Failed to lookup the required marshalling information.
Additional information:
Selector: conformsToProtocol:
Type: ViewController
(ObjCRuntime.RuntimeException)
Failed to get the 'this' instance in a method call to templ.ViewController.InvokeConformsToProtocol. (ObjCRuntime.RuntimeException)
at Registrar.DynamicRegistrar.GetMethodDescriptionAndObject(Type type, IntPtr selector, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc)
at ObjCRuntime.Runtime.GetMethodAndObjectForSelector(IntPtr klass, IntPtr sel, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc)
at ObjCRuntime.Runtime.get_method_and_object_for_selector(IntPtr cls, IntPtr sel, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc, IntPtr& exception_gchandle)
Failed to marshal the Objective-C object 0x7f813fd2f470 (type: ViewController). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'templ.ViewController' does not have a constructor that takes one NativeHandle argument). (ObjCRuntime.RuntimeException)
at ObjCRuntime.Runtime.MissingCtor(IntPtr ptr, IntPtr klass, Type type, MissingCtorResolution resolution)
at ObjCRuntime.Runtime.ConstructNSObject[T](IntPtr ptr, Type type, MissingCtorResolution missingCtorResolution)
at ObjCRuntime.Runtime.ConstructNSObject(IntPtr ptr, IntPtr klass, MissingCtorResolution missingCtorResolution)
at ObjCRuntime.Runtime.GetNSObject(IntPtr ptr, MissingCtorResolution missingCtorResolution, Boolean evenInFinalizerQueue)
at Registrar.DynamicRegistrar.GetMethodDescriptionAndObject(Type type, IntPtr selector, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc)
* A lot of obsolete/deprecated removal.
* Remove the NSDraggingInfo model, which required numerous other changes.
* Remove the NSPasteboardReading/NSPasteboardWriting models, which required more
numerous changes.
* Update the tests accordingly.
* Use 'ObjCException' instead of 'MonoTouchException' as the managed exception
type wrapping an NSException for all platforms in .NET (that was already the
case for macOS, so no change there).
* Make the ObjCException class behave like the MonoTouchException class does.
* Move the ObjCException type to the ObjCRuntime namespace in .NET.
Fixes https://github.com/xamarin/xamarin-macios/issues/13855.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Also make the (NativeHandle) constructor protected instead of public, to make
it clearer that it's not for public consumption.
And modify the template tests to execute the template if we can.
Fixes https://github.com/xamarin/xamarin-macios/issues/13979.
This turned out a bit complex, because numerous ModelIO APIs were initially bound
with wrong matrix types, and had to be rebound later (our matrix type was transposed
with regards to the native matrix type). The new versions often had to use worse
names, so that's being fixed now. This means that numerous tests had to be updated,
because the original API now returns non-transposed matrices.
* [CHIP] Updates for Xcode13.2 beta 1
* Update based on feedback
* Update based on feedback and intro test failure
* Update xtro .todo files
* Fix some breaking API changes
* Delete silly typos
This hopefully solves a few problems on M1, where we'd want to execute with
.NET 5 (last stable .NET release), but that version only supports x86_64, and
then if an ARM64 version of .NET 6 was also installed, things would break in
mysterious ways.
This way we have full control over what happens, and also a consistent
environment across all machines.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Mostly just removal of obsolete/deprecated API.
* Modified CAScrollLayer.ScrollMode to use the good name
(CAScrollLayer.ScrollMode) for the strongly typed enum, and then have a
WeakScrollMode property for the NSString version (like we do elsewhere).
* Use `is` instead of `==` for null checks
* Use `ThrowHelper` to throw common exceptions
* Use faster `CFString` API (over the slower `NSString` variants)
* [tests] Adjust UTTypeTest.cs to build for net profile
* Use the native `NSStringFrom*` API so we can, eventually, use the
native code to parse them from `NSString` and also ensure increased
compatibility with any code that expects the native string representation
* Add unit tests for `ToString` methods
Also use [`System.HashCode`](https://docs.microsoft.com/en-us/dotnet/api/system.hashcode?view=net-6.0) to generate the hash code
* Update dependencies from https://github.com/dotnet/runtime build 20220117.8
Microsoft.NETCore.App.Ref
From Version 6.0.2-mauipre.1.22054.8 -> To Version 6.0.2-mauipre.1.22067.8
* [tests] Adjust according to BCL changes.
* Update dependencies from https://github.com/dotnet/runtime build 20220118.10
Microsoft.NETCore.App.Ref
From Version 6.0.2-mauipre.1.22054.8 -> To Version 6.0.2-mauipre.1.22068.10
* Update dependencies from https://github.com/dotnet/runtime build 20220119.5
Microsoft.NETCore.App.Ref
From Version 6.0.2-mauipre.1.22054.8 -> To Version 6.0.2-mauipre.1.22069.5
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Improve the API for both legacy Xamarin and .NET.
* Obsolete the old API in legacy Xamarin and point to the new API.
* Remove the old API in .NET.
* Add nullability.
This is mostly removing obsolete/removed API, except for
SKProduct.ContentVersion, where the XAMCORE_4_0 annotations were wrong and the
property is still alive and kicking.
This means removing numerous obsolete/deprecated methods where better/more
correct alternatives already exist.
Also fix one obsolete message and adjust the tests.
These types come from the CFNetwork.framework, but for some reason they were bound inside CoreServices many years ago.
This resolves a potential issue where we might end up linking with the
CoreServices framework instead of CFNetwork framework (because we use the
namespace of types to determine which framework they belong to).
- Disable check "[FAIL] Both '{t}' and '{m}' are marked with `{s}`." type and member on that type in NET
- Due to the behavior of NET6 style attributes, we are forced to duplicate availability attributes in many cases
- See https://github.com/xamarin/xamarin-macios/issues/10170 for details
This makes it easier to figure out problems in consuming code, since it makes
it easier to identify where things start to go wrong.
Fixes https://github.com/xamarin/maccore/issues/2539.
In .NET, all files that should be published (put into the final .app bundle) are put into the @(ResolvedFileToPublish) item group, and at the end of the build process, .NET will publish all the files in that item group. Which files are in this item group, and how they're put in there, is out of our control (it's just how the build process works in .NET), so we'll have to cope.
Additionally, publishing an app for Apple platforms is different than publishing other .NET apps, because we can't just put all the files in the a directory like .NET usually does, we have a fairly strict directory structure we need to follow, and it also differs between platforms (the structure is different between macOS and iOS for instance).
This means that for every file in the `ResolvedFileToPublish` item group, we have to figure out:
* Should it be put into the app bundle in the first place?
* If so, in which subdirectory (if any)?
This PR implements these changes. The exact details are explained in a document in the PR, but the general logic is:
* We make an educated guess for some types of files we know about (assemblies, unmanaged libraries, images, etc).
* We provide a way to set metadata on each item specifying which type of item it is (assembly, unmanaged library, image, etc), and we'll treat the item as such. This method can also be used to override the guess we made (for files that shouldn't be published for instance).
* We warn if we run into files we're not educated enough to be able to guess about, and for which there's no custom metadata set.
Fixes https://github.com/xamarin/xamarin-macios/issues/12572.
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.
Alex Soto
Rolf Bjarne Kvinge
Manuel de la Pena
Aaron Bockover
Přemek Vysoký
Curtis Wensley
Sebastien Pouliot
Stephane Delcroix
TJ Lambert
Chris Hamons
Filip Navara
Marius Ungureanu
Rachel Kang
dotnet-maestro[bot]