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.
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 7.0.3 to 7.0.4 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: fffd7604-ce46-455f-0f2f-08db24524baf
- **Build**: 20230320.23
- **Date Produced**: March 21, 2023 6:36:46 AM UTC
- **Commit**: 332c2bc24954c8305a1985bd8e52088cc6b6a677
- **Branch**: refs/heads/release/7.0.2xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.105-servicing.23165.29 to 7.0.203-servicing.23170.23][8]
[8]: f7fbfe4...332c2bc
Encode the .NET version we're targeting in the third NuGet version number by
adding X000 (where X is the .NET version) to the commit distance.
This accomplishes a few goals:
* We automatically compute a different NuGet version depending on the .NET version we're targeting.
* Versions are sorted correctly (.NET 7 nugets have a higher version number than .NET 6 nugets).
* It's possible to see which .NET version a NuGet is targeting from the version.
The downside is:
* The scheme breaks down if we need more than three digits for the commit
distance (possible solution: add another zero, so we add X0000 instead of
X000).
* 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.
We need to use 'DOTNET_MANIFEST_VERSION_BAND' instead of
'DOTNET_VERSION_BAND', because the former always ends with '00' (which
manifest version bands are supposed), while the latter can have other numbers
(for instance 7.0.100 vs 7.0.101 - the former is a valid manifest version
band, the latter isn't).
Use a make template for the build logic for our platform assemblies, so that we don't
unintentionally have slightly different build code for different platforms (especially
when making changes to the build this way ensures that we make the same change on all
platforms).
This also makes the code significantly shorter, and will make it easier to add more
platforms in the future if we ever need that.
The script does the same thing, except:
* It doesn't use 'bc', but instead bash's intrinsic math support: '$((1+2))' -
because when we execute in bash on Windows, 'bc' might not be available.
* It's easier to debug.
This fixes a problem when we need to compute these values on Windows in CI.
Update the download of API references to:
* Use `dl.internalx.com` links instead of `bosstoragemirror.blob.core.windows.net`
links (the relative path stays the same).
* Require a GitHub PAT in order to download from dl.internalx.com. This PAT
can either be provided through a file (recommended for local use) or through
the environment.
* Document these changes.
Stable MSIs are versioned like non-stable MSIs, except that:
* We define the commit distance as the number of commits since the branch
bacame a release branch (and started using stable branding). Technically
this is the number of commits since the `NUGET_RELEASE_BRANCH` variable
changed (which will be incorrect for non-stable branches, but in that case
we shouldn't use this number in those scenarios).
* We use the above-mentioned commit distance as the third number in the MSI
version (as opposed to the fourth number in non-stable branches.)
Note: we detect if we're building a stable release by checking if the
`NUGET_PRERELEASE_IDENTIFIER` is empty (we can't use `NUGET_RELEASE_BRANCH`,
because this variable will be set for PRs to the release branch, while
`NUGET_PRERELEASE_IDENTIFIER` will only be empty for CI builds from a stable
branch).
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 7.0.0-rtm.22479.3 to 7.0.0-rtm.22512.1 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: df408977-ead8-4cfb-e40b-08dab20af502
- **Build**: 20221019.39
- **Date Produced**: October 20, 2022 12:51:36 AM UTC
- **Commit**: e6dd91c290b808f971a1ac69c2fb29395bbf1051
- **Branch**: refs/heads/release/7.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.100-rtm.22479.5 to 7.0.100-rtm.22519.39][3]
- **Microsoft.AspNetCore.App.Ref**: [from 7.0.0-rtm.22479.3 to 7.0.0-rtm.22512.1][4]
[3]: eb23d8c...e6dd91c
[4]: 02d62cf...c686535
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>
Current versions in this branch:
Microsoft.iOS 16.1.1419-net7.0-xcode14.1+sha.51ad25e7b64
Microsoft.tvOS 16.1.1419-net7.0-xcode14.1+sha.51ad25e7b64
Microsoft.MacCatalyst 16.1.1419-net7.0-xcode14.1+sha.51ad25e7b64
Microsoft.macOS 13.0.1974-net7.0-xcode14.1+sha.51ad25e7b64
Compare with the `release/6.0.4xx-xcode14.1` branch version numbers (from #16431):
Microsoft.iOS 16.1.179+sha.2107639a131
Microsoft.tvOS 16.1.179+sha.2107639a131
Microsoft.MacCatalyst 16.1.179+sha.2107639a131
Microsoft.macOS 13.0.734+sha.2107639a131
the buffer is >1000 commits.
* It's wrong once in a while because of network hiccups.
* Building mono from source takes a long time.
* Building mono from source doesn't even seem to work anymore.
So just remove the automatic detection. If someone ever wants to build mono
from source again, then it can be enabled using 'configure'.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* 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
This makes it possible to run xtro consistently when not all platforms are
enabled.
Fixes https://github.com/xamarin/xamarin-macios/issues/12769.
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
We don't need legacy Xamarin builds in .NET 7, so this will hopefully speed up
our builds (and posterior signing) significantly.
This change should not be merged back into main.
Rolf Bjarne Kvinge
Alex Soto
dotnet-maestro[bot]
Manuel de la Pena
VS MobileTools Engineering Service 2