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).
* Better text.
* Better number ("7000" is more like "this is kind of normal" - while "6999"
was more like "something quite expected happened").
* Use resources to make it localizable.
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.
MTLRenderCommandEncoder.SetViewports and
MTLRenderCommandEncoder.SetScissorRects aren't deprecated/obsoleted anywhere as
far as I can tell, so unmark them as such.
Also change the key for our Info.plist entry with the version number in .NET, and document the change.
We now use "com.microsoft.<platform in lower case>" instead of "com.xamarin.ios" (for all platforms).
Fixes https://github.com/xamarin/xamarin-macios/issues/14108.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
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
Remove the CGPDFOperatorTable.SetCallback overload that takes a normal managed
delegate, because on platforms that are AOT'ed, this delegate must point to a
static function with the MonoPInvokeCallback attribute, and if you don't
follow this requirement, you'll either get an exception at runtime (which is
not very nice to the app developer) or make the AOT compiler crash (which is a
completely different level of not being nice to developers).
In .NET, we already have an overload that takes an unmanaged function pointer,
where these requirements are enforced by the C# compiler, so just use that
instead.
* 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.
Hide the obsolete UIApplication.Main overload that takes string parameters
from intellisense. This overload is used *a lot*, so it's not worth it to
remove it, since it would break a lot of user code.
This fixes an issue where the build would continue if the server in question
serves an error page (and eventually fail with weird errors because the error
page wouldn't be valid C code).
The size of unicode strings for the minimal MySingleView.app (.net
version) goes from 6315 to 5171 characters (each being 2 bytes).
Part of the work to solve/minimize https://github.com/xamarin/xamarin-macios/issues/14188
This also removes the recent `Console.WriteLine` and replace it
with a call to `NSLog` so `System.Console.dll` is not part of the
final app bundle (size regression).
Fixes https://github.com/xamarin/xamarin-macios/issues/14182
* 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.
There was a large change to rename a lot of our Xamarin assemblies to Microsoft
ie) Xamarin.iOS -> Microsoft.iOS
There is a mismatch with some of the prerequisites in our tools/apidiff/Makefile where dependencies
are looking for ...Microsoft.iOS... but they are still named ...Xamarin.iOS...
This PR takes any remaining "Xamarin" names and changes them to "Microsoft" for all dotnet related rules.
We will also change other dotnet rules to use the new naming convention of "macOS" and "tvOS"
The only exception is to the Xamarin.PLATFORM.dll's coming from the zip - those remain as Xamarin.iOS.dll
We should expect to see the gists showing up in ApiDiffs from this PR!
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
We don't sign each rid-specific bundle, but we sign the final merged app bundle instead.
This means that we must store the list of files to codesign from the rid-specific
build and load those lists before running codesign on the merged app bundle.
https://github.com/xamarin/xamarin-macios/issues/14155.
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).
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22116.1 -> To Version 6.0.300-preview.22118.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-1.21519.4 -> To Version 6.0.200-1.22069.1 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Rolf Bjarne Kvinge
Sebastien Pouliot
TJ Lambert
github-actions[bot]
dotnet-maestro[bot]