The native methods xamarin_get_[generic_]method_from_token are a bit unusual
in that they return an actual GCHandle. This is for performance reasons, since
in some cases their return value is passed as parameters to other function
calls to managed code, in which case we need the GCHandle. This way we avoid
round-tripping a GCHandle multiple times.
Not an experiment anymore - it works as expected.
This half-remove the optimization option (it must remain there to avoid
breaking all projects that have it defined) but it will always be `true`
so `Xamarin.Forms.Platform.iOS.dll` will **always** be considered as SDK
code by the linker.
Fix https://github.com/xamarin/xamarin-macios/issues/8407
* Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and
mtouch, by putting mono's static and dynamic libraries in
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk
to match how Xamarin.iOS does it.
* Don't use 'usr' as an intermediate directory. This removes another special
case.
* Share many of the functions and properties that return specific directories,
and document (as comments) what each function/property is supposed to
return.
Cecil has a fall-back mode where it looks in the GAC / system mono for
assemblies when failing to find them elsewhere. This is not the expected
behavior when using Xamarin.Mac in the Full/XM mode, because then we should
only resolve to assemblies shipped with Xamarin.Mac.
Unfortunately doing so will break apps (our own tests break), so instead
change our resolution to be explicit about where we find assemblies, and if we
find assemblies in the GAC / system mono when we're not supposed to, then show
a warning.
Also add a fall-back mechanism, where we use the old logic instead, in case
the new logic is not 100% compatible with the old one.
This showed up when I tried to port mmp to dotnet, because then Cecil stopped
looking in the GAC / system mono for assemblies (Cecil has a special case when
running on Mono to look in Mono's GAC), and tests started failing.
We're using the Release configuration to build the mtouch and mmp binaries
that we ship, which means that we can use the Debug configuration for
debugging from an IDE, and use the standard conditional compilation symbols to
identify that case.
xcrun can print stuff to stderr even if it succeeds and prints what it found
to stdout, which means we have to separate stdout and stderr when capturing
xcrun's output.
This also means that we need a few changes to our RunCommand API:
* Add support for capturing stdout and stderr separately by providing
different callbacks/StringBuilder instances.
* Use overloads instead of default arguments, because with default arguments
we end up with ambiguous matches in a lot of places with the new overloads.
Fixes https://github.com/xamarin/xamarin-macios/issues/8147.
Backport of #8150.
* [mtouch/mmp] Only use stdout from xcrun as the path of the file that was found. Fixes#8147.
xcrun can print stuff to stderr even if it succeeds and prints what it found
to stdout, which means we have to separate stdout and stderr when capturing
xcrun's output.
This also means that we need a few changes to our RunCommand API:
* Add support for capturing stdout and stderr separately by providing
different callbacks/StringBuilder instances.
* Use overloads instead of default arguments, because with default arguments
we end up with ambiguous matches in a lot of places with the new overloads.
Fixes https://github.com/xamarin/xamarin-macios/issues/8147.
* [tests] Fix mmptest build.
* [mtouch/mmp] Fix process log output.
* Unify target framework code between mtouch and mmp.
* Simplify the code in mmp: have three possible valid target frameworks for
most of code, and add special code to handle setting any other valid target
frameworks to redirect to one of those three valid target frameworks (and
warn if given any of those valid, but not "main", target frameworks). Any
other code can then depend on the target framework having exactly one of
those specific values, which means we can make IsUnified* variables
convenience properties instead.
* Unify a bit more of the argument parsing code between mtouch and mmp, since
that made a few other things easier.
* Add TargetFramework.IsValidFramework to have one validation implementation.
* Move the implementation of TargetFramework.MonoFrameworkDirectory to mmp
itself, it's not really related to the target framework.
* Remove Driver.IsUnified and IsClassic from mmp, they're not used anymore.
* Formally deprecate --xamarin-[full|system]-framework in mmp, they've really been deprecated for many years.
* Remove LinkerOptions.TargetFramework, it's not used anymore.
* Get rid of mmp's userTargetFramework fried, it's duplicated with the
targetFramework field.
* Add a few tests, and tweak others a bit.
Breaking changes:
* Both mtouch and mmp require --target-framework now. The only direct
consumers should be the MSBuild tasks, which already pass --target-framework
all the time. This simplifies code, and removes assumptions.
* [mtouch][mmp] Share error.cs and make it safer against FormatException
Beside the obvious code sharing [1] this makes the error reporting code
safer against `FormatException`.
Even with code review this happened a few times in the past - we get
a string that can't format correctly in some error handling code. This
means the `FormatException` must be fixed before we can see the
underlying root issue (delaying bug fixes and support).
Recent changes made for localization makes it harder to review the
original strings (and even harder for translated strings) for
correctness. This means we can end up with something like
```
String.Format ("{0} {1}", "foo");
``
and easily miss it (since they split between different files) if there
are several changes inside a PR.
Finally sprinkle some unit tests :)
[1] we should move everything to use `ProductException` but that will be
for another PR...
This optimization can be enabled when it's not possible to use the
managed linker (e.g. **Don't link**) or when the managed linker cannot
remove references to deprecated types that would cause an application
to be rejected by Apple.
References to the existing types will be renamed, e.g. `UIWebView` to
`DeprecatedWebView`, in every assemblies.
The type definition is also renamed (for validity) and all custom
attributes on the types and their members will be removed.
Code inside the members will be replaced with a
`throw new NotSupportedException ();`.
The msbuild test app `MyReleaseBuild` has been updated to test that the
optimization is working as expected (device builds are slow so reusing
this test has little impact in test time).
Basically the test ensure that `UIWebView` is used and cannot be removed
by the compiler (optimization) or the managed linker (since it's
referenced). Since the optimization is enabled then we can `grep` then
final `.app` directory to ensure there's no mention of `UIWebView` inside
any of the files that would be submitted.
The application can be run, by itself, and will turn green if OK, red if
`DeprecatedWebView` can't be found (skeleton replacement for `UIWebView`)
or orange if a `NotSupportedException` is thrown.
Finally introspection tests have been updated to skip over the deprecated
(and renamed) types. It should not be an issue right now, since this
optimization is not enabled by default, but it made testing easier.
Using this option it's possible to test for the presence of a type
reference in both pre-linked and post-linked assemblies.
This makes it possible to detect if
* a 3rd party assemblies are using some specific type you would like to avoid;
* a type reference has been removed during the build (e.g. linker)
Notes:
* Custom attributes are encoded differently and not included in the assembly type references metadata.
* Assembly that define a type `X` do not have a reference (but the definition) of the type (and won't be reported).
If either the pre or post-linked warnings are not useful then it's possible
to add `-nowarn:150x` to exclude the results.
E.g.
* `-nowarn:1502` would not report references in pre-linked assemblies;
* `-nowarn:1503` would not report references in post-linked assemblies;
Finally `-warnaserror:150x` can be used to stop a build that would not
satisfy either the pre or post-linked condition.
* `-warnaserror:1502` would not report references in pre-linked assemblies;
* `-warnaserror:1503` would not report references in post-linked assemblies;
_side note_ this was first done on `d16-6` to ease backports as `master`
has multiple changes for localization. A similar PR will be done for
`master` once merged.
This optimization can be enabled when it's not possible to use the
managed linker (e.g. **Don't link**) or when the managed linker cannot
remove references to deprecated types that would cause an application
to be rejected by Apple.
References to the existing types will be renamed, e.g. `UIWebView` to
`DeprecatedWebView`, in every assemblies.
The type definition is also renamed (for validity) and all custom
attributes on the types and their members will be removed.
Code inside the members will be replaced with a
`throw new NotSupportedException ();`.
The msbuild test app `MyReleaseBuild` has been updated to test that the
optimization is working as expected (device builds are slow so reusing
this test has little impact in test time).
Basically the test ensure that `UIWebView` is used and cannot be removed
by the compiler (optimization) or the managed linker (since it's
referenced). Since the optimization is enabled then we can `grep` then
final `.app` directory to ensure there's no mention of `UIWebView` inside
any of the files that would be submitted.
The application can be run, by itself, and will turn green if OK, red if
`DeprecatedWebView` can't be found (skeleton replacement for `UIWebView`)
or orange if a `NotSupportedException` is thrown.
Finally introspection tests have been updated to skip over the deprecated
(and renamed) types. It should not be an issue right now, since this
optimization is not enabled by default, but it made testing easier.
This makes the `--time` options more useful to see inside the linker's
pipeline steps.
This was used only in `mtouch` before (and missed some steps [1]).
Now it's shared between both tools.
[1] not sure why... merge issue/backport maybe ?
Using this option it's possible to test for the presence of a type
reference in both pre-linked and post-linked assemblies.
This makes it possible to detect if
* a 3rd party assemblies are using some specific type you would like to avoid;
* a type reference has been removed during the build (e.g. linker)
Notes:
* Custom attributes are encoded differently and not included in the assembly type references metadata.
* Assembly that define a type `X` do not have a reference (but the definition) of the type (and won't be reported).
If either the pre or post-linked warnings are not useful then it's possible
to add `-nowarn:150x` to exclude the results.
E.g.
* `-nowarn:1502` would not report references in pre-linked assemblies;
* `-nowarn:1503` would not report references in post-linked assemblies;
Finally `-warnaserror:150x` can be used to stop a build that would not
satisfy either the pre or post-linked condition.
* `-warnaserror:1502` would not report references in pre-linked assemblies;
* `-warnaserror:1503` would not report references in post-linked assemblies;
_side note_ same as https://github.com/xamarin/xamarin-macios/pull/7925
except that this one uses the localized mtouch/mmp errors only in master (so far)
We can end up with a format that has `{x}` inside it and no argument. If
this is logged (which depends on verbosity level) then we end up with an
uncaught exceptions and either `MT0000` or `MM0000` errors.
This happens in #7904 due to other, unrelated, issues (a variable is not
expanded) but this can happen in other circumstances, e.g. a file could
be named `{x}.cs`.
The easy fix is to use the right `Console.WriteLine` overload if there
are no arguments provided. This is always good since it avoid an non
required call to `String.Format`.
Fixes https://github.com/xamarin/xamarin-macios/issues/7904
* [xcode11.4] Add xcode 11.4 b1 initial support
* [xtro] re-enable PDFKit
* Disable watchOS and fix xtro
Unfortunately watchOS simulator hangs when we try to deploy to it
and it keeps our tests timing out. Disabling for now until we
can investigate more.
Disables PDFKit on xtro in macOS
* [jenkins] Switch to use the catalina bot group (#7819)
* Bump maccore to get fix for launching the simulator for watch apps.
New commits in xamarin/maccore:
* xamarin/maccore@546270c8f9 [Xamarin.Hosting] Fix the name of the notification we get when the simulator has launched. (#2145)
Diff: 55957e908d..546270c8f9
* [tests] Diable watch due to time out, enable 10,15,4 in intro, fix min version
* Bump macios-binaries to get updated binary mlaunch as well.
New commits in xamarin/macios-binaries:
* xamarin/macios-binaries@f8c6e63 Bump mlaunch to xamarin/maccore@546270c8f9
Diff: eb6980e8b6..f8c6e63228
* [msbuild] Reflect ibtool changes in our tests
Looks like Apple reverted some changes introduces in Xcode 11
in ibtool, for more context see xamarin/xamarin-macios#6970
* [mtouch] Workaround strange behavior of realpath.
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto
Whitney Schmidt
Manuel de la Pena
Waleed Chaudhry