Update to xunit.runner.visualstudio 3.1.1 #79343
Conversation
Address changes from dotnet/sdk#49248.
| This version needs to match the Test SDK version consumed by Arcade. | ||
| --> | ||
| <MicrosoftNETTestSdkVersion>17.5.0</MicrosoftNETTestSdkVersion> | ||
| <MicrosoftNETTestSdkVersion>17.13.0</MicrosoftNETTestSdkVersion> |
There was a problem hiding this comment.
@NikolaMilosavljevic - we need to take this test platform update because otherwise our tests will stop running in CI (see dotnet/sdk#49248)
I don't understand what the comment above means - is this going to break anything in the VMR (based on the git blame it looks like you introduced it)
There was a problem hiding this comment.
will stop
Correction: have stopped
There was a problem hiding this comment.
we need to take this test platform update because otherwise our tests will stop running in CI
I'm surprised that this update is required for running tests. I think updating xunit.runner.visualstudio should just be sufficient. At least the issue when I investigated for aspnet core was xunit.runner.visualstudio 2.x relying on specific behavior in deps.json that .NET SDK broke, but then .NET SDK special cased xunit back again. https://github.com/dotnet/sdk/blob/460bff1c9e39948a9620f2216f428d60751395ec/src/Tasks/Microsoft.NET.Build.Tasks/DependencyContextBuilder.cs#L374-L375
If you started consuming newer SDK with the hack above, it should also just work.
It's still a good idea to update both packages for sure. But I mean, you could keep Microsoft.NET.Test.Sdk separately.
There was a problem hiding this comment.
No, we cannot. xunit.runner.visualstudio depends on Microsoft.TestPlatform.ObjectModel (>= 17.13.0) on framework.
There was a problem hiding this comment.
Oh, I didn't realize xunit's dependency.
Will follow up with an issue but disabling for now to see if this unblocks the CoreCLR tests
This `Assert.False` call was executing directly an a thread pool thread. That meant when it triggered it was an unhandled exception on a TPT which crashes the process. The calling code already fails the test when this happen hence changed this to just output the failure info to the test logs.
|
/azp run roslyn-CI |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| throw new InvalidOperationException(); | ||
|
|
||
| var xunitUtilities = AppDomain.CurrentDomain.GetAssemblies().Where(static assembly => assembly.GetName().Name.StartsWith("xunit.runner.utility")).ToArray(); | ||
| var xunitUtilities = AppDomain.CurrentDomain.GetAssemblies().Where(static assembly => assembly.GetName().Name.StartsWith("xunit.runner.visualstudio")).ToArray(); |
There was a problem hiding this comment.
Should we fail if this assembly doesn't exist to simplify catching this type of break in the future?
|
Merging, this fixes regular CI. Integration CI is still under investigation, but we may re-open the branches first. |
7 participants
Address changes from dotnet/sdk#49248.