Pull in MAUI repo(s) in order to source-build MAUI manifest nupkgs #3242
Comments
dotnet-issue-labeler
bot
added
area-additional-repos
directhex
added
the
area-prebuilts
MichaelSimons
removed
area-prebuilts
|
[Triage] @directhex - is this something on your radar to fix in the 8.0 timeframe? |
|
Note to self: this current behaviouir results in a functional difference between a source-built SDK and a non-source-built SDK. Edit: As of Preview 6, the following 5 workloads are missing in a source-build SDK:
|
|
@MichaelSimons I'm prioritizing getting emsdk/wasi-sdk fully built from source, I'm not sure if I'll get time to work on much else in time. |
|
ping :) |
|
I'm highly interested in this. This looks like a bug to the end user. |
Context: dotnet/source-build#3242 If using a source-built .NET SDK, the Android workload manifests are not included in the SDK. So, you won't see `android` workload when you run `dotnet workload search`. The Android workload, in general, contains private sources, but the manifest files are completely public. In the long run, we could consider onboarding dotnet/android to: * https://github.com/dotnet/source-build/blob/main/Documentation/sourcebuild-in-repos/new-repo.md But the prerequisites would be to first have the Android workload onboard to arcade: * https://github.com/dotnet/arcade/blob/main/Documentation/Onboarding.md *For now*, we could include the Android workload in source-build by: * Add a step that copies the Android workload manifests source code in-tree (to be used when updating manifests). * Commit the manifest sources. * Source-build will then include the Android workload manifests in the SDK by using the source code, in-tree.
|
This is a serious issue. Is there any workaround for momentarily use, as it prevents installation of such workloads on macOS (and some other UNIX-based OS I assume)? |
|
@TheBlackPlague on macOS you can install dotnet from https://dotnet.microsoft.com/download to get the workload support. If you're using homebrew make sure to use |
|
A year and a half later and it's still unresolved. This is a serious issue. For all the people ending up here after investigating the issue, there should be clear workarounds. How can I work-around this issue on Arch-based Linux? |
|
The only know workaround is to use the scripted install |
We've now excluded the manifest prebuilts from the
installerbuild, where those manifests don't come from source-build itself. We've also pulled inemsdkto generate some manifests from that repo, and rejiggledruntimeto emit runtimes on non-mobile builds. The last set of manifests we need to worry about are the conditional ones onsrc/redist/targets/BundledManifests.targets:Of those six, most of them come from https://github.com/xamarin/xamarin-macios, one from https://github.com/xamarin/xamarin-android, and the final one from https://github.com/dotnet/maui
The text was updated successfully, but these errors were encountered: