Context: https://dotnet.microsoft.com/platform/support/policy/maui
> A major version of .NET MAUI receives support for a minimum of 6
> months after a successor (the next major release) ships. For
> example, .NET MAUI 6.0 will be supported for 6 months after .NET
> MAUI 7.0 ships. Similarly, .NET MAUI 7.0 will receive support for 6
> months after .NET MAUI 8.0 ships.
By the time .NET 8 GA ships, .NET 6 MAUI projects will not be supported.
Remove .NET 6 support from our .NET 8 workloads.
We need the latest released version numbers for the previous .NET version so
that we can reference and consume those when building projects using the
corresponding target framework.
Luckily we have a system for keeping dependencies up-to-date, so let's use it
to notify the current branch for any updates to the release branch for the
previous .NET version.
Then I had to bump the Xamarin.iOS version too, so that we have the same commit distance for both, otherwise this happens:
```
*** The commit distance for Xamarin.iOS (111) and Xamarin.Mac (0) are different.
*** To fix this problem, bump the revision (the third number) for both IOS_PACKAGE_NUMBER and MAC_PACKAGE_NUMBER in Make.versions.
*** Once fixed, you need to commit the changes for them to pass this check.
```
The KnownFrameworkReference now references the exact versions of the ref and runtime
packs we're shipping with the sdk pack, instead of telling the build to use whatever
version is defined in the workload.
Then in the workload we specify the latest released version of the .NET 6 for the
ref and runtime packs.
Finally we add an aliased sdk pack, which points to the .NET 6 sdk pack, and
when we're building a .NET 6 TargetFramework we load this aliased sdk pack
instead of the one we're shipping with this workload.
Putting this together means that:
* When we're building a .NET 7 TargetFramework, we load the sdk pack shipped
with the workload, which adds a KnownFrameworkReference which references the
ref and runtime packs with the same version as the sdk pack.
* When we're building a .NET 6 TargetFramework, we load the (aliased) sdk pack
which points to the latest stable .NET 6 sdk pack. That sdk pack will add a
KnownFrameworkReference that tells the build to use the ref and runtime pack
versions specified in the workload - which are now pointing to the .NET 6
ref and runtime pack versions.
Thus we use the .NET 6 sdk, ref and runtime packs when building a .NET 6
TargetFramework, and we use the .NET 7 sdk, ref and runtime packs when
building a .NET 7 TargetFramework.
According to the workload design spec [1], this is supposed to be implemented
by using aliased ref and runtime packs, but that doesn't work due to
https://github.com/dotnet/sdk/issues/26384.
Fixes https://github.com/xamarin/xamarin-macios/issues/15375.
[1]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md?rgh-link-date=2022-06-30T08%3A25%3A10Z#side-by-side-workload-pattern
Adjust our versioning scheme so that the NuGet version is
`Major.Minor.CommitDistance`. The previous scheme ("Major.Minor.<fixed-ish
version>") causes problems on branches producing stable builds, because each
new commit would end up with the same NuGet version, and we wouldn't be able
to push those to a NuGet feed because there might already be an existing
version there.
By using the commit distance in the NuGet version we ensure that every commit
has a different version.
This is a follow up to 92ee92eeb5, where we
changed the assembly version from four digits to three digits (i.e not include
the build number), because our managed API should be identical for (released)
versions where only the build number changes.
In this PR we go a bit further, because we're not supposed to have any API
differences unless the first two parts of the product version changes, which
means that we should only use need the two first parts of our product version
as the assembly version.
* [Xcode13.2] Bump to Xcode 13.2 RC (#13497)
* [Xcode13.2] Bump to Xcode 13.2 Beta 2
Breaking changes addressed for legacy
* HomeKit
* CallKit
* CoreLocation
* [xcode13.2] Bump to Xcode 13.2 RC and apply feedback
* [AppKit] Fix missing Notifications
* Fix xtro
* [xcode13.2] Bump versions and use stable Xcode 13.2
* [monotouch-tests] Make TestAddingByComponents work on the last day of the year
Happy New Year!!
* NO BOM PLZ!
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@9acbbed1f6 [mlaunch] Add support for Xcode 13 beta 1. (#2452)
* xamarin/maccore@e48f75c0b6 [Xamarin.Hosting] Fix the --stdout arg not being forwarded to DeviceLaunchConfig (#2435)
* xamarin/maccore@109c695b1b [Xamarin.Hosting] Fix help string for launchdev argument (#2429)
Diff: cddbd1915d..9acbbed1f6
* [xtro] Fix generation of .pch files
* [xtro] Fix deprecated check to handle (anonymous) declarations and enable latest C# syntax in project
* [xtro] Fix _sanity_ checks
* [xtro] Update todo for beta 1
* [Siminstaller] Force siminstaller to use the xcode 12.5 url
Related issue: https://github.com/xamarin/xamarin-macios/issues/11881
* Fix introspection failures (due to [breaking] changes)
* [tests][intro] Fix hang for tvOS
Creating an instance of `NSMetadataQuery` hangs the simulator.
Even after (xharness) timeout the simulator is not in a good state
to run further tests and every new (tvOS) test will also hang...
* [tests][intro] Same hang for watchOS
except that further test execution does not seem affected (like tvOS)
```
CoreSimulator 772.1 - Device: Apple Watch Series 3 - 38mm (watchOS 8.0) - created by XHarness (42262867-E060-40C0-803E-6DA676AF50CC) - Runtime: watchOS 8.0 (19R5266p) - DeviceType: Apple Watch Series 3 - 38mm
Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread
0 com.apple.Foundation 0x00007fff21470bd0 -[NSMetadataQuery dealloc] + 432
1 libobjc.A.dylib 0x00007fff200d11f7 objc_object::sidetable_release(bool, bool) + 177
2 com.apple.Foundation 0x00007fff21470a03 -[NSMetadataQuery init] + 64
3 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107efc139 xamarin_dyn_objc_msgSend + 217 (trampolines-x86_64-objc_msgSend.s:15)
4 ??? 0x000000010c76d4f6 0 + 4504081654
5 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107cffc85 mono_jit_runtime_invoke + 1621 (mini-runtime.c:3197)
6 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e177d8 do_runtime_invoke + 54 (object.c:3052) [inlined]
7 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e177d8 mono_runtime_invoke_checked + 136 (object.c:3220)
8 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e1e3c5 mono_runtime_try_invoke_array + 2101 (object.c:5601)
9 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107daf977 ves_icall_InternalInvoke + 871 (icall.c:3927)
10 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107dc0167 ves_icall_InternalInvoke_raw + 103 (icall-def.h:667)
11 ??? 0x000000010a232799 0 + 4465043353
12 ??? 0x000000010c76e08b 0 + 4504084619
```
* [tests][monotouch-test] Fix failures with xcode 13 beta 1
* [tests][mmptest] Use a FAT framework that's build with x86_64 and arm64
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* [dotnet-linker] Templateify the install logic.
* [builds] Templateify the Versions.plist install logic.
* [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform.
Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions.
* [dotnet] Templateify some build code.
This version of Xcode requires macOS 11.0 or later.
New commits in xamarin/maccore:
* xamarin/maccore@de616ca53e [mlaunch] Fix dependencies for Xcode 12.5 beta 1 (#2387)
* xamarin/maccore@e93375583c [Actions] Fix rebase trigger.
* xamarin/maccore@0dfeb85ff6 [CI][VSTS] Add information when the external tool fails. (#2377)
* xamarin/maccore@87e165fdbb Remove Vincent as a code owner 😞 (#2368)
* xamarin/maccore@55a700bb5b [build] Add /restore to Xamarin.Analysis build (#2366)
* xamarin/maccore@2d9f8a9685 Bump to xamarin/xamarin-analysis@95245313 (#2362)
Diff: 428964bf32..de616ca53e
* Bump system mono to the latest available 2020-02 package. (#10402)
This makes xamarin-macios build on Apple Silicon, and also seems to get an
updated csc that fixes a problem with nullability warnings/errors.
* [tests] Fix mmp-regression build
```
10:59:46.5383210 Making all in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/mmp-regression
10:59:46.5392610 TargetFrameworkFallbackSearchPaths=/Users/builder/azdo/_work/1/s/xamarin-macios/_mac-build/Library/Frameworks/Mono.framework/External/xbuild-frameworks MSBuildExtensionsPathFallbackPathsOverride=/Users/builder/azdo/_work/1/s/xamarin-macios/_mac-build/Library/Frameworks/Mono.framework/External/xbuild make all
10:59:46.6208220 /Applications/Xcode_12.5.0-beta.app/Contents/Developer/usr/bin/make clean
10:59:46.6956100 /Applications/Xcode_12.5.0-beta.app/Contents/Developer/usr/bin/make build
10:59:46.7422460 GEN dylib/libTest.dylib
10:59:46.8094820 ld: library not found for -lSystem
10:59:46.8097590 clang: error: linker command failed with exit code 1 (use -v to see invocation)
10:59:46.8110310 make[2]: *** [dylib/libTest.dylib] Error 1
10:59:46.8112570 make[1]: *** [run] Error 2
10:59:47.0030120 Process make exited with 2
```
This happens on BigSur as it does not find the default location anymore...
* [tests] Do not test GKLeaderboardViewController on BigSur
The issue is the OS version, not the Xcode version. Update check
to skip that test on macOS 11+
* [tests] Fix MSBuild tests / integration
The test cannot work on BigSur since while you can `dlopen` the library
you can open `fopen` it as a file (and can't embed it for the test).
```
12:31:23.9407820 CSC : error CS1566: Error reading resource 'libz.dylib' -- 'Could not find file "/usr/lib/libz.dylib"' [/Users/builder/azdo/_work/1/s/xamarin-macios/tests/msbuild/Xamarin.MacDev.Tests/bin/Debug/net472/tmp-test-dir/msbuild-tests201/XM45Binding.csproj]
12:31:23.9407900 Done Building Project "/Users/builder/azdo/_work/1/s/xamarin-macios/tests/msbuild/Xamarin.MacDev.Tests/bin/Debug/net472/tmp-test-dir/msbuild-tests201/XM45Binding.csproj" (default targets) -- FAILED.
```
* [tests] Fix MTouch tests failures
* `nm` changed it's output and test was updated
* `clang` linking has a much higher limit for it's command-line length
At least it does not seem to be OS specific since both 10.15 and 11.0
returns the same maximum
```
$ getconf ARG_MAX
1048576
```