We still need some of the source files from the legacy Mono library, but it's
only a few files, so just add them to the git repo.
Also implement caching of the .NET download, which speeds up clean rebuilds
significantly.
Note: all the files in the `builds/mono-ios-sdk-destdir` are a straight import
from the Mono archive, so those shouldn't need much reviewing (nor will I
change them unless absolutely necessary).
On the bots we're executing with Rosetta, and 'arch' returns 'i386' under
Rosetta, so detect when we're executing under Rosetta, and install the arm64
version of .NET in that case as well.
Also fix a bug in the same area in our tests.
This way it can easily be overridden when building from the command line (to provide a different url if the normal url doesn't work for some temporary reason).
The `SdkSupportedTargetPlatformVersion` item group is used for (at least) two things:
1. Generate the `_OR_GREATER` preprocessing symbols:
bfd2919bc4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets (L230-L237)
2. Validate the TargetPlatformVersion:
bfd2919bc4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.TargetFrameworkInference.targets (L233-L246)
The problem is that these two uses aren't equivalent.
Take for example the following scenario:
We release bindings for iOS 10, and a library developer takes advantage of the
bindings for the new iOS version, while at the same time supporting
multi-targeting to older platforms:
```csharp
#if IOS10_0_OR_GREATER
UseNewApi ();
#else
UseOldApi ();
#endif
```
Time passes, iOS 11 comes out, and we stop shipping bindings specifically for
iOS 10 (the APIs themselves would be included in the bindings for iOS 11). The
code above should continue to work, but iOS 10 is not a valid
TargetPlatformVersion anymore. However, with the current situation there's no
way to express this, because the moment we remove the "10.0" version from
SdkSupportedTargetPlatformVersion, the IOS10_0_OR_GREATER define isn't
generated anymore.
We discussed this in a meeting internally, and the suggestion that came up was
to use metadata to handle this situation, and we've decided to add the
"DefineConstantsOnly=true" metadata to items in
SdkSupportedTargetPlatformVersion that are "OS versions we support or have
supported", but not "OS versions we support as TargetPlatformVersion".
Note: we're adding this to .NET 8, but .NET will not understand the new
metadata until .NET 9, which means this won't be a breaking change until .NET
9.
In a different PR I'll add logic to warn if a project uses a
TargetPlatformVersion that is no longer valid (so that people will start
getting a warning in .NET 8 instead of getting surprised by a build error in
.NET 9).
Ref: https://github.com/dotnet/sdk/issues/38016
In .NET the 4 platforms are 4 separate products, so it makes sense that each
Versions.plist only contains information for the corresponding platform.
This means we can share the same logic for all .NET platforms, instead of
having to special-case macOS.
It also decouples legacy logic from .NET logic, which makes it easier to
remove legacy logic when that time comes.
Use the .NET version (the `*_NUGET_VERSION` variables) instead of the
Xamarin.iOS/Xamarin.Mac versions (the `IOS_PACKAGE_VERSION` /
`MAC_PACKAGE_VERSION` variables) for the buildinfo file we put in our .NET
NuGets.
This also means we can share the same logic for all .NET platforms, instead of
having to special-case macOS.
Besides this being the correct value to put in the file (the Xamarin versions
have nothing to do with the .NET versions), it also decouples legacy logic
from .NET logic, which makes it easier to remove legacy logic when that time
comes.
The ResolveNativeReferences task would incorrectly set Kind=Framework for static
libraries and dylibs if these files came from an XCFramework in the runtimes/native
directory in a NuGet (as opposed to a binding project, or the NuGet built from a
binding project).
Fix this by properly assigning the Kind and PublishFolderType metadata for such static
libraries and dylibs.
Also add a test.
We're going to change the pack names to support multi-targeting, so ahead
of the pack name change I'm changing the existing logic to use a variable
for the pack name in most places (this will make the rename much easier and
simpler).
These changes should have no effect by themselves.
This way we always get a consistent build (at the cost of flexibility:
sometimes we won't be getting 'Microsoft.NETCore.App.Ref' updates for a while
if either dotnet/runtime or dotnet/sdk have security fixes in the works, but
this shouldn't be much of an issue for a stable .NET version, since we usually
work with any dotnet/runtime version at that point).
Also fix a duplicated entry for 'Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100',
and run 'darc update-dependencies' to update the dependencies.
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.
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230306.1
- **Date Produced**: March 6, 2023 10:15:46 AM UTC
- **Commit**: 51e06f6931e859f56564556fa6ba519761fa7141
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.2.23108.2 to 8.0.100-preview.3.23156.1][77]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4][78]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.2.23107.2 to 8.0.0-preview.3.23127.13][79]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4][78]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100-preview.2**: [from 8.0.0-preview.2.23081.3 to 8.0.0-preview.2.23113.1][80]
[77]: 5a84050...51e06f6
[78]: e71a4fb...2bdc3cb
[79]: cec7fbf...3265dc6
[80]: 1d9df33...d7ff0aa
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.2.23107.2 to 8.0.0-preview.3.23127.13 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100-preview.2**: from 8.0.0-preview.2.23081.3 to 8.0.0-preview.2.23113.1 (parent: Microsoft.NETCore.App.Ref)
* Use a separate variable for Mono's and Emscripten's manifest version band,
so that they can diverge (this is a decision from the corresponding teams,
we don't control it).
* Have a separate variable for our own manifest version band, so that it's
easier to hard code it if we want to.
* Rename a few variables to make them clearer.
* Remove hardcoded rc.2 logic, we're not using any rc.2 versions right now, so
that's dead code.
* A few other minor changes.
Dynamic libraries might be deployed in subdirectories such as libclrjit.dylib from the nuget package cefglue.common:
Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
The library ID for that library should be: @executable_path/../MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Instead of: @executable_path/../MonoBundle/libclrjit.dylib
Beside the library ID being wrong, when it's combined with the nuget package microsoft.netcore.app.runtime.osx-x64 providing a library with the same name, both uses the same `ReidentifiedPath`, which can cause a failure in the InstallNameTool tasks that are run in parallel operating on the same temporary file.
The following patch uses the `RelativePath` for the tempory file used by `InstallNameTool` so that there are no clashes with other files with the same name deployed in other directories. It also uses the `RelativePath` to create the correct library id: @executable_path/../../Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Partially fixes https://github.com/xamarin/xamarin-macios/issues/15173 for this scenario
* Use a variable for the curl command to avoid duplicating all the retry logic.
* Pass --retry-all-failures to curl to retry harder.
Hopefully fixes these errors:
curl: (56) LibreSSL SSL_read: error:02FFF036:system library:func(4095):Connection reset by peer, errno 54
make: *** [downloads/ios-release-Darwin-2a19f878dab8d2e62123e0bf29453de553f5402a.7z] Error 56
Unfortunately builds fail often in CI due to random network errors. So try to
make downloading with curl a bit more resilient by re-trying downloads a few
times before giving up.
Hopefully this will avoid random network problems with NuGet later on.
Most of the network problems seems to occur when using the system `nuget` (shipped with mono), as opposed to `dotnet restore` (implicit or explicit). This will download the packages we need using `dotnet restore`, and then the `nuget` binary will hopefully not try to look online too much (since both `nuget` and `dotnet restore` will use the same local cache).
Ref: https://github.com/xamarin/maccore/issues/2620
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.AspNetCore.App.Ref**: from 6.0.5 to 6.0.9 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: be6e1947-9e64-4217-c50e-08da52a3899f
- **Build**: 20220915.1
- **Date Produced**: September 15, 2022 7:51:35 AM UTC
- **Commit**: 1c38151cabb5771a1503aff6e5cecb435be4c69c
- **Branch**: refs/heads/release/6.0.4xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 6.0.301-rtm.22280.1 to 6.0.402-servicing.22465.1][147]
- **Microsoft.AspNetCore.App.Ref**: [from 6.0.5 to 6.0.9][148]
[147]: 283e9cf...1c38151
[148]: https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore/branches?baseVersion=GCe5f183b&targetVersion=GC3fe12b9&_a=files
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: GitHub Actions <github-actions@xamarin.com>
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 7.0.100-1.22423.4 to 7.0.100-1.22452.1 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 7.0.0-rc.2.22426.4 to 7.0.0-rc.2.22452.11 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: fa8142cc-91f4-4845-3384-08da5a845ad2
- **Build**: 20220907.11
- **Date Produced**: September 7, 2022 11:47:04 PM UTC
- **Commit**: 5b138901abdfe8f971b6df0f0593e0dc84b96879
- **Branch**: refs/heads/release/7.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.100-rc.2.22454.1 to 7.0.100-rc.2.22457.11][4]
- **Microsoft.NET.ILLink.Tasks**: [from 7.0.100-1.22423.4 to 7.0.100-1.22452.1][5]
- **Microsoft.AspNetCore.App.Ref**: [from 7.0.0-rc.2.22426.4 to 7.0.0-rc.2.22452.11][6]
[4]: 330dee3...5b13890
[5]: 313671b...5f9bfd9
[6]: 5eff673...59a0a28
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: GitHub Actions <github-actions@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Rolf Bjarne Kvinge
Alex Soto
Alex Soto
Haritha Mohan
dotnet-maestro[bot]
Andoni Morales Alastruey