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
The change allows to state the tests that have to be ran. ATM with these
changes, the vsts pipeline must add the following to the env vars:
* tvOS device pipelines: Must add run-tvos-tests to the labels.
* iOS device pipelines: Must add run-ios-tests to the labels.
This will ensure that only the tests for the devices are ran and if the
tests pass we get a green build with no unexpected skips.
* [msbuild] Add reference to `System.Drawing.Common.dll` to XI projects.
Fixes https://github.com/mono/mono/issues/13483 :
```
@akoeplinger: Since we moved types from Mono.Android.dll and
Xamarin.iOS/WatchOS/TVOS.dll to System.Drawing.Common.dll user projects
would fail to compile. We need to add some msbuild logic to add a
reference to the assembly automatically.
```
* [msbuild] Implement the same fix for XM projects as well.
* [msbuild] Update Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* tests.
We're including a new assembly, which means the
Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* must be updated
accordingly.
Also modify these tests so that test assert that fails lists the actual
assembly that's missing, i.e. instead of this:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
#1
Expected: 6
But was: 7
we now print:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
References
Expected: equivalent to < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
But was: < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Drawing.Common.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
* [tests] Adjust Xamarin.MMP.Tests.AssemblyReferencesTests.ShouldNotAllowReference_ToSystemDrawing.
The test was verifying that referencing System.Drawing.dll and trying to use
System.Drawing.RectangleF would fail to compile (because System.Drawing.dll
shouldn't be resolved in this case).
The addition of System.Drawing.Common.dll breaks this assumption, because now
we ship System.Drawing.RectangleF, so the code that was supposed to fail to
compile works just fine instead.
So modify the test to verify that there's no System.Drawing.dll in the final
bundle.
* Remove workarounds for mono/mono#13483.
* [msbuild] Create a way out if automatically referencing System.Drawing.Common.dll causes problems.
* [msbuild] Adjust variable name and boolean logic according to review.
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.
[d16-2] Add support for running tests with the earliest possible simulator, and use it for introspection tests.
* Add support for running tests with the earliest possible simulator
(currently iOS 8.1, tvOS 9.1 and watchOS 2.0).
* Make the introspection tests run with the earliest possible simulator.
* Fix several binding issues (mostly missing availability attributes), and a
couple of issues in the introspection tests themselves.
Reference: https://github.com/xamarin/xamarin-macios/issues/3668.
This is a backport of #6004, since it will probably be useful for the next Xcode release.
The system-dependencies.sh script greps in Make.config for the
EXTRA_SIMULATORS variable, and the grepping wasn't able to correctly parse the
previous variable definition, so make it simpler so that
system-dependencies.sh understands it.
We automatically create simulators when needed, but it won't work if the
simulator runtime isn't installed. So handle the case where a test might not
have a simulator to execute in correctly.
Fixes these test failures:
1) Test Failure : Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").FrameworksEmbeddedProperly(True)
#RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
2) Test Failure : Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildFinalProject(True)
#RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
Fixes https://github.com/xamarin/xamarin-macios/issues/5974.
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).
Fixes this test:
Xamarin.MTouch.AppAndExtensionWithBindingFramework: Expected execution to succeed, but exit code was 1, and there were 2 error(s): build app
error MT5210: Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
error MT5202: Native linking failed. Please review the build log.
Rolf Bjarne Kvinge
Bernhard Urban
monojenkins
Sebastien Pouliot