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.
* Make Runtime.Arch a readonly field.
* Tell the AOT compiler Runtime.Arch is a constant value.
* Tell the linker to stub out the method we use to fetch the current
architecture from native code (it turned out a bit complicated to set the
Arch field when it's readonly - the solution I came up with was to call a
P/Invoke).
Test case (size of the main executable): link all (debug)
* Before: 33.522.704 bytes
* After: 33.506.112 bytes
* Difference: -16.592 bytes (-0.05 %)
There were no size differences in release mode, nor were there any size
differences in the "don't link" test, neither for debug nor release mode.
Fixes https://github.com/xamarin/xamarin-macios/issues/5518.
Make note about:
* Caveat with regards to IntPtr constructors having to be manually changed to
be NativeHandle constructors.
* Moving NSFileProvider types.
This type has been obsolete for over 3 years, it hasn't been updated in many
more years, and there are multiple newer and better alternatives available.
This meant we could remove a few more other (private/related) types as well.
Mono will eventually use functions from the Compression framework to
decompress ICU data files during the runtime's initialization. Prepare
for this by linking against the compression framework.
Also see https://developer.apple.com/documentation/compression?language=objc.
This speeds up builds significantly when the linker is disabled.
Test case: building tests/dotnet/MySimpleApp for macOS.
* Before: 37s
* After: 9s
* Difference: 26s (4x faster)
Test case: run the .NET tests
* Before: 2h55
* After: 1h43
* Difference: 1h12 (1.7x faster)
Contributes towards https://github.com/xamarin/xamarin-macios/issues/10251.
Ref: https://github.com/dotnet/linker/issues/2089
* 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.
It seems that MSBuild doesn't always automatically convert directory
separators for relative paths, so we have to do it ourselves.
Thanks to @lauxjpn for diagnosing this and coming up with a fix.
Fixes https://github.com/xamarin/xamarin-macios/issues/13838.
## Problem
Template package does not appear on nuget.org correctly, as `packageType` in nupkg is set to `DotnetPlatform`.
## Solution
Disabled loading Microsoft.DotNet.SharedFramework.Sdk for template package build.
it doesn't seems to be needed and overwrites PackageType to DotnetPlatform, even though initially it is correctly set to 'PackageType'
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).
* 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.
Split decompressing zip files and figuring out what was inside the zip files
in two different tasks, so that we do the second part even if the first part
isn't done (it could have been done in a previous build).
This is required for rebuilds to work correctly.
This fixes the following problem:
* App with framework is built and signed.
* App is rebuilt, and the framework is copied in again.
* This time, the framework's executable's timestamp will be earlier than the
timestamp when it was last signed, and as such it won't be signed again.
Fix this by touching all the copied files when copying a directory to the app bundle.
Collect all the binding resource packages, add our binding resource packages to the
items that need to be resolved, and remove them from the ResolvedFileToPublish item
group.
Depending on the resolved content (static library, dynamic library, framework) of
a binding resource package, we must do different things , so these items must be
removed from the ResolvedFileToPublish item group.
The _DecompressPlugIns target will process all the items in the _CompressedPlugIns
item group, decompress them and add them to _DirectoriesToPublish. The compressed
file itself is not copied to the app bundle.
We can't keep plugins in the ResolvedFileToPublish item group, because plugins are
usually directories, which may contain symlinks, which the built-in publish logic
doesn't handle correctly.
The _DecompressAppleFrameworks target will process all the items in the _CompressedAppleFrameworks
item group, decompress them and add them to _FrameworkNativeReference. The compressed
file itself is not copied to the app bundle.
This new target will process all the items in the _CompressedAppleBindingResourcePackage
item group, decompress them, and then resolve the extracted results.
This new target will process all the items in the _CompressedPlugIns item group,
decompress them, and add them to _DirectoriesToPublish for later copying into the
app bundle.
This new target will process all the items in the _CompressedAppleFrameworks item
group, decompress them, resolve them if necessary (for .xcframeworks) and add them
to _FrameworkNativeReference.
Rolf Bjarne Kvinge
imhameed
Sebastien Pouliot
Vlada Shubina
Chris Hamons
Mauro Agnoletti
TJ Lambert
James Parsons