-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Update SDK #25081
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
Update SDK #25081
Conversation
|
💥 |
dougbu
left a comment
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.
Looks like the latest SDK still has problems. Or, at least it can't work on the agents we're using.
/cc @dsplaisted @marcpopMSFT @sfoslund @clairernovotny @nkolev92
|
Put another way, dotnet/sdk#12897 didn't help us. |
Are we sure that change is in this version we're grabbing? |
|
Not certain though the change was merged 4 days ago and the SDK used here is from this morning. |
|
What version of VS is being used here? The problem may be that you need 16.8.p2 to work with this sdk. @nkolev92 , does that sound right? What is their path forward until that's available? |
Shouldn't matter for the Unix machines that are failing with the same error. |
For example, from the macOS build: It appears the .NET SDK contains a breaking change that required the dotnet/arcade@f8d1331#diff-49032945af4968a76e1ae76f37234d19 workaround. We need a new Arcade SDK to get things working with a newer .NET SDK. @BrennanConroy I suggest triggering our Arcade subscription because they just promoted a new build. According to dotnet/arcade@83fda4b...56a95cc, the build includes the above workaround. |
dougbu
left a comment
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.
Withdrawing my changes request in hopes this works.
nit: I meant trigger-subscriptions not update-dependencies but am fine w/ keeping everything in this PR.
|
Looks like some extra checks have been added. I'll fix the taskcontinuationoptions, not sure about netcoreapp3.0 yet. |
|
Oops, new errors about targeting |
|
This is going to be a fun PR 😰 |
| { | ||
| var taskId = Interlocked.Increment(ref _nextPendingTaskId); | ||
| var tcs = new TaskCompletionSource<TValue>(TaskContinuationOptions.RunContinuationsAsynchronously); | ||
| var tcs = new TaskCompletionSource<TValue>(TaskCreationOptions.RunContinuationsAsynchronously); |
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.
Looks like a bunch of tests relied on this being inline instead of async
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.
Tests like Microsoft.JSInterop.Infrastructure.DotNetDispatcherTest.EndInvokeJS_WithNullValue are failing w/ expected true, got false. @pranavkm @captainsafia should we remove the async continuation, or fix up the tests?
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.
Remove https://github.com/dotnet/aspnetcore/pull/25081/files#diff-799ff3281d6420f4ff7469e3402a2d25R29 whenever this question gets answered. #25111 fixed the netcoreapp3.0 issue.
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.
ping @pranavkm @captainsafia can we get this resolved today?
|
failure is here |
|
@sfoslund @wli3 looks like there was some churn there recently, could it be related to dotnet/sdk#12897? |
|
@wtgodbe that failure likely means the version of MSBuild that's being used isn't recent enough. Is it possible you might need to update the version of xcopy-msbuild that's being used here? It's 16.5.0-alpha right now which definitely doesn't have the necessary intrinsic functions. |
Seems very possible - how can I know what a good version to use would be? @dougbu is there a strong reason we're on that particular version of xcopy-msbuild? |
|
We're using 16.8.0-preview2.1, which was generated from last Friday's dogfood, so it has all the necessary nuget and MSBuild changes. |
|
I will give that a try, thanks! |
We're not using the In fact, that version won't work at all for our builds due to our need for Microsoft.VisualStudio.Component.VC.ATL and Microsoft.VisualStudio.Component.VC.Tools.x86.x64. I tried extending the @wtgodbe your change isn't going to change anything because the build will successfully find the 16.5 VS installation and use Further, this whole conversation is about the desktop |
|
That's just because git isn't showing the PR rebased on release/5.0 correctly since the arcade update went in from a different PR.
Why not? Unless we're planning on indefinitely targeting an old SDK in 5.0, then we'll need to update it at some point and the earlier the better. |
Because we're in ask mode, the change is unreasonably painful, and moving to something other than (say) the stable / released RC1 SDK after that's out seems nice-to-have but not required. |
|
We could go for the preview8 SDK once it releases |
|
We're going to punt this work until we get the RC1 SDK: #25214 |
Hopefully this will have some changes for the ARM issue we're seeing in #24841