* 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>
It is not really needed. The only caller `SKIndex` was already clearing
the handle by calling `Dispose(bool)` which called `ClearHandle`.
If it really becomes needed then it can be reintroduced in the future.
Found while looking [1] at the strings inside the assemblies.
The diff for before/after the PR is
```diff
-Version mismatch between the native Xamarin.iOS runtime and Xamarin.iOS.dll. Please reinstall Xamarin.iOS.
+Version mismatch between the native Microsoft.iOS runtime and Microsoft.iOS.dll. Please reinstall Microsoft.iOS.
```
[1] https://github.com/xamarin/xamarin-macios/issues/14188
so the linker can remove more overloads from most/small applications.
In case of `ErrorHelper.CreateError` then the API was already accepting a
`null` exception so the extra code was not needed.
Using NativeHandle avoids implicit casts [1]
[1] likely not an issue with JIT/AOT optimization, less sure for the
interpreter. No harm in not having those in the product assembly.
* Update dependencies from https://github.com/dotnet/installer build 20220211.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.201-servicing.22111.7 -> To Version 6.0.300-preview.22111.11
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.200-1.22069.1 -> To Version 6.0.100-1.21519.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220216.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.201-servicing.22111.7 -> To Version 6.0.300-preview.22116.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.200-1.22069.1 -> To Version 6.0.100-1.21519.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Use the preview csc.
* Hardcode the toolchain version band to 6.0.200 for now.
* Bump dotnet/runtime to get nfloat changes.
* Add a dependency on Microsoft.NET.Workload.Emscripten.Manifest-6.0.100, and use it.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Changing to better null exception handling
* using is null and is not null
* Enable nullability
* revert throw null changes
* Accidentally included this file, so removing now
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
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.
Hopefully fixes random build failures like this:
> xamarin-macios/msbuild/Versions.ios.g.cs(3,1): error CS1022: Type or namespace definition, or end-of-file expected
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>
Rolf Bjarne Kvinge
Sebastien Pouliot
TJ Lambert
github-actions[bot]
dotnet-maestro[bot]
Alex Soto
Manuel de la Pena