This includes:
* 32-bit version of Xamarin.Mac.dll and OpenTK.dll
* XamMac.dll and XamMac.CFNetwork.dll
* 32-bit versions of the runtime libraries (libxammac.a and friends).
* 32-bit version of the partial static library for Xamarin.Mac.
* Classic support in the generator.
We still ship a few Classic files so that Visual Studio for Mac continue to detect that Xamarin.Mac is installed (otherwise VSfM won't open Classic projects, which makes it impossible to use the migration wizard).
This makes our build slightly faster.
Partial fix for #6300.
* [tests] Don't use unsupported characters in matrix names for yml scripts. Fixesxamarin/maccore#1831.
Matrix names must be alphanumeric (+underscore), and recently Azure DevOps
stopped working correctly if that wasn't the case (unfortunately without a
good error message though, so it took a while to figure it out).
Fixes https://github.com/xamarin/maccore/issues/1831.
* [jenkins] Fix lookup of environment variables from matrix jobs.
* [tests] Don't use unsupported characters in matrix names for yml scripts. Fixesxamarin/maccore#1831.
Matrix names must be alphanumeric (+underscore), and recently Azure DevOps
stopped working correctly if that wasn't the case (unfortunately without a
good error message though, so it took a while to figure it out).
Fixes https://github.com/xamarin/maccore/issues/1831.
* [jenkins] Fix lookup of environment variables from matrix jobs.
Add a separate provisioning script to install Xcode if it's not already installed on the bot.
For some unknown reason it needs to be a separate script, otherwise the provisionator will complain it doesn't know the required GitHub token to download Xcode.
Fixes https://github.com/xamarin/xamarin-macios/issues/6326.
* adding Speech
* Style changes and fixed copyright
* fixing requested changes
* adding spacing to make less red in diff
* adding [DisableDefaultCtor] to SFSpeechRecognitionResult and SFTranscription
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
Context: 4ecedac733/src/Shared/BuildEnvironmentHelper.cs (L567-L586)
Context: 1d71d99837/tools/xabuild
When using `xibuild` to build an SDK-style project:
tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj /restore
It was failing with:
Resolving SDK 'Microsoft.NET.Sdk'...
Project "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj" is building "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj" (GetTargetFrameworks target(s)):
Building with tools version "Current".
msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj : error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.
Looking at this code, it looks pretty familiar -- it came from xabuild!
xibuild was currently setting `MSBuildSDKsPath` via a config file:
<msbuildToolsets default="Current">
<toolset toolsVersion="Current">
<property name="MSBuildSDKsPath" value="/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/Current/bin/Sdks" />
Reviewing the source code for MSBuild, they don't even look for this
value via MSBuild properties... They just look for Visual Studio
directories and a `MSBuildSDKsPath` environment variable. We don't have
to use this in Xamarin.Android, because we do things a different way.
There was craziness involved to get both Windows & Mac working.
For this to work on Mac, we can just set `MSBuildSDKsPath` when
starting the new MSBuild process.
I cleaned up how `MSBUILD_EXE_PATH` is set so both of these variables
are just set via `ProcessStartInfo.EnvironmentVariables`.
Now I can fully build a Xamarin.Forms project that references a
netstandard library with `xibuild`:
$ tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj /restore
...
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:15.83
~~ New Tests ~~
I went ahead and added a new Xamarin.Forms project to test and verify
that it builds. It is the Blank Forms app template from latest VS4Mac.
With the changes to `xibuild`, I was able to build with the in-process
MSBuild APIs.
* Adding PencilKit to the src
* forgot the mac constants
* adding PencilKit and fixed whitespace
* removing whitespace
* removed mac capabilities and added ignore for PencilKit.todo
* removed newline
* added the iOS-PencilKit.ignore file
* removed pencilkit.todo
* adding DesignatedDefaultCtor
No change in beta 2
This enable PushKit on watchOS and macOS.
Availability macros suggest this is available on tvOS 13 but the
headers are not in the tvOS SDK (at least in beta 2)
No change in beta 2
This enable some API in macOS. Headers are now present and some types are
marked as unavailable on macOS - but, sadly, nothing got marked as new
for 10.15 :|
* adding Sound Analysis
* set up error domain and added CMTimeRange for all platforms except watch
* removed whitespaces
* removed more whitespaces
* edited framework files and constants. Changed header names and added todo files
* Apply feedback
* fixing head and skipping functions with class issues
* fixing spacing-tab issues
* Bump VSMac to 8.1.0.2742 to fix msbuild issues (#6279)
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
* [xibuild] Fix incorrect mscorlib.dll being used (#6068)
* [xibuild] Fix incorrect mscorlib.dll being used
The `GuiUnit_NET_4_5` project, when built with `xibuild` uses the wrong `mscorlib.dll`.
From https://github.com/xamarin/xamarin-macios/issues/5760#issuecomment-472457202 :
```
- mscorlib.dll is being used from mono/4.5 and the other system assemblies are from mono/4.5-api
- GuiNet* project is built with xibuild
What is happening here is:
xibuild sets[1] `SetToolsetProperty ("TargetFrameworkRootPath", FrameworksDirectory + Path.DirectorySeparatorChar);`
which points to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`.
This causes $(FrameworkPathOverride) to be set[2] to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks/.NETFramework/v4.5`,
but that doesn't have a mscorlib.dll, so it gets reset[3] to /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5/.
If we don't set TargetFrameworkRoothPath, then we get `FrameworkPathOverride = /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api`,
causing `_ExplicitReference=/Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api/mscorlib.dll`(correct one) to be used.
```
Fixes https://github.com/xamarin/xamarin-macios/issues/5760
1. https://github.com/xamarin/xamarin-macios/blob/master/tools/xibuild/Main.cs#L209
2. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L79
3. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L84
* Revert "Workaround https://github.com/xamarin/xamarin-macios/issues/5760 in generator csproj"
This reverts commit 9bd927bb7f.
The previous commit for xibuild removes the need for this.
* [xibuild] Handle "incorrectly" cased msbuild property names (#6202)
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
Fixed to ignore case.
Fixes https://github.com/mono/mono/issues/14765 .
* [tests] Minor refactor to get better Xcode version parsing.
* Rename Configuration.XcodeVersion to XcodeVersionString.
* Add Configuration.XcodeVersion a parsed Version instane of XcodeString.
* [tests] Ignore all 'MT0099: Not linking with WatchKit because Xcode 11 beta 1' warnings in tests.
* [tests] Adjust min OS version tests for Xcode 11b1.
* [tests] Adjust tests for changes in 'nm' output.
* [tests] Adjust tests for name changes in Clang.
* [tests] Adjust tests for changes in ld warning format.
* [msbuild] 'metal' and 'metallib' aren't in PATH anymore, so use xcrun to execute them.
* [msbuild] Fix DevicePlatformBinDir for the Metal and MetalLib targets on iOS.
Also set the SDKROOT variable, otherwise metal and metallib don't work
properly, and revert the previous attempt at a fix (use xcrun).
* [tests] Simplify version parsing code to not version parse anymore.
* [tests] Add FIXME for once Apple fixes the WatchKit disappearance.
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
Fixes this build error:
Xamarin.iOS.Tasks.WatchKit2("iPhoneSimulator").BasicTest: #RunTarget-ErrorCount
redefinition of 'main'
Failed to compile the file(s) '/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/msbuild/tests/MyWatchKit2IntentsExtension/obj/iPhoneSimulator/Debug/mtouch-cache/i386/main.m'. Please file a bug report at https://github.com/xamarin/xamarin-macios/issues/new
Expected: 0
But was: 2
since we no longer generate two main functions.
* We must bump the min simulator versions, since Apple has bumped what they offer.
* Re-enable simulator provisioning.
* Minor output fix to siminstaller to make the output easier to understand.
* The Photos headers are broken when building in C++ mode.
* The PhotosUI headers include the Photos header, so those don't work either.
* The WatchKit framework just isn't there at all.
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
Fixed to ignore case.
Fixes https://github.com/mono/mono/issues/14765 .
* [XHarness] Remove the old style mscorlib tests.
Remove the old style test and replace it with the xunit equivalent which
has more tests and is provided by the mono package.
* Only skip the mscorlib tests on watchOS devices with 32b. Run them anywhere else.
This fixes an issue with the api comparison since the api comparison fails if
it detects unexpected modified files: https://github.com/xamarin/xamarin-macios/pull/6133#issuecomment-496283224.
Putting the temporary files in APIDIFF_DIR makes sure the api comparison
doesn't see those files as unexpectedly modified.
* [xharness] Refactor a bit to use named types for a few unnamed types with numerous fields.
Anonymous types becomes quite unwieldy the more fields they have.
* [xharness] Remove unnecessary field assignments.
Mono did remove all the tests in a number of assemblies on
ios/tvos/watchos. With a recent change, we report test runs with no
tests as a failure (correctly since it will bring up issues with the
runners).
In this case, the tree assemblies have to be ignored because they trully
do not have tests and the runners are doing the right thing.
Fixes: https://github.com/xamarin/maccore/issues/1652
We can't assume that the cached `lipo` output is part of the `.app`
since the directory for the later could be different.
E.g. we build two .csproj in out `mmptest` inside the same directory
and they share the same `obj` directory (used for caching) but have
different output directories
```
./obj/Release/mmp-cache/libmono-native.dylib
./bin/Release/UnifiedExample.app/Contents/MonoBundle/libmono-native.dylib
./bin/Release/XM45Example.app/Contents/MonoBundle/libmono-native.dylib
```
Without an update building the XM45 project would not include the
**required** `libmono-native.dylib` library and would crash when
executed.
So far this only applies to `QTKit`...
XM will now, by default, avoid natively link with QTKit unless it's
instructed to so explicitly using `--link-prohibited-frameworks`
ref: https://github.com/xamarin/xamarin-macios/issues/6039
* [apidiff] Add rule to get mono-api-info.exe and mono-api-html.exe.
This fixes an issue when bumping mono: when bumping mono, the already
downloaded mono archive isn't applicable (because we've changed to the
previous commit, which has the previous mono hash, whose archive hasn't been
downloaded).
So add a rule to get mono-api-info.exe and mono-api-html.exe, by downloading
the current mono archive.
* [apidiff] Change the name of the unzip stamp and download dir to contain the hash.
This way the logic doesn't get confused when the hash changes (or there's an
old unzip stamp in the directory), and things are downloaded again as
expected.
* [apidiff] Make make not delete temporary files.
Things end up confused if temporary files have been removed by make, but our
stamp file that the temporary files are still there is present.
* [apidiff] No need to make everything depend on the bundled zip.
If everything that needs the bundled zip already depends on it.
* [apidiff] Restore original hash before calculating api diff.
This makes it less annoying when the api diff calculation changes, because
with the previous behavior they were impossible to test in a PR, since any
changes wouldn't take effect until after the PR was merged.
Allow to add extra mtouch arguments to the bcl test applications to configure them. This will allow to pass required specific settings that some tests have, for example, for the linker.
This updates the project generation. We cannot yet fully remove the submodule because:
* We are missing the xunit dlls which should be added in the SDK.
* We have not yet remove all the old style tests. Would make the PR huge, better to deal with it in a diff PR.
* The xunit CoreLib tests have issues loading all the tests, needs some extra work and again, the PR is already large.
Fixes: xamarin/maccore#1199Fixes: xamarin/maccore#1204Fixes: xamarin/maccore#1209Fixes: xamarin/maccore#1510
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
```
Tuning.cs(300,8): warning CS0108: 'LoadOptionalReferencesStep.ProcessReferences(AssemblyDefinition)' hides inherited member 'LoadReferencesStep.ProcessReferences(AssemblyDefinition)'. Use the new keyword if hiding was intended. [/Users/poupou/git/master/xamarin-macios/tools/mmp/mmp.csproj]
```
it's not virtual and it's not being called back annyway.
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
Use for producing API diff for release notes without waiting for a PR,
bots and/or approvals...
Also useful to produce API diff between any versions, not just between
the current revision and a baseline (last stable).
We had issues in the code that adds a type found in an assembly to
ensure that it was not removed by the linker. This resulted in some
assemblies having 0 tests.
Added the needed ignore for the corlib tests and system ones.
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.
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.
* [mtouch/mmp] Split out the RunCommand[Async] methods to a separate file so that the generator can reuse more easily.
* [generator] Show proper errors when failing to compile something.
* Fix grammar
* [linker] Mark protocol interfaces when using the dynamic registrar.
Fixes this monotouch-test failure when using the dynamic registrar and the
linker at the same time:
[FAIL] RegistrarTest.TestProtocolRegistration : UIApplicationDelegate/17669
Expected: True
But was: False
* [tests] Adjust test after linker change.
All Xamarin.iOS apps will now link with QuickLook when using the dynamic
registrar, because NSUrl implements a QuickLook protocol:
fcac64ad6e/src/foundation.cs (L5445).
Adjust LinkAll_Frameworks accordingly, and add a new test that verifies that
the old behavior (not linking with QuickLook when linking all assemblies) is
still correct.
Before we unzip, we remove the target directory. This is a bad idea if the
target directory is also used for other things: in particular it breaks
parallel make if some other target tries to write to the temporary directory.
Instead unzip downloaded files into a subdirectory exclusively used by those
unzipped files, which means we can remove at will before unzipping.
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).
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).
* Share much more marshalling code between the dynamic and static registrar
(by refactoring code into separate functions used by both).
* Fix an issue with multiple out/ref parameters in the dynamic registrar.
* Throw an error instead of silently ignoring out/ref parameter types we don't
completely understand in the dynamic registrar.
* Fix returning Class/SEL out/ref parameters in the static registrar.
* Fix returning NSString out/ref parameters in the dynamic registrar.
* Add/fix support for out/ref arrays everywhere.
* Fix support for the various supported out/ref parameter types in the
generator.
* Add lots of tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/5171.
* [builds] Add support for using cached downloads of the mono archives from ~/Library/Caches.
* [apidiff] Add support for using cached downloads of apidiff bundle from ~/Library/Caches.
* [builds] Move the facade check targets down in the Makefile.
Move the facade check targets below the declaration of their prerequisite
variables (*_BCL_TARGETS), since otherwise the prerequisite variable will be
empty when the facade check targets are read by make, they end up with no
prerequisites at all, and the targets fail.
* [builds] Make the tools build use mono's packaged logic instead of our own.
Make the 'tools64' build use mono's packaged build logic instead of our own.
This is the first step to consuming the BCL from the mono archive.
Also completely refactor the 'tools64' build by removing everything we don't
need and renaming it to 'bcl' (since that's more representative of what it
does).
* [apidiff] Unzip downloaded files into a temporary subdirectory.
Before we unzip, we remove the target directory. This is a bad idea if the
target directory is also used for other things: in particular it breaks
parallel make if some other target tries to write to the temporary directory.
Instead unzip downloaded files into a subdirectory exclusively used by those
unzipped files, which means we can remove at will before unzipping.
* [apidiff] Use mono-api-[info|html].exe from the mono archive.
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.
Existing binding binaries won't have the `[Preserve]` attribute on
the `Handler` field and, with the new optimization, would not work
properly.
This tweak make sure that older, already linker-safe, bindings will
remain this way (safe) in this (and future) versions of both iOS and
macOS SDK.
According to Rolf it's fine to always add since the native linker will
figure out if it's really needed and so customers don't need to do
anything when using -all_load.
Mono started using System.IO.File from CoreFX and it has a different
behavior for File.Copy() when the target is a directory:
It just puts the file into the directory instead of raising an exception.
In order to fix the MT1015 test we just check ourselves whether the target
is a directory.
Up to this commit the test dlls used for the bcl tests were from iOS. Since
the Mono SDK provides the dlls for both missing platforms (TvOS and
WatchOS) we can now use the correct path for the dlls.
There is a small trick to minimize the project generation, since there
is a simple stirng.Replace, the logic now checks the platform under
test and does:
* TvOS - Goes from monotouch_TEST_NAME to monotouch_tv_TEST_NAME
* WatchOS - Gores from monotouch_TEST_NAME to monotouch_watch_TEST_NAME
This commit improves the state of the BCL testing in the following ways:
1. Improve the device tets running. Less apps, faster results.
2. WatchOS apps are left as they were to ensure that we do not have deplouyment/run issues.
We now support the ignore files per assembly name to simplify the
tracking of the ignored tests. All
```
/Users/poupou/git/master/xamarin-macios/tools/linker/MonoTouch.Tuner/RemoveBitcodeIncompatibleCodeStep.cs(14,7): warning CS0105: The using directive for 'Xamarin.Linker' appeared previously in this namespace [/Users/poupou/git/master/xamarin-macios/tools/mtouch/mtouch.csproj]
```
This also centralize other interpreter checks and options in the same
location (making it easier to read / update).
* Warn and switch the REPL if the interpreter is enabled on simulator
Why ? It's confusing to build the same code using different options for
simulator and devices. This is what happens if you try to use features
like `dynamic` or `System.Reflection.Emit`.
So instead of an error, we warn that the interpreter is not supported
and switch to the existing REPL mode.
The JIT remains the only option for the simulator but it allows testing
features without a device.
* Fail early if the interpreter is used on 32bits [1]
The current interpreter only works on 64 bits (so ARM64). However the
error won't be reported, back to the developer, until deployment time.
This temporary [1] fix spot the condition very early and report an error
```
error MT0099 : Internal error : The interpreter is currently only available for 64 bits.
```
instead of the current one at deploy time
```
IncorrectArchitecture: Failed to find matching arch for 32-bit Mach-O input file /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.tNKDlx/extracted/X.app/X
error MT1006: Could not install the application 'X.app' on the device 'Mercure': AMDeviceSecureInstallApplicationBundle returned: 0xe8000087 (kAMDIncorrectArchitectureError).
Application could not be uploaded to the device.
```
[1] https://github.com/mono/mono/issues/9871
* [tests] Fix/renumbered MT0138
The test was using simulator + interpreter which is not _really_
possible, we use REPL in that case - so we're now checking if
assemblies were specified with `--interpreter` to cover both cases.
Also 0138 was already used by `mmp` and the warning was **not**
registered or documented in the errors documents. To avoid
confusion it has been renumbered to 0142 and documented.
* [Foundation] Add an NSArray.FromNSObjects overload that can take an array of INativeObjects.
* [runtime] Use mono_array_setref instead of mono_array_set.
Otherwise the GC won't know about the assignment, and the assigned value can
be freed if it's no longer referenced anywhere else.
Some optimizations are not safe to apply when dynamically loading code
at runtime. This is not possible when ahead-of-time (AOT) compilation
is used, so those options were always enabled in the past. The
interpreter is changing the situation so those optimizations are now
disabled, when the interpreter is enabled.
The disabled optimizations are:
* 'remove-dynamic-registrar' when using the interpreter
This avoid the following exception when unknown (at build time) code
tries to register (at runtime)
```
Unhandled Exception:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> ObjCRuntime.RuntimeException: Can't register the class SubclassDemo.CustomView when the dynamic registrar has been linked away.
```
* 'inline-isdirectbinding' when using the interpreter
This avoid crashing (at runtime) when types are subclasses by the
interpreter (code unknown to `mtouch` at build time).
* 'register-protocols' when the interpreter is enabled
Dynamically loaded code can include protocols. When the optimization is
enabled then they won't be registered and won't work as expected.
Note: It is possible to re-enable the optimization(s), either one or all,
if the interpreter is not used to dynamically load code at runtime.
In both cases we use a different binaries for a few assemblies. They
include support for SRE and a few other things that are not normally
usable on iOS. That's totally fine and not something that can be fixed
(unless you stop using the feature). So this PR simply ignore that
specific case so we don't warn about things that can't be changed (and
are not a problem)
E.g.
```
Warning MT0109: The assembly 'mscorlib.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/mscorlib.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/mscorlib.dll). (MT0109) (XXX)
Warning MT0109: The assembly 'System.Core.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/System.Core.dll). (MT0109) (XXX)
Warning MT0109: The assembly 'System.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/System.dll). (MT0109) (XXX)
Warning MT0109: The assembly 'System.Xml.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/System.Xml.dll). (MT0109) (XXX)
```
E.g. `MetalPerformanceShaders` is unusable in 10.3.1 on the simulator so
trying to build with the static registrar cause simlauncher to be rebuilt
with a **strong** (and not _weak_) reference to the framework. This cause
a crash then the application start
```
Dyld Error Message:
Library not loaded: /System/Library/Frameworks/MetalPerformanceShaders.framework/MetalPerformanceShaders
Referenced from: /Users/USER/Library/Developer/CoreSimulator/Devices/95679F95-CCE7-4733-8376-35E91E97039C/data/Containers/Bundle/Application/0F665B2D-ADAC-4CA0-BD04-33E968B3F268/FailerApp.app/FailerApp
Reason: no suitable image found. Did find:
/System/Library/Frameworks/MetalPerformanceShaders.framework/MetalPerformanceShaders: mach-o, but not built for iOS simulator
```
ref: https://github.com/xamarin/xamarin-macios/issues/5753
document it and adjust the optimization tests.
This allows the optimization to be:
* disabled (if ever needed) on fully AOT'ed applications
* re-enabled for the interpreter (at your own risk)
Fix comparison so the XM profiles do not report _inexistent_ changes for `_Attribute`, `_EventInfo` and `_Exception`. That noise makes it harder to review the diffs (for us) and is incorrect in our published API diffs (for release notes).
Also
* Delete .unzip.stamp on clean
* Skip classic XM diff (binaries won't change)
Reenable the tests and ensure that the failing ones on Modern are
ignored. The bcl tests on mac os x can now make a diff between the
version (Moder/Full) to ignore files so that tests that work in a
version are not ignored in the other one.
Fixes https://github.com/xamarin/maccore/issues/1200
* MachO.cs: Support reading LC_BUILD_VERSION
Newer SDKs set this instead of LC_VERSION_MIN_*
* MachO.cs: Add support for reading Mach-O files inside ar archives.
* [tests] Augment ProductTests.MinOSVersion to test static libraries as well.
* Adjust enum field names to match our naming scheme.
The removal of the XML files broke the comparison with the previous
commit. It did NOT fail the original PR because the targets were
in the previous commit.
And it will fail this PR because the previous commit still does not
have the targets - but it _should_ be fine, once merged, for all
future PR.
Fixes https://github.com/xamarin/maccore/issues/1452
* [XHarness] Ensure we do a nuget restore on bcl imported tests. Fixes#5383
We need to ensure that a nuget restore is done, otherwise we might have
build issues with missing libs.
Fixes https://github.com/xamarin/xamarin-macios/issues/5383
Instead download the assemblies (part of existing bundle.zip) of the
current release and generate the XML locally (no storage in github)
before doing the diff against the newer, just built, assemblies.
reference: https://github.com/xamarin/xamarin-macios/issues/4891
* We only need to do a runtime check on watchOS.
* On watchOS assume we're on a ARM64-based CPU as long as we're not on a
ARMv7k CPU.
Fixes an issue where we failed to detect a 64-bit iOS CPU as ARM64-based (in
particular iPhone X's ARM64v8).
The Mono AOT compiler maintains a set of signatures of compiled methods.
Those signatures are necessary to emit wrappers to enable the transition
from interpreter->AOT code. Thus, they must be collected for each
assembly.
* Improve the behavior when we fail to download the .dvtdownloadableindex file
to report a "Not Found" if we get a "Forbidden" (403) response, since that's
what it really is.
* Improve the behavior when we fail to download the .dvtdownloadableindex file
to check if the requested simulators are already installed instead of always
failing. This makes it possible to manually install the required simulators
if needed (Apple might not have published simulators for the Xcode version
we're using), and this would allow any checks to pass if the required
simulators are already installed.
* Improve the code to modify the PackageInfo XML to not use simple string
replacement (it's too fragile), use proper XML parsing instead.
* Fix "time left" math, I have no idea what my previous math was doing.
Clang will automatically compile .bc files into object code if needed, but
it's done serially. If we do the compilation ourselves, it'll be parallelized.
This makes the dontlink tests build in half the time when building for watchOS
/ Release (it drops from ~15 minutes to ~7 minutes).
The AOT compiler uses the 'outfile' as the base for a temporary .bc file. If
it's not set, the path to the assembly is used as the base instead. This does
not work if we compile the same assembly to multiple architectures (for
instance armv7k+arm64_32), because the temporary file will clash between those
AOT compilations.
This is not a problem for iOS (armv7+armv7s) because we don't compile to
bitcode (.bc files) on iOS.
* [mtouch] Don't use the native linker to create fat executables.
Don't use the native linker to create fat executables, instead link each
architecture separately, and then manually lipo everything together at the
end. This requires a few changes since we need to keep track of the linker
flags per architecture.
The problem is that bitcode files (.bc) do not correspond with a particular
architecture, so the linker can't distinguish between .bc files for armv7k and
.bc files for arm64_32. So if we pass all together to the linker, the linker
will add all .bc files to both architectures, thus duplicating everything (and
the linking fails with duplicate symbols errors).
* [mtouch] Fix building symlinked simulator executables.
* [mtouch] Fix several assumptions about each Target only producing a single executable.
The current code did not consider that overrides could be swept later,
if unused/unmarked by the linker, so we were missing opportunities to
make methods as final.
Also change output to use the full path to files as nodes, instead of just the
filename, and instead use a label to set what's shown to just the filename.
This makes the graph correct when we have multiple files with the same name,
but different paths.
We need our 32-bit and 64-bit assemblies to be identical so that we can avoid
duplicating the .dll in fat apps.
One difference used to be that the .dll contained the full path to the
corresponding .pdb ([1]), but we changed cecil to only write the filename
([2]). Unfortunately this change breaks something else, so it has to be
reverted ([3]).
This implements a different solution: we provide a custom symbol writer to
Cecil, which only writes the filename of the pdb in the .dll, not the full
path.
[1]: https://bugzilla.xamarin.com/show_bug.cgi?id=54578
[2]: https://github.com/jbevain/cecil/issues/372
[3]: https://github.com/jbevain/cecil/pull/554
(cherry picked from commit 53874c863996656eaba43a5582731b93eb6f53b7)
# Conflicts:
# tools/mtouch/mtouch.csproj
Fixes this warning:
tools/bcl-test-importer/BCLTestImporter/BCLTestProjectGenerator.cs(19,17): warning CS0414: The field 'BCLTestProjectGenerator.iOSReleasePattern' is assigned but its value is never used
* Add a Runtime.IsARM64CallingConvention property.
Determining whether we should use the ARM64 calling convention in P/Invokes
gets more complicated with ARM64_32 (which for our purposes is a 32-bit
architecture).
So add a property on the Runtime class to avoid code duplication, and teach
the linker to optimize any calls to this property to a constant value whenever
possible (and the method is marked as optimizable).
Also change our code to use this new property, and make the corresponding
methods optimizable.
Some shuffling in mmp was required, which meant a little bit more code is now
shared between mtouch and mmp.
* Coding style.
* Test tweaks.
* Improve comment.
* Document new optimization
* Move ILReader to shared linker test code location.
* Disable inlining on armv7k.
* Change IsARM64CallingConvention to a read-only field.
We can give the AOT compiler a constant value for a read-only field, so that
the AOT compiler optimizes away the call to the field by using the constant
value.
This commit does not implement this change for the AOT compiler, but using a
read-only field makes it easy to implement it in the future.
* [linker] Remove non-bitcode compatible code, and show a warning.
Remove code not currently compatible with bitcode and replace it with an
exception instead (otherwise we'll assert at runtime).
Also show a warning when we detect this.
This is quite helpful when looking at watch device test runs to filter out
failures we already know about.
This fixes point #2 in #4763.
* Improve documentation.
* Simplify linker code by using a substep.
* Fix whitespace issues.
* Improve reporting.
* Add support for reporting more than one MT2105 at the same time when making
the errors instead of warnings.
* Only report MT2105 for methods that haven't been linked away.
* Format the error message nicer for properties.
* Tweak a bit for warning tests to pass.
* Use ExceptionalSubStep to provide better error information.
* Adjust where linker warnings/errors are reported from to avoid a NullReferenceException.
* Make PreserveSmartEnumConversionsSubStep use error codes that are not
already used elsewhere: this isn't obvious at first, but all
ExceptionalSubStep errors use a range of error numbers (10 numbers from NNN0
to NNN9), so we need to reserve that entire range. In this case there were
other errors using some of the numbers of the range for PreserveSmartEnumConversionsSubStep.
* Make sure there are anchor links for all the variations of each ExceptionalSubStep error.
Rework BCL test importation to generate projects that won't compile instead of
giving up completely in case of generation failure.
This means that xharness can still be used for non-BCL tests even if the
generation of the BCL tests fail.
This is usually not a problem, because these variables are already set when
running from the command-line or xharness. However, it shows up when running
tests directly from VSfM.
Sometimes we just Log a string without any format arguments. This works fine,
until the string comes from the user, and happen to contain braces, in which
case an invalid format exception is thrown.
Adding Log overloads that doesn't take format arguments (nor formats its
input) avoids this problem.
Deserialize cached Objective-C class symbols to match how the objects looked
before serialization. This means storing the Objective-C class name in the
Symbol.ObjectiveCName field, and not the Symbol.Name field.
Fixes https://github.com/xamarin/xamarin-macios/issues/5467.
The small typo made the test projects from mac and ios/tvos/watchos be
in different nodes in the xhanress web page which is ugly. They now wil
appear in the same node.
All the failing tests have been ignored. There are a large number of
tests ignored on the watchOS platform beacuase atm the iOS test dll is
used.
Fixes https://github.com/xamarin/maccore/issues/1135
As with other tests, this have been added because they were present when
we built the test assemblies locally, but they are not present in the
Mono SDK.
Fixes https://github.com/xamarin/maccore/issues/1132
As with other tests, this assembly was added when we built the tests in
the iOS makefile, but they are not present in the Mono SDK.
Fixes https://github.com/xamarin/maccore/issues/1140
Before
```
clang : error : no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ee-interp.a'
clang : error : no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-icall-table.a'
clang : error : no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ilgen.a'
error MT5209 : Native linking error : clang: error: no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ee-interp.a'
error MT5209 : Native linking error : clang: error: no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-icall-table.a'
error MT5209 : Native linking error : clang: error: no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ilgen.a'
MTOUCH : error MT5202: Native linking failed. Please review the build log.
0 Warning(s)
7 Error(s)
```
After
```
MTOUCH : error MT0141: The interpreter is not supported in the simulator. Do not pass --interpreter when building for the simulator.
0 Warning(s)
1 Error(s)
```
We can't share native code between apps and app extensions if the interpreter
settings differ between them, so detect this scenario and automatically
disable native code sharing.
Fixes https://github.com/xamarin/xamarin-macios/issues/5365.
Fixes this problem:
The following files were modified, and they shouldn't have been:
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/src
which shouldn't be reported, since the "file" in question is a directory.
Reference: https://github.com/xamarin/xamarin-macios/pull/5355#issuecomment-452400517
* [xibuild] Add support for /verbose, and use it accordingly.
Also stop using xibuild when it's not needed.
* Use the same verbosity for xibuild as we do for xbuild/msbuild.
This PR adds support to the use of *.ignore files for iOS/tvOS/WatchOS. The files are very similar to those that are use in xtro. We have:
* common-{TestProjectName}.ignore: For those tests that fail in all platforms.
* tvOS-{TestProjectName}.ignore: For tvOS specific failures.
* watchOS-{TestProjectName}.ignore: For watchOS specific failures.
* iOS-{TestProjectName}.ignore: for iOS specific projects.
Two test projects that were ignored previously have been added to show that the code does as advertised:
* SystemDataXunit: xUnit test project example. Fixes https://github.com/xamarin/maccore/issues/1131
* SystemServiceModelWebTests: NUnit test project example. Fixes https://github.com/xamarin/maccore/issues/1137
The files take the name of the failing tests, although we do support ignoring by class/namespace and other combinations, that would make the *.ignore files format more complicated and it is not worth it.
objc_msgSend*_stret doesn't exist on arm64, so trying to call these functions
in our generated P/Invoke wrappers will result in a clang error:
[...]/pinvokes.m:180:69: error: 'objc_msgSend_stret' is unavailable: not available in arm64 (TaskId:243)
So instead generate a call to throw an EntryPointNotFoundException (which is
exactly what would happen if we didn't generate the P/Invoke wrapper).
Fixes https://github.com/xamarin/xamarin-macios/issues/5183.
Only the arm64 slice are built for iOS 7.0 (because that's when arm64 was
introduced), the arm7(s) slices are built for iOS 6.0, which means it's safe
to ignore this warning.
Fixes https://github.com/xamarin/xamarin-macios/issues/5092.
We now download the ios Mono sdk which means that there is no need for
us to build the test assemblies on iOS, WatchOS and tvOS BUT we need to
do so for the Mac tests.
The change includes:
1. Use fo the downloaded test assemblies.
2. Removal of the dependency of building them in the tests.
3. Move back to using reflection for the project generation.
4. Remove the cached project details added in the workaround.
Rolf Bjarne Kvinge
monojenkins
Manuel de la Pena
TJ Lambert
Sebastien Pouliot
Jonathan Peppers
Sebastien Pouliot
Ankit Jain
Alexander Köplinger
Sebastien Pouliot
Bernhard Urban
Vlad Brezae
Alex Soto
Chris Hamons
Vincent Dondain
Bernhard Urban
Marek Safar