Updating runtime version for tests#16271
Conversation
Change 93ec623 removed Span.NonPortableCast from System.Private.CoreLib.dll requiring tests to use an updated version of System.Memory.dll that no longer refers to it.
| updated manually whenever breaking changes require it to move forward, but it would be nice if we could update it automatically | ||
| as we do with many of the package versions above --> | ||
| <BaselineMicrosoftNetCoreAppPackageVersion>2.1.0-preview2-26124-05</BaselineMicrosoftNetCoreAppPackageVersion> | ||
| <BaselineMicrosoftNetCoreAppPackageVersion>2.1.0-preview2-26131-06</BaselineMicrosoftNetCoreAppPackageVersion> |
There was a problem hiding this comment.
How it this version number different from MicrosoftNETCorePlatformsPackageVersion ? Why can't we just use MicrosoftNETCorePlatformsPackageVersion ?
There was a problem hiding this comment.
Ok, I see. This is yet another way to mix and match bits. It is different from how we mix and match for corefx tests (#16263) so we will see different failures for it. I would nice to standardize on just one way to mix match so that we have just one configuration to worry about.
There was a problem hiding this comment.
Yeah, these scenario tests need a complete dotnet SDK to run. If this scheme was proving to be problematic my next step was likely going to assembling the shared\M.N.A\version directory using whatever scheme the test layout generator uses to build Core_Root. Its not an exact match for the real installer's shared\M.N.A\version directory but its probably close enough that the test wouldn't notice.
Change dotnet/coreclr@93ec623 removed Span.NonPortableCast from System.Private.CoreLib.dll requiring tests to use an updated version of System.Memory.dll that no longer refers to it. Commit migrated from dotnet/coreclr@7caf7f3
3 participants
Change 93ec623 removed Span.NonPortableCast from System.Private.CoreLib.dll requiring tests to use an updated version of System.Memory.dll that no longer refers to it.
This should fix the recent break that occured in JitBench CI. I'm hoping we just got unlucky that CoreCLR took a breaking change last week just as JitBench work finished up, but we'll see how often it continues to occur. Thankfully after changing the perf CI run to record logs in the failure case diagnosing the version mismatch was fairly straightforward.
PTAL @jorive