* Update dependencies from https://github.com/dotnet/runtime build 20220727.6
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.8
* Update dependencies from https://github.com/dotnet/runtime build 20220727.6
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.8
* Update dependencies from https://github.com/dotnet/runtime build 20220813.7
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.9
Dependency coherency updates
Microsoft.NET.Workload.Emscripten.Manifest-6.0.100
From Version 6.0.4 -> To Version 6.0.8 (parent: Microsoft.NETCore.App.Ref
* Update dependencies from https://github.com/dotnet/runtime build 20220815.11
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.9
Dependency coherency updates
Microsoft.NET.Workload.Emscripten.Manifest-6.0.100
From Version 6.0.4 -> To Version 6.0.9 (parent: Microsoft.NETCore.App.Ref
* Update dependencies from https://github.com/dotnet/runtime build 20220816.8
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.9
Dependency coherency updates
Microsoft.NET.Workload.Emscripten.Manifest-6.0.100
From Version 6.0.4 -> To Version 6.0.9 (parent: Microsoft.NETCore.App.Ref
* Update dependencies from https://github.com/dotnet/runtime build 20220819.3
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.9
Dependency coherency updates
Microsoft.NET.Workload.Emscripten.Manifest-6.0.100
From Version 6.0.4 -> To Version 6.0.9 (parent: Microsoft.NETCore.App.Ref
* [tests] Adjust InvalidRuntimeIdentifier_Restore to expect failure for Mac Catalyst.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This makes it not necessary to check for the currently selected Xcode in our
system dependency check. It also means it'll become much easier to work with
multiple branches simultaneously where each branch needs its own Xcode.
Otherwise the P/Invoke generator leaves partial results in the static
registrar class, essentially saying things like "we've processed CoreMidi, no
need to add an #include for this framework", and then we'd generate the static
registrar code and that code would lack the #include for CoreMidi.
Finishing the P/Invoke generator output will clear out any state stored in the
static registrar.
Also fix a few other issues to make the generated P/Invoke wrapper code work,
and add a test.
Fixes https://github.com/xamarin/xamarin-macios/issues/15190.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
The current directory at launch is the root directory of the app bundle. This
means that any files written to the current directory when an app is executed,
will be placed there. This becomes a problem when the app is rebuilt (and
resigned), because a valid macOS app bundle doesn't have any files in the root
directory of the app bundle, so signing fails.
We have logic to automatically crash crash reports from the app bundle, but it
turns out this is a more common problem with other types of files (and
folders), so improve the logic a bit:
* Add support for setting a property to automatically clean up everything from
an app bundle we don't think should be there (which is anything not in a
Contents/ subdirectory).
* Use the same property to add support for disabling any cleaning (we already
clean mono's crash reports by default).
* Improve detection of unwanted files to include directories inside the app
bundle, not only files.
Ref: https://github.com/dotnet/maui/issues/7353
This also means that we shouldn't load the linker's output. Note that we need
to check _LoadLinkerOutput even if we've already disabled the linker, because
there may be linker output from a previous (connected) build, and we don't
want to load that.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1542438.
Add a default MAUI and a default Xamarin.Forms project as size comparison apps
(both created from templates).
This reveals that a MAUI app is ~30% bigger than a Xamarin.Forms app (42MB vs
31MB). Notably there's 21% *less* managed code, but 33% *more* native code.
https://gist.github.com/rolfbjarne/d294171969226f7511d90a817b9ac328
Resolves#14285
1. Make sure `libextension-dotnet.a` gets built, and with the `-DEXTENSION` flag.
2. Make sure `libextension-dotnet.a` gets included in the package alongside `libxamarin-dotnet.a`
3. At build time, make sure to link with the correct lib[tv]extension-dotnet.a library depending when we need to.
4. Add some tests.
Co-authored-by: Eric Sink <eric@Erics-MacBook-Pro.local>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Ask ditto to thin native libraries and frameworks when copying them to the app
bundle to remove slices for architectures we're not building for.
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/13081.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
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.
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.
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.
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>
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.
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 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>