Dogfood .NET6 SDK & use native SDK for Apple Silicon native builds (WIP) - #47245
Dogfood .NET6 SDK & use native SDK for Apple Silicon native builds (WIP)#47245sdmaclea wants to merge 3 commits into
Conversation
sdmaclea
added
NO-MERGE
|
Tagging subscribers to this area: @ViktorHofer Issue DetailsThis doesn't work yet.... Looking for some help... On osx-x64, I see lots of errors like this On osx-arm64 native M1 build The missing app-host looks like something is missing from the SDK and/or runtime to support I am not sure about the /cc @vitek-karas @ViktorHofer @janvorli @mangod9 @jkoritzinsky
|
|
The package Microsoft.NetCore.DotnetAppHost is missing the osx-arm64 variant (the actual package should be called |
|
The apphost appears to be present |
|
Thanks @vitek-karas I'll looks for that code. |
|
/cc @Anipik |
|
Is it possible that the KnownFrameworkReference for the apphost pack hasn’t had its RuntimeIdentifiers list updated to include osx-arm64 in the SDK. |
|
@jkoritzinsky There are a lot of places where osx-arm64 is missing in src/installers. I am working on a PR. |
|
In case it is not clear the |
|
The update that I mentioned might be needed would be in dotnet/sdk. |
|
@jkoritzinsky I don't see any relevant |
|
It looks like what I thought might be the issue has already been handled. |
There was a problem hiding this comment.
You don't intent do commit the SDK update, right?
There was a problem hiding this comment.
I didn't intend to commit this PR. It was more of an experiment to see if the .NET 6 SDK would work (especially on native Apple Silicon because NET 5 doesn't support Apple Silicon native.)
@jkoritzinsky has suggested we might commit something like this to solve the crossgen2 issues @trylek is working on.
748fbda to
435d98d
Compare
|
Thanks to @jkoritzinsky, this version of the PR, the osx-arm64 build has similar symptoms to other builds. For some reason, the element: is causing the /Users/stmaclea/git/runtime/src/libraries/System.Security.Cryptography.X509Certificates/src/System.Security.Cryptography.X509Certificates.csproj :
error NU1012:
Platform version is not present for one or more target frameworks, even though they have specified a platform: net6.0-unix, net6.0-osx, net6.0-ios, net6.0-tvos [/Users/stmaclea/git/runtime/Build.proj]
Failed to restore /Users/stmaclea/git/runtime/src/libraries/System.Security.Cryptography.X509Certificates/src/System.Security.Cryptography.X509Certificates.csproj (in 20 ms).I guess I don't know how it works. I tried targeting |
|
Assume there are no concerns with upgrading the sdk? Given that preview1 is now forked would be ideal to start consuming those bits in main. |
|
Please note that upgrading the SDK to its current main won't solve the CG2 framework compilation in its entirety. As Viktor pointed out on the framework switch-over PR thread, limitations of the current implementation in the SDK repo forced me to use hacky constructs like globally exposing the |
|
ok thats fair. So please update when the sdk changes are done. Would we want to port the changes to preview1 to pick that sdk build? |
|
We definitely would not want to use a random nightly SDK build. I assume porting the change to preview1 is already too late so I would assume the next applicable one would be preview2 which will take at least another month. That said, maybe we can still get Tomas's change into P1, that would be fantastic. |
|
if the sdk fix is straight forward might be good to get that into p1 so we can get that integrated. |
435d98d to
700b9ec
Compare
Updated the runtime reference to use the latest preview1 candidate. @Anipik If you have a chance it would be nice to see this working correctly with the preview1 candidate. |
sure i will take a look |
|
ping @Anipik |
|
@ViktorHofer @sdmaclea i fixed the failure here. |
|
I never would have found that, thanks @Anipik |
welcome :) |
|
Looks like
|
|
@ViktorHofer the 6.0 sdk is required for crossgen2 work as well, since 3/1 is still a few weeks away, is there concern about getting it integrated before then (assuming all issues are resolved)? |
|
Updating the minimum required SDK is defined as a breaking change and needs to go through a monthly rollout. Unfortunately there is no way around that. Another thing to be aware of is that we don't want to depend on a non publicly released SDK as the minimum supported version. There is a document about this in Arcade which I can't find right now. As 6.0 Preview 1 isn't released yet, it will probably just be a few days between that SDK being released and March 1st. Hope that is helpful... |
|
Ok thanks for the context, will check with @trylek and if this is going to cause too much of a delay we might have to ask for an exception. |
|
Hmm, this is complicated. What I'm getting out of this discussion is as follows:
Based on similar arguments, we'll only be able to further roll forward the SDK drop to Preview2 (containing my change currently in progress) only after Preview2 has shipped. Perhaps we'll again need to sync up with the monthly infra rollout cadence. Long story short, not ideal, we would to wait for SDK CG2 switchover until something like Preview 4 or so which is way too long. In light of this I believe we need a stopgap solution. I'll go over my current CG2 SDK PR and I'll try to figure out whether there's an easy way to address Viktor's concerns to let us use the existing SDK for the time being and move forward with testing, perf / size measurements and ASP.NET switchover. Once the newer SDK lights up, all that will remain is a small mop-up change to clean up some of the scripts using the new SDK functionality. |
ghost
locked as resolved and limited conversation to collaborators
7 participants
This doesn't work yet.... Looking for some help...
I see lots of errors like this
I am not sure about the
osx-x64error, but it might also be a SDK issue./cc @vitek-karas @ViktorHofer @janvorli @mangod9 @jkoritzinsky
Experiment related to #46960