dotnet
Move to .NET 10 P5 SDK and Arcade 10 SDK
Restores the previous move to .NET 10 P5 changes and brings in Arcade 10 SDK.
Targets a specific build of Arcade 10 SDK because later builds introduce bootstrap failures.
It looks like there are some package version issues in the correctness leg
Correctness_Bootstrap_Build_Default is also deeply broken, there are almost 150k lines of "System.Object not defined" type of errors, despite the restore seemingly not reporting any complaints.
We have some RPS counters in a recent insertion which require more data to decide if there is a real problem or not. I would like to wait to see if our upcoming build inserts cleanly, before taking this. Thanks! https://dev.azure.com/dnceng/internal/_build/results?buildId=2733703&view=results
![azure-pipelines[bot] avatar](https://avatars.githubusercontent.com/in/9426?v=4 "Published by a pub.dev verified publisher"){kind=small}
@JoeRobich are you able to reprooduce this failure locally? There is not really any info to go off of in the test run that I could see.
@JoeRobich are you able to reprooduce this failure locally? There is not really any info to go off of in the test run that I could see.
I have not been able to run integration tests locally. Trying to workout what is going on with my DevBox.
I have looked at the Screenshots artifacts from the failing run and see that the locale seems to be misconfigured during the CSharpInteractive WorkspaceClearedAfterReset test. It is expecting "Stack overflow." Since the test is checking error strings in this way it should be using the UseCultureAttribute.
In BasicRename we have a test failing due to the cursor not moving to the end of the identifier after a rename. In NewDocumentFormatting we have a test failing because the Error List is not clearing when a new project is opened.
I had moved the CI image to use the scouting queue meaning 17.14.7. I've reverted that change to see if these issues exist when running on 17.14.5.
OK, so more failures on 17.14.5.
Looking at BasicRename and it seems like the cursor location is a known problem that we tried to work around. TrueException is a XunitException so not sure why this isn't working for us.
https://github.com/dotnet/roslyn/blob/334d4c7ade78170d7b06448a2807627ddb96d742/src/VisualStudio/IntegrationTest/New.IntegrationTests/VisualBasic/BasicRename.cs#L384-L403
Still seeing the Interactive test fail as in https://github.com/dotnet/roslyn/pull/78925#issuecomment-3047666194 even with the UseCulture("en-US") attribute. It makes me think the interactive is running OOP and may not share the locale of the process that launched it. @tmat
@JoeRobich Any idea why would the behavior be different now?
Perhaps these VM images have the system culture set differently. I know for both the LSP and BuildHost we pass along locale so that logging matches the process that launched them.
We do that as well here: https://github.com/dotnet/roslyn/blob/aafd6ebe5e8d2ced7ed7b8c59158ee0103d4a93a/src/Interactive/Host/Interactive/Core/InteractiveHost.LazyRemoteService.cs#L64
We do that as well here
@tmat I was sure hoping we did. =) Unfortunately that makes what we are seeing even more bizarre. I don't know what explains this