-
Notifications
You must be signed in to change notification settings - Fork 507
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dotnet] Implement support for building net6.0-* apps with .NET 7. Fixes #15672. #15785
[dotnet] Implement support for building net6.0-* apps with .NET 7. Fixes #15672. #15785
Conversation
We can now use these projects with a .NET 6 TFM. New commits in migueldeicaza/MonoTouch.Dialog: * migueldeicaza/MonoTouch.Dialog@558958b Revert "[MonoTouch.Dialog] Use 'BundledNETCoreAppTargetFrameworkVersion' to specify the .NET version in the project files. (migueldeicaza/MonoTouch.Dialogspouliot/Touch.Unit#261)" * migueldeicaza/MonoTouch.Dialog@8e859cc [MonoTouch.Dialog] Use 'BundledNETCoreAppTargetFrameworkVersion' to specify the .NET version in the project files. Removed commits from migueldeicaza/MonoTouch.Dialog: * migueldeicaza/MonoTouch.Dialog@eaa2202 [MonoTouch.Dialog] Use 'BundledNETCoreAppTargetFrameworkVersion' to specify the .NET version in the project files. Diff: https://github.com/migueldeicaza/MonoTouch.Dialog/compare/eaa22021dda3969a73117959a8f638f78a565690..558958b0a2de19036cf6fdd21401573a65239017 New commits in spouliot/Touch.Unit: * xamarin/Touch.Unit@564433f Revert "[Touch.Client] Use 'BundledNETCoreAppTargetFrameworkVersion' to specify the .NET version in the project files. (xamarin/Touch.Unit#113)" * xamarin/Touch.Unit@6963a2a [TouchRunner] Flush the console before exiting. Diff: https://github.com/spouliot/Touch.Unit/compare/be3a8d0855b8291848d02c9c9d99748cb41c56c2..564433f35c8ab6b7bb0709f83e1b81a89c406956
…eworks work when building with .NET 7. Fixes xamarin#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 dotnet/sdk#26384. Fixes xamarin#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
… variants in there. This way a workload restore will get the .NET 7 runtime packs.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Looks like this needs a dotnet/runtime bump first:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Fixes a string replacement related typo in the generated pack name for `Microsoft.@platform@.Windows.Sdk.Aliased.net7`.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This reverts commit de7e738.
💻 [PR Build] Tests on macOS Mac Catalina (10.15) passed 💻✅ All tests on macOS Mac Catalina (10.15) passed. Pipeline on Agent |
✅ API diff for current PR / commitLegacy Xamarin (No breaking changes).NET (No breaking changes)✅ API diff vs stableLegacy Xamarin (No breaking changes).NET (No breaking changes)✅ Generator diffGenerator diff is empty Pipeline on Agent |
❌ [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) failed ❌Failed tests are:
Pipeline on Agent |
🚀 [CI Build] Test results 🚀Test results✅ All tests passed on VSTS: simulator tests. 🎉 All 223 tests passed 🎉 Tests counts✅ bcl: All 69 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
"Backport" of #15761.
This required a few changes:
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
dotnet/sdk#26384.
There were a few other related changes:
files uses 'net6.0'. This way these projects partly work as tests.
we implement the same functionality different in .NET 7 (and they clash).
Fixes #15672.