This moves our current/legacy attributes to the ones added in dotnet 5 [1].
Short Forms (only in bindings)
| Old | New |
|---------------------------------------|-------------------------------------|
| [iOS (7,0)] | [SupportedOSPlatform ("ios7.0")] |
| [NoIOS] | [UnsupportedOSPlatform ("ios")] |
Long Forms
| Old | New |
|---------------------------------------|-------------------------------------|
| [Introduced (PlatformName.iOS, 7,0)] | [SupportedOSPlatform ("ios7.0")] |
| [Obsoleted (PlatformName.iOS, 12,1)] | [Obsolete (...)] |
| [Deprecated (PlatformName.iOS, 14,3)] | [UnsupportedOSPlatform ("ios14.3")] |
| [Unavailable (PlatformName.iOS)] | [UnsupportedOSPlatform ("ios")] |
Other changes
* `[SupportedOSPlatform]` and `[UnsupportedOSPlatform]` are not allowed on `interface` [2] which means they cannot be used for protocols. This is currently handled by inlining the existing attributes on all members.
* `[ObsoletedInOSPlatform]` was removed in net5 RC. This PR is now mapping the existing attributes to `[Obsolote]`, however multiple ones cannot be added so they need to be platform specific.
Remaining work (manual bindings update) tracked in https://github.com/xamarin/xamarin-macios/issues/11055
References
* [1] https://github.com/xamarin/xamarin-macios/issues/10170
* [2] https://github.com/dotnet/runtime/issues/47599
* [3] https://github.com/dotnet/runtime/issues/47601
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
The main reason why we use the Tcp Tunnel is because we do have
networking issues, one of them is related to the DNS server. If we use
the tunnel we have made a choice and we are sure we will not need the
IPs.
This solves a case in which we have a network failure when we try
to retrieve the IP address using the DNS lookup.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
The main reason why we use the Tcp Tunnel is because we do have
networking issues, one of them is related to the DNS server. If we use
the tunnel we have made a choice and we are sure we will not need the
IPs.
This solves a case in which we have a network failure when we try
to retrieve the IP address using the DNS lookup.
VSTS does not longer have a file with the pat yet it does allow to use
an env variable with the pat provided by the keyvault. Before this
change we have been running all the tests which results in several extra
hours when we do not need to. For example, if nothing was changed in
msbuild, do not run its tests which are 45 mins long.
Changes are:
* provide pat in the env.
* update xharness to use an env var, do not longer read from a file.
fixes: https://github.com/xamarin/xamarin-macios/issues/10923
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
VSTS does not longer have a file with the pat yet it does allow to use
an env variable with the pat provided by the keyvault. Before this
change we have been running all the tests which results in several extra
hours when we do not need to. For example, if nothing was changed in
msbuild, do not run its tests which are 45 mins long.
Changes are:
* provide pat in the env.
* update xharness to use an env var, do not longer read from a file.
fixes: https://github.com/xamarin/xamarin-macios/issues/10923
Sometimes msbuild wants to restore packages during this process, which may
take a while.
Hopefully fixes errors like this:
Harness exception for 'Tests for C6353E8B-BFDA-4F54-93D9-FF0F838BF8EE': System.Exception: Unable to evaluate the property OutputPath.
at Xharness.AppBundleLocator.GetPropertyByMSBuildEvaluationAsync (System.Xml.XmlDocument csproj, System.String projectPath, System.String evaluateProperty, System.String dependsOnTargets, System.Collections.Generic.Dictionary`2[TKey,TValue] properties) [0x00327] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:109
at Xharness.AppBundleLocator.LocateAppBundle (System.Xml.XmlDocument projectFile, System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x000d2] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:49
at Microsoft.DotNet.XHarness.iOS.Shared.AppBundleInformationParser.ParseFromProject (System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x00147] in /_/src/Microsoft.DotNet.XHarness.iOS.Shared/AppBundleInformationParser.cs:71
at Xharness.AppRunner.InitializeAsync () [0x00046] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppRunner.cs:120
at Xharness.Jenkins.TestTasks.RunSimulator.SelectSimulatorAsync () [0x002df] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/RunSimulator.cs:108
at Xharness.Jenkins.TestTasks.AggregatedRunSimulatorTask.ExecuteAsync () [0x00335] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/AggregatedRunSimulatorTask.cs:63
at Xharness.Jenkins.TestTasks.TestTasks.RunInternalAsync () [0x00226] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/TestTask.cs:283
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
The test run can fail even if all the tests pass: in case the process crashes
or deadlocks at exit for instance. Don't overwrite such failures with the unit
test results.
Use a private property (prefixed with underscore) for now, until we can decide
on a better/general name.
Also add a variation to xharness to build monotouch-test with CoreCLR
(building works fine, but it crashes at startup, which is expected at this
point).
Sometimes msbuild wants to restore packages during this process, which may
take a while.
Hopefully fixes errors like this:
Harness exception for 'Tests for C6353E8B-BFDA-4F54-93D9-FF0F838BF8EE': System.Exception: Unable to evaluate the property OutputPath.
at Xharness.AppBundleLocator.GetPropertyByMSBuildEvaluationAsync (System.Xml.XmlDocument csproj, System.String projectPath, System.String evaluateProperty, System.String dependsOnTargets, System.Collections.Generic.Dictionary`2[TKey,TValue] properties) [0x00327] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:109
at Xharness.AppBundleLocator.LocateAppBundle (System.Xml.XmlDocument projectFile, System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x000d2] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:49
at Microsoft.DotNet.XHarness.iOS.Shared.AppBundleInformationParser.ParseFromProject (System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x00147] in /_/src/Microsoft.DotNet.XHarness.iOS.Shared/AppBundleInformationParser.cs:71
at Xharness.AppRunner.InitializeAsync () [0x00046] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppRunner.cs:120
at Xharness.Jenkins.TestTasks.RunSimulator.SelectSimulatorAsync () [0x002df] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/RunSimulator.cs:108
at Xharness.Jenkins.TestTasks.AggregatedRunSimulatorTask.ExecuteAsync () [0x00335] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/AggregatedRunSimulatorTask.cs:63
at Xharness.Jenkins.TestTasks.TestTasks.RunInternalAsync () [0x00226] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/TestTask.cs:283
* [tests] Add a .NET/macOS version of monotouch-test.
I made a macOS version of monotouch-test instead of a .NET version of xammac tests,
so that one day we might have only one test suite for all our API tests.
* Add a project file for .NET/macOS
* Fix some code to handle the fact that we're called 'monotouchtest' on macOS (but
only on .NET).
* Ignore exception marshalling tests, those aren't working yet.
* [xharness] Add support for .NET/macOS and add a macOS version of monotouch-test to our tests
* [dotnet-linker] Skip libSystem.Net.Security.Native and libSystem.Native when collecting native methods to preserve for .NET/macOS.
* [link sdk/link all] Adjust to compile on Mac Catalyst.
* [tests] Adjust the LinkAllRegressionTest.NoFatCorlib to work on Mac Catalyst.
* [tests] Add version checks to make link sdk green on Mac Catalyst.
* [tests] Make the LinkSdkRegressionTest.SpecialFolder test pass on Mac Catalyst.
* [xharness] link sdk and link all are green on Mac Catalyst now.
* Fix test build.
* [tests] Use the 'Apple Developer' code signing key instead of 'iPhone Developer' for xcframework-test.
* [msbuild] Fix resolving the XCFramework for Mac Catalyst.
* [xharness] Enable xcframework-test by default on Mac Catalyst.
We need to add the prefix to the xharness logs or we will not be able to
acceess them via a click.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Fixes this warning when running xharness:
Unknown file: fsharplibrary.fsproj (extension: .fsproj). There might be a default inclusion behavior for this file.
This is mainly to bring in this fix: dotnet/xharness@841114a
(two parameters were swapped and BundleIdentifier was set to AppPath)
Other changes contained:
We don't log the full XML when listing devices anymore, just the file size
SimulatorLoader has a new method that accepts retryCount
* [apitest] Sanitize files by adding missing eols.
* [apitest] Add #if __MACOS__ to all test files.
In preparation for the move into monotouchtest.
* [apitest] Move test files into monotouchtest.
* [tests] Remove the apitest project.
* [monotouch-test] Remove MessagingMac.cs, it's not needed.
* [xammac-tests] Add file PlatformInfo.cs to the build.
* [xammac-tests] Move files into monotouch-test.
* [monotouch-test] Rename test class to not clash with another test class of the same (Objective-C) name.
* [tests] How did this ever work?
Answer: it never did.
* [monotouch-test] Remove duplicated test code.
* [xammac-tests] Define DYNAMIC_REGISTRAR when we're using the dynamic registrar.
* [monotouch-test] Adjust the BundleTest.TestGetBundleId test to cope with having multiple apps for the same bundle id.
* [monotouch-test] Ignore a test that doesn't work with the static registrar (due to a bug in the static registrar).
* Install the Mac Catalyst versions of the mono libraries and BCL.
* The BCL is the same as the one for Xamarin.iOS, which means it has to be post-processed a bit to work with a Xamarin.MacCatalyst.dll
* Build our runtime for Mac Catalyst.
* Build a Xamarin.MacCatalyst.dll with the Mac Catalyst API (it compiles, but I haven't looked at the API surface at all). This PR assumes we're going to have a new TargetFrameworkIdentifier for Mac Catalyst, but a final decision has not been made (see https://github.com/dotnet/runtime/issues/44882), so this may change.
* Build a Xamarin.iOS.dll that contains type forwarders to Mac Catalyst for all the types that exist in both Mac Catalyst and Xamarin.iOS.
* Add support to xharness for running introspection on Mac Catalyst (there are a lot of failures because the API surface is wrong)
* Add support to our msbuild tasks and mtouch for building Mac Catalyst apps. This basically comes down to adding a new case in numerous places to either do things the iOS way or the macOS way, depending on each case.
* Add a __MACCATALYST__ define (which is in addition to the __IOS__ define).
* Bumps mono binaries to include x86_64 watchOS support
* Build runtime/registrar x86_64 slices
* Produce a 64 bit version of Xamarin.WatchOS.dll
* Allow building x86_64 for watch simulators in mtouch
* Let xharness know about x86_64
* [tests] Add x86_64 arch to test-libraries
* Make dotnet package aware of x64
* [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator.
* [xharness] Re-enable some watchOS tests.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
New commits in mono/mono:
* mono/mono@ac596375c7 Add support for OP_FCONV_TO_I to mini-arm64.c. (#20548)
* mono/mono@392fe5b87b [2020-02][watchOS] Add simwatch64 support (#20552)
* mono/mono@a22ed3f094 Fix potential crash for Encoder.Convert (#20522)
* mono/mono@970783731f Bump to F# 5.0 (#20511)
* mono/mono@32ab5066f7 Bump msbuild to fix a build issue
* mono/mono@93a7fe77e8 Ensure special static slots respect alignment. (#20506)
* mono/mono@3db5b35841 [debugger] Switch to GC Unsafe in signal handler callbacks (#20495)
* mono/mono@af315f44c4 [2020-02][corlib] ThreadAbortException protection for ArraySortHelper (#20468)
* mono/mono@ca11fb0fd8 [2020-02] Bump ikvm-fork to include https://github.com/mono/ikvm-fork/pull/20 (#20452)
Diff: be2226b5a1..ac596375c7
This is done early so we can resolve the inner framework, inside the
xcframework, and let the existing framework support do most of the
work.
The resolving code has unit tests. Custom projects for "NoEmbedding"
exists for all supported platforms and executed by xharness.
A sample `xcframework` with tests projects is also available
[here](https://github.com/spouliot/xcframework).
The xcframework test case is based on Rolf's earlier/partial implementation.
https://github.com/rolfbjarne/xamarin-macios/commit/xcframework
Things to note:
Do not rename a framework (like XTest) to use it in an xcframework
(like XCTest). That will fail at codesign but won't give anything
useful. You might think signing the framework (instead of the inner
binary) would solve it. It does, as it codesign, but then the app
crash at startup. At some point you realize some symbols are still
using XTest (not XCTest) and then you can delete several other weird
workarounds (like for `ld`) because all of it was cause by this
never identified rename.
dSYM support (and tests) to be done in a separate PR.
* [watchOS] Add x86_64 simulator support
* Build runtime/registrar x86_64 slices
* Produce a 64 bit version of Xamarin.WatchOS.dll
* Allow building x86_64 for watch simulators in mtouch
* Let xharness know about x86_64
* [tests] Add x86_64 arch to test-libraries
* Make dotnet package aware of x64
* [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator.
* [xharness] Re-enable some watchOS tests.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This involves a few changes:
* Change everything to reference net6.0 instead of net5.0
* Update various variables to be NET6* instead of NET5*
* Reorder build logic to account for that our targets are imported earlier in
the build process:
In the latest .NET 6, our Workloads.targets is imported earlier in the
build. This requires a few changes, because we still need to run most of
our logic later in the process, which we do by adding targets files we
want imported later to the AfterMicrosoftNETSdkTargets property.
What we're loading as soon as possible:
* Our version information (Xamarin.Shared.Sdk.Versions.targets)
* The supported OS versions
(Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets)
* The default OS version
(Xamarin.Shared.Sdk.TargetFrameworkInference.targets).
This is all information that the .NET build require early on.
Changes:
* Rename all files that are loaded early to *.props.
* Updated documentations to reflect these changes.
* Remove Microsoft.<platform>.TargetFrameworkInference.targets, these
files aren't used and don't contain anything useful.
* Move the logic to calculate _ComputedTargetFrameworkMoniker has been
delayed to later, because it needs TargetFrameworkMoniker set.
* Add a StoreAttributesStep to store attributes that are removed by the
linker, but that the static registrar needs.
In particular, in .NET 6 the linker removes the
System.Runtime.CompilerServices.ExtensionAttribute, which the static
registrar needs to handle category methods properly.
This involved copying and slightly modifying the RemoveAttributesBase
code.
This code isn't necessary in main, because we've removed any GuiUnit usage,
but in d16-8 we're still using GuiUnit, which means we still need to process
GuiUnit project references correctly.
This fixes numerous build failures when building Xamarin.Mac tests (in
particular when building Xamarin.Mac tests for older macOS versions).
Manually added `NoBindingEmbedding` to bindings .csproj and removed
`[LinkWith]` attributes.
Also added support for NativeReference to harness and updated the
workaround for watchOS (since it can't link against ModelIO)
Fixed/adapted unit tests wrt change
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto
Peter Collins
VS MobileTools Engineering Service 2
Manuel de la Pena
vs-mobiletools-engineering-service2
Přemek Vysoký