This allows the optimization to be disabled in cases where one, or
many, a custom attribute(s) are required by the application at runtime.
While not ideal disabling this single step is much better than disabling
linking for the whole application.
A better approach is described in https://github.com/xamarin/xamarin-macios/issues/6048
but this configuration optimization makes sense independently of it.
Fix https://github.com/xamarin/xamarin-macios/issues/3655
An mlaunch fix in master required a code change in xamarin-macios; when
backporting this mlaunch fix to d16-2 the corresponding xamarin-macios fix was
not, causing the build to break.
Fixes this:
[...]
Build FAILED.
"/Users/builder/jenkins/workspace/xamarin-macios/maccore/tools/mlaunch/Xamarin.Hosting/Xamarin.Hosting.sln" (default target) (1) ->
"/Users/builder/jenkins/workspace/xamarin-macios/maccore/tools/mlaunch/Xamarin.Hosting/Xamarin.Hosting.csproj" (default target) (2) ->
(CoreCompile target) ->
/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/common/MachO.cs(10,15): error CS0234: The type or namespace name 'Bundler' does not exist in the namespace 'Xamarin' (are you missing an assembly reference?) [/Users/builder/jenkins/workspace/xamarin-macios/maccore/tools/mlaunch/Xamarin.Hosting/Xamarin.Hosting.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:03.63
make[3]: *** [Xamarin.Hosting/Xamarin.Launcher/bin/Debug/mlaunch.app] Error 1
The arm64_32 slice for watchOS apps will always use the 'unified' mode, while
the armv7k can be both 'unified' and 'compat' depending on the deployment
target, so we need to keep track of this per Target.
This PR does not change anything related to arm64_32, that will come in a
later PR.
We often (e.g. previews, service releases) update the API diff during
a release cycle. The current code generated a new GUID every time, which
is not what correct since it's the same document.
This uses an MD5 digest of the filename as the source of the GUID so
it will remain constant once created (and updated).
Some code now need to be initialized a few lines earlier... otherwise we
end up with an error like:
```
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/bin/mmp --version
error MM0000: Unexpected error - Please file a bug report at https://github.com/xamarin/xamarin-macios/issues/new
System.InvalidOperationException: Nullable object must have a value.
at System.Nullable`1[T].get_Value () [0x0000d] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-02/external/bockbuild/builds/mono-x64/external/corefx/src/Common/src/CoreLib/System/Nullable.cs:48
at Xamarin.Bundler.Driver.get_TargetFramework () [0x00001] in /Users/poupou/git/xamarin/xamarin-macios/tools/common/Driver.cs:198
at Xamarin.Bundler.Application.get_Platform () [0x00001] in /Users/poupou/git/xamarin/xamarin-macios/tools/common/Application.cs:62
at Xamarin.Bundler.RuntimeOptions.ParseHttpMessageHandler (Xamarin.Bundler.Application app, System.String value) [0x0002f] in /Users/poupou/git/xamarin/xamarin-macios/src/ObjCRuntime/RuntimeOptions.cs:43
at Xamarin.Bundler.RuntimeOptions.Create (Xamarin.Bundler.Application app, System.String http_message_handler, System.String tls_provider) [0x00007] in /Users/poupou/git/xamarin/xamarin-macios/src/ObjCRuntime/RuntimeOptions.cs:34
at Xamarin.Bundler.Driver.Main2 (System.String[] args) [0x00a78] in /Users/poupou/git/xamarin/xamarin-macios/tools/mmp/driver.cs:377
at Xamarin.Bundler.Driver.Main (System.String[] args) [0x00015] in /Users/poupou/git/xamarin/xamarin-macios/tools/mmp/driver.cs:211
```
* [runtime] Add an inner exception parameter to Runtime.CreateProductException.
This allows us to simplify code by using inner (and outer) exceptions as
a means to provide information instead of passing extra information
around in order to create decent exceptions.
One example is how we pass the selector and method name to the method
that converts from a native id to a managed NSObject instance: passing
this information is not necessary anymore if we can use two exceptions,
one for the failure to convert from an id to a NSObject instance,
wrapped in a second that tells which method/selector call ran into this
conversion problem.
* [runtime] Throw better exceptions when the dynamic registrar can't marshal something.
* [runtime] Throw a better exception when something goes wrong when trying to marshal a return value.
* [runtime] Use inner exceptions to convey failure information instead of trying to create a single exception with all we know.
* Fix merge problem.
* [registrar] Make a copy of the static registrar for Xamarin.Mac/Classic.
Make a copy of the static registrar for Xamarin.Mac/Classic, one which is
compatible with the binary artifacts we ship for Xamarin.Mac/Classic
(libxammac, XamMac.dll).
This way the static registrar can evolve in the future, without breaking
Xamarin.Mac/Classic.
* [runtime] Make a copy of the runtime headers too.
* Update comment.
* [mmp] Delay creating a Target instance until we know if we're a Classic or Unified app.
Otherwise the wrong static registrar might be created.
* [tests] Add sample tester.
Add a unit project that looks for iOS/macOS/tvOS sample projects in several
repositories, and builds them all.
* [tests][sampletester] Remove known issue which has now been fixed.
* [tests] Only run sample tests on CI in Azure Devops.
* Remove the possibility of automatically running the sample tests with
xharness (so the sample tests won't run on PR bots or internal bots when the
'run-all-tests' label is added). It's still possible to run the sample tests
manually from the xharness web UI.
* Automatically trigger the sample test run in Azure Devops if the
'run-sample-tests' label is applied to a PR (and that PR is executed on
internal Jenkins).
* Fix typo.
* Fix path.
* Verbose output to track down scheduling failure.
* Bump maccore to get improved debug spew.
Diff: f527c9c526..f89d74b165
* [tests][sampletester] Fix build for TodoWCF.
This fixes an issue with the api comparison since the api comparison fails if
it detects unexpected modified files. Putting the temporary files in
APIDIFF_DIR makes sure the api comparison doesn't see those files as
unexpectedly modified.
Fixes https://github.com/xamarin/maccore/issues/1522.
Fixes this NRE:
error MT0000: Unexpected error - Please file a bug report at https://github.com/xamarin/xamarin-macios/issues/new
System.ArgumentNullException: Value cannot be null.
Parameter name: collection
at System.Collections.Generic.List`1[T].InsertRange (System.Int32 index, System.Collections.Generic.IEnumerable`1[T] collection) [0x00003] in <a104f9cbbafd4348bcc580acb0a3f8a8>:0
at System.Collections.Generic.List`1[T].AddRange (System.Collections.Generic.IEnumerable`1[T] collection) [0x00000] in <a104f9cbbafd4348bcc580acb0a3f8a8>:0
at Xamarin.Bundler.Application.BuildApp () [0x00040] in /work/maccore/master/xamarin-macios/tools/mtouch/Application.cs:1541
at Xamarin.Bundler.Application.BuildNative () [0x0001f] in /work/maccore/master/xamarin-macios/tools/mtouch/Application.cs:903
at Xamarin.Bundler.Application+<>c.<BuildAll>b__148_2 (Xamarin.Bundler.Application v) [0x00000] in /work/maccore/master/xamarin-macios/tools/mtouch/Application.cs:840
at System.Collections.Generic.List`1[T].ForEach (System.Action`1[T] action) [0x0001e] in <a104f9cbbafd4348bcc580acb0a3f8a8>:0
at Xamarin.Bundler.Application.BuildAll () [0x00076] in /work/maccore/master/xamarin-macios/tools/mtouch/Application.cs:840
at Xamarin.Bundler.Driver.Main2 (System.String[] args) [0x004a1] in /work/maccore/master/xamarin-macios/tools/mtouch/mtouch.cs:1369
at Xamarin.Bundler.Driver.Main (System.String[] args) [0x00015] in /work/maccore/master/xamarin-macios/tools/mtouch/mtouch.cs:877
- A long while ago, this hack was added to mmp:
// Shutup the warning until we decide on bug: 36478
if (shortendName.ToLowerInvariant () == "intl" && IsUnifiedFullXamMacFramework)
- This breaks use cases were we explicitly ask for that file, so let's
fix that for now until we can fix the root cause for real
It's needed at runtime since it changes exception handling behavior.
The "link sdk" Linker_RuntimeWrappedException() test relies on it,
but this never showed up there since "link sdk" doesn't link the main assembly.