In theory we should define the default platform version if it's not specified
in the TFM, and this default should not change for a given .NET version:
* We release support for iOS 17.0 with .NET 8
* Apple releases iOS 18.0, we're still using .NET 8. This default continues to be iOS 17.0
* .NET 9 is shipped, and at this point we bump the default to iOS 18.0
Basically: this should be the last OS version of the platform in question when
the current major .NET version is first released to stable.
Ref: 8e6394406d/accepted/2020/net5/net5.md (os-versions)
However, this doesn't work well for Apple platforms: whenever Apple releases
new Xcode versions, our existing workloads might not be compatible with the
new Xcode. We'll of course ship updateds workload with support for the new
Xcode, but defaulting to an older target platform version would mean that
developers wouldn't get the new workload, they'd get the old one. This is
exacerbated by the fact that Apple aggressively auto-updates Xcode on
developers' machines: they might wake up one day to a broken build - the
obvious fix ("dotnet workload update") doesn't fix anything - even if we've
shipped updated workloads - because the default is to use the old one. They'd
have to manually specify the target platform version in the target platform to
get the updated workload ("net8.0-ios17.2" to use the iOS 17.2 workload
instead of "net8.0-ios", which would use the default (old/initial/17.0) .NET 8
workload) - and then update _again_ when the next Xcode comes around. At this
point the point of having a sane default value is totally out the window,
because everybody would have to specify (and continuously update) a platform
version in their project files to keep their projects building.
So we've made the decision that the default target platform version is always
the latest target platform version.
This is easier than maintaining four different template files, also there will
be significant changes in the WorkloadManifest.targets file with the upcoming
multi-targeting changes, so this makes those changes simpler.
We might actually support a newer OS version than the one we're building for,
if we're supporting a preview version in a stable release. In this case, we
need to make sure to load the correct sdk when we run into errors, so that we
show the correct error messages.
Fixes this test failure:
Xamarin.Tests.DotNetProjectTest.InvalidTargetPlatformVersion(MacCatalyst): Error message
Expected string length 92 but was 87. Strings differ at index 84.
Expected: "...ormVersion for MacCatalyst. Valid versions include:\n16.4\n17.0"
But was: "...ormVersion for MacCatalyst. Valid versions include:\n17.0"
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.
The `MicroBuildCodesignVerify@3` task has been added to validate the
signing status of the MSI files required for VS insertions. This will
allow us to identify any potential signing issues earlier.
Detect if we're using a non-stable Xcode, and in that case produce packages
that show an error if they're used and the EnablePreviewFeatures flag isn't
enabled.
Also add logic to set this flag for our own build, otherwise all our tests
would fail.
This is the same as Android does.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/18343.
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.
* 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.
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 8.0.100-1.23067.1 to 8.0.0-preview.2.23101.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-alpha.1.23076.8 to 8.0.0-preview.2.23101.7 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: from 8.0.0-alpha.1.23073.2 to 8.0.0-alpha.1.23066.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-alpha.1.23076.9 to 8.0.0-preview.2.23101.2 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230202.11
- **Date Produced**: February 2, 2023 10:28:14 PM UTC
- **Commit**: 5c7737d740c861fe7cda4822a7137c22368000dc
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-alpha.1.23077.6 to 8.0.100-preview.2.23102.11][1]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.100-1.23067.1 to 8.0.0-preview.2.23101.2][2]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-alpha.1.23076.8 to 8.0.0-preview.2.23101.7][3]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: [from 8.0.0-alpha.1.23073.2 to 8.0.0-alpha.1.23066.1][4]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-alpha.1.23076.9 to 8.0.0-preview.2.23101.2][5]
[1]: 1d88a6b...5c7737d
[2]: c790896...842ec4a
[3]: 4d75ee9...56cb24c
[4]: ff23620...5b46122
[5]: 007df05...842ec4a
Fixes this random build error:
/bin/sh: Workloads/Microsoft.NET.Sdk.macOS/WorkloadManifest.targets.tmp: No such file or directory
make[1]: *** [Workloads/Microsoft.NET.Sdk.macOS/WorkloadManifest.targets] Error 1
make[1]: *** Waiting for unfinished jobs....
The `%(Version)` metadata declared in `vs-workload.props` should always
be a four part version, this was missed when reviewing commit 9f1dc519ea.
Fix this by adding a trailing `.0` to stable branded packages.
For "Preview" branded manifest packs, the fourth part of the version
should be the commit distance (e.g. 16.1.0.5).
For "Stable" branded manifest packs, the third part of the version
should be the commit distance (e.g. 16.1.5.0).
See the following for more info on `vs-workload.props` versioning:
https://github.com/xamarin/sdk-insertions/wiki/How-to-create-a-new-insertion#msi-generation-and-vs-versioning-requirements
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>
This will hopefully make it easier to correctly subscribe to our maestro feeds
and only pick certain platforms.
It also fixes a problem where publishing wouldn't work unless we were building
for iOS, because the code was assuming that iOS was always enabled.
A `Xamarin.Shared.Sdk.MultiTarget.targets` file has been added to update
the ref/runtime pack versions associated with the .NET 6 SDK. This file
will ship as part of the .NET 7 SDK but only be imported when using the
.NET 6 SDK. This should work around the need to add new and net7
versioned aliases of the `Ref` and `Runtime` packs. Adding this file to
`AfterMicrosoftNETSdkTargets` will ensure that it is imported last,
after all `KnownFrameworkReferences` that need updating are declared.
Backport of #15834
Co-authored-by: Peter Collins <pecolli@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Attempt to improve consistency in generated workload manifest MSI versions by more closely following the four digit versioning schema used by Android and MAUI. This change should only affect preview versioned workload manifests, as stable manifest MSIs will now use the three digit NuGet package version as the MSI version.
The previous version passed to the MSI version generation task in arcade contained the commit distance twice, and now the commit distance is only used in the fourth version part.
Before:
Version="15.4.1167.1167"
After:
Version="15.4.0.1167"
Compared to Android/MAUI:
Version="33.0.0.151"
Version="7.0.0.6683"
With these changes the arcade task should weigh the time delta between builds more heavily, which should produce MSI versions that increment more consistently and by smaller amounts.
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
The build was failing with errors like:
Could not find workload 'microsoft-net-runtime-tvos' extended by workload 'tvos' in manifest 'microsoft.net.sdk.tvos'
I found I could copy the mono/emscripten workloads from 7.0.100 to
7.0.100-rc.1 to get past this.
I looked at the xamarin-android build tree, and we were doing this...
But I don't exactly remember why -- or if it was Peter or I that did it.
We must use the sdk manifest band when computing the path into sdk-manifests
to install workloads, otherwise they won't be found after installation.
This is a problem when building with .NET 6.0.301, because we want to install
into the sdk-manifests/6.0.300 directory, not sdk-manifests/6.0.301 directory.
Rolf Bjarne Kvinge
Haritha Mohan
Peter Collins
dotnet-maestro[bot]
VS MobileTools Engineering Service 2
Jonathan Peppers
Alex Soto