-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Re-Bootstrap Source Build to .NET 10.0.100-alpha.1.24612.1 #45435
Conversation
Source build errors: symreader repo:
xdt repo (source-build-externals and sourcelink have similar errors):
|
Unified build errors: *_Dev_x64:
Windows_x64:
Related to dotnet/runtime#105875. This may be fixed by dotnet/aspnetcore#59389. They're still being referenced but marked as obsolete there as well. |
@jaredpar - Do the errors described in #45435 (comment) seem relevant to Roslyn? |
The Which indicates that the resource string is null. That matches up with the /cc @jaredpar |
@mthalman can you reproduec this locally? If so can you grab a compiler log and send it to me? https://github.com/jaredpar/complog?tab=readme-ov-file#creating-compiler-logs |
@jaredpar - Here's the log for the xdt repo that's failing: |
Regarding this |
For the @jaredpar - This means you don't need to investigate further. |
|
I think we'll need to reference the pack at the version that's in the SDK itself, not at the incoming (live-built) aspnetcore package version - @MackinnonBuck @javiercn do you agree? That'd mean we could have a mismatch between what's in the SDK and what would get generated by the repo build |
Would it be an option to do this conditionally? i.e., when in source build, use the version in the SDK. Otherwise, use the live-built version. It would be a big regression in dev iteration speed if we had to wait for every JS change to flow through to the SDK and back to aspnetcore. |
Yeah, I think we could condition it on |
@wtgodbe - Is this a change you plan to make? It's not clear to me where this change needs to go. |
It'll need to go in aspnetcore, I'll sync w/ Mackinnon offline & get back to you Edit: Actually, I might be wrong, will post back here when I know more Edit Edit: @MackinnonBuck put up a PR to unblock: dotnet/aspnetcore#59526 |
@wtgodbe - The unified build is passing now after syncing latest from main. So maybe nothing is needed now. |
@@ -300,7 +300,7 @@ | |||
|
|||
<!-- Get the previously-built-source-built package information from the manifest from that build. --> | |||
<ItemGroup> | |||
<_PrebuiltSourceBuiltAssetManifests Include="$(PrebuiltSourceBuiltPackagesPath)VerticalManifest.xml" /> | |||
<_PrebuiltSourceBuiltAssetManifests Include="$(PrebuiltSourceBuiltPackagesPath)*.xml" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is temporary right and was fixed in #45554? Assuming so, when will this get reverted and what is tracking that work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be reverted upon the next rebootstrap. The artifacts we target now don't have the fixed output. I'll log an issue to follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this error showed up in the Windows UB legs and I have no idea what's going on here:
@ViktorHofer - I wonder if this is fixed by #45563? It didn't start failing until I merged in 67c3a6c. |
The error hints towards a newer version of STJ being used than what's available inbox in the SDK. Just a guess. |
The calling code and the |
@dotnet/product-construction - I need some help on the issue at #45435 (comment). Here's a link to a build with this failure: https://dev.azure.com/dnceng-public/public/_build/results?buildId=900153&view=results. This was originally working in this PR but started failing after merging in 67c3a6c. I suspect a part of the reason for that is that it now references an Arcade SDK with this change: dotnet/arcade#15221. I looked at the difference between the Arcade versions being used between the previously passing run and the failing run and it's between these two commits: Another important bit of information I found is that this only seems to fail on repos (wpf, aspnetcore) that are using the |
OK the problem is the
System.Memory's 4.6.0 version must not used when not building from source, and especially not when targeting .NET Framework. I think that the updated dotnet/arcade#15353 will fix this. |
🎉🎉🎉 |
Re-Bootstrap Source Build to .NET 10.0.100-alpha.1.24612.1