Fixes:
?fixed-todo? Entry '!missing-pinvoke! AudioSessionAddPropertyListener is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionGetProperty is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionGetPropertySize is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionInitialize is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionSetActive is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionSetActiveWithFlags is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-pinvoke! AudioSessionSetProperty is not bound' in 'MacCatalyst-AudioToolbox.todo' is not found in corresponding 'MacCatalyst-AudioToolbox.raw' file
?fixed-todo? Entry '!missing-enum! NSTextWritingDirection not bound' in 'MacCatalyst-UIKit.todo' is not found in corresponding 'MacCatalyst-UIKit.raw' file
Sanity check failed (8)
make: *** [classify] Error 8
* Update dependencies from https://github.com/dotnet/installer build 20210408.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21208.1
* Update dependencies from https://github.com/dotnet/installer build 20210409.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21209.4
* Update dependencies from https://github.com/dotnet/installer build 20210410.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21210.1
* same P4 specific fix as ccb43cba56
but the ICU support was added based on P3 but merged after ^
* Update dependencies from https://github.com/dotnet/installer build 20210412.5
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21212.5
* Update dependencies from https://github.com/dotnet/installer build 20210413.70
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21213.70
* Update dependencies from https://github.com/dotnet/installer build 20210414.14
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21214.14
* Update to new package names
Thanks @pjcollins for the heads up https://github.com/xamarin/xamarin-macios/pull/11175#issuecomment-819936692
* Update dependencies from https://github.com/dotnet/installer build 20210415.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21215.1
* Fix build (path changed to include '.mono')
* remove more '.mono' special case that are not needed anymore
* Update dependencies from https://github.com/dotnet/installer build 20210415.12
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21215.12
* Fix building apps (it now finds the native libs)
Credits to @filipnavara
8325f8dadc
* Add back IsTrimmable (or nothing gets linked)
* Update dependencies from https://github.com/dotnet/installer build 20210418.6
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21218.6
* Keep downloading the CoreCLR runtime packs.
* [runtime] Adjust the build to link with the correct runtime library for CoreCLR.
* [tests][monotouch-test] Ignore NSTimeZoneTest / All_28300 on dotnet as it hangs
Introduced with https://github.com/dotnet/runtime/pull/48931
Issue https://unicode-org.atlassian.net/browse/ICU-21591
PR https://github.com/unicode-org/icu/pull/1699
* [dotnet][msbuild] Add more (missing) '\'
Fix satellite/location assemblies and some unit tests
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Otherwise a `[SupportedOSPlatformAttribute ("ios12,3")]` (should be a
dot, not a comma) would throw a `NullReferenceException` making it
harder to track down the error
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>
With P3 addition on ICU we must now link the native executable as C++.
Remove an old workaround, in many tests, referencing old (5.0/previews)
packages that caused native link time failures.
ref: https://github.com/mono/linker/issues/1139
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
Those are called respectively inside `xamarin_vm_initialize` and
`xamarin_bridge_initialize` functions.
This fix the **AppContext.GetData always return null for iOS** issue
https://github.com/dotnet/runtime/issues/50290
Thanks for @filipnavara for diagnosing this quicker than anyone else!
Added unit tests to ensure `AppContext.GetData` can read back the values
we're providing at startup.
* Link FrameworkList.xml to a place where MSBuild SDK actually expects it
* Create necessary directories
* Fix symlinks for packaging
* Add test case
* Minor tweak to test case
* Fix cut & paste error
Co-authored-by: Filip Navara <navara@emclient.com>
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>
This test verifies that the build log prints:
"execution started with arguments: actool --errors --warnings --notices --output-format xml1 --output-partial-info-plist "
However, for M1 machines, we don't call actool directly, we go through 'arch'
instead, and this line is printed:
Tool arch execution started with arguments: -arch arm64e /usr/bin/xcrun actool --errors --warnings --notices --output-format xml1 --output-partial-info-plist ...
So adjust the test to cope with both of these behaviors.
* [mono] Bump mono to bring iOS binaries built with xcode12.4
Also bumping system mono pkg to the one that contains arm64 support
New commits in mono/mono:
* mono/mono@eb4c3116eb Build iOS SDK archives on Xcode 12.4
* mono/mono@acb8d8ed6f [2020-02][marshal] Fix VARIANT and BSTR marshaling in structs (#20918)
Diff: be9218f4d1..eb4c3116eb
* [mtouch] fix version logic check
Fixes Unexpected minOS version (expected 8.0.0, found 7.0.0) in MonoTouch.iphonesimulator.sdk/lib/libmono-native-compat.dylib ()
we really only care if it is over the version we expect not below.
* Fix version test
* Bump to .NET 6.0.100-preview.3.21152.10
* Bump to 6.0.100-preview.3.21152.10.
* Bump to 6.0.100-preview.3.21161.7.
* Bump to .NET 6.0.100-preview.3.21161.23.
* [dotnet-linker] Bump ILink and use the supported method of getting an assembly's location.
* Bump to MSBuild.StructuredLogger 2.1.364 to get support for newer binlog versions.
* Fix build failure
Fixes:
TestHelpers/BuildEngine.cs(161,24): error CS0433: The type 'ProjectEvaluationFinishedEventArgs' exists in both 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'StructuredLogger, Version=2.1.0.0, Culture=neutral, PublicKeyToken=d4c7181801cb6448' [/Users/builder/azdo/_work/1/s/xamarin-macios/tests/msbuild/Xamarin.MacDev.Tests/Xamarin.MacDev.Tests.csproj]
* Update parsing binlog properties.
* Be more defensive.
* [tests] Make sure the InternalsVisibleToAttribute constructor isn't linked away.
* [tests] Implement better printing of binlogs.
The latest MSBuild.StructuredLogger made some internal changes to the Message
property which confuses some of our test logic. So implement manual printing
of the log entries that we care about to make sure they conform to the
expected format by the tests (the output is mimicing what 'msbuild /v:diag
foo.binlog' would show).
Sebastien Pouliot
Rolf Bjarne Kvinge
VS MobileTools Engineering Service 2
dotnet-maestro[bot]
Alex Soto
Peter Collins
Manuel de la Pena
Rachel Kang
Filip Navara