xamarin
/
xamarin-macios
зеркало из
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-macios/dotnet/targets/Microsoft.Sdk.Versions.temp...

33 строки
1.3 KiB
Plaintext
Исходник Обычный вид История

[dotnet] Templateify some build logic. (#10618) * [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.
2021-02-11 22:17:12 +03:00
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CurrentBranch>@CURRENT_BRANCH@</CurrentBranch>
<CurrentHash>@CURRENT_HASH_LONG@</CurrentHash>
<_ShortPackageVersion>@NUGET_VERSION_NO_METADATA@</_ShortPackageVersion>
<_PackageVersion>@NUGET_VERSION_FULL@</_PackageVersion>
[dotnet] Stop using a separate default platform version. (#19754) 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: https://github.com/dotnet/designs/blob/8e6394406d44f75f30ea2259a425cb9e38d75b69/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.
2024-01-09 11:47:07 +03:00
<_XamarinTargetPlatformVersion>@TARGET_PLATFORM_VERSION@</_XamarinTargetPlatformVersion>
[net8.0] [build] Require using EnablePreviewFeatures=true when using preview releases. Contributes towards #18343. (#18476) 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.
2023-06-22 09:16:50 +03:00
<_XamarinIsPreviewRelease>@XCODE_IS_PREVIEW@</_XamarinIsPreviewRelease>
[dotnet] Store the .NET version we target in a generated props file. (#19416) This way we can avoid hardcoding the .NET version later in the build targets.
2023-11-10 14:08:24 +03:00
<_XamarinDotNetVersion>@DOTNET_TFM@</_XamarinDotNetVersion>
[dotnet] Templateify some build logic. (#10618) * [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.
2021-02-11 22:17:12 +03:00
</PropertyGroup>
[dotnet] Generate an itemgroup with the valid runtime identifiers and use it to detect invalid runtime identifiers. (#13484) This way we don't have to update the runtime identifier validation when we add support for new runtime identifiers. We'll also have an item group that lists the valid runtime identifiers, which is making it possible (although the item group is currently private) to query the valid runtime identifiers (which is something the IDEs have expressed interest in).
2021-12-03 09:57:08 +03:00
<ItemGroup>@VALID_RUNTIME_IDENTIFIERS@
</ItemGroup>
[dotnet] Rework KnownFrameworkReference so that 'net6.0-*' TargetFrameworks work when building with .NET 7. Fixes #15375. 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
2022-06-30 14:04:04 +03:00
<!-- Declare the XI/XM framework bundled with this version of the SDK. See Microsoft.NETCoreSdk.BundledVersions.props -->
<ItemGroup>
<KnownFrameworkReference
Include="Microsoft.@PLATFORM@"
TargetFramework="@DOTNET_TFM@"
RuntimeFrameworkName="Microsoft.@PLATFORM@"
DefaultRuntimeFrameworkVersion="@NUGET_VERSION_NO_METADATA@"
LatestRuntimeFrameworkVersion="@NUGET_VERSION_NO_METADATA@"
[net8.0] Revert multi-targeting support. (#19145) It turns out to have a few sharp edges we need to smooth out first.
2023-10-10 18:20:09 +03:00
TargetingPackName="Microsoft.@PLATFORM@.Ref"
[dotnet] Rework KnownFrameworkReference so that 'net6.0-*' TargetFrameworks work when building with .NET 7. Fixes #15375. 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
2022-06-30 14:04:04 +03:00
TargetingPackVersion="@NUGET_VERSION_NO_METADATA@"
[net8.0] Revert multi-targeting support. (#19145) It turns out to have a few sharp edges we need to smooth out first.
2023-10-10 18:20:09 +03:00
RuntimePackNamePatterns="Microsoft.@PLATFORM@.Runtime.**RID**"
[dotnet] Rework KnownFrameworkReference so that 'net6.0-*' TargetFrameworks work when building with .NET 7. Fixes #15375. 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
2022-06-30 14:04:04 +03:00
RuntimePackRuntimeIdentifiers="@RUNTIME_PACK_RUNTIME_IDENTIFIERS@"
Profile="@PLATFORM@"
/>
</ItemGroup>
[dotnet] Templateify some build logic. (#10618) * [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.
2021-02-11 22:17:12 +03:00
</Project>