runtime: New "an operation is not legal in the current state" failures from Type.GetType

Description

After some recent dependency updates, we’re seeing occasional failures on the efcore CI. They seem so stem from this code inside a static construstor:

var appDataType = Type.GetType("Windows.Storage.ApplicationData, Microsoft.Windows.SDK.NET");

/cc @ajcvickers

Reproduction Steps

None. The failures are infrequent. The most recent one was from the OSX.1100.Amd64.Open pool on Helix.

Expected behavior

We only recently started seeing these failures.

Actual behavior

Microsoft.EntityFrameworkCore.Scaffolding.Internal.CSharpRuntimeModelCodeGeneratorTest.Sqlite [FAIL]
  System.TypeInitializationException : The type initializer for 'Microsoft.Data.Sqlite.SqliteConnection' threw an exception.
  ---- System.IO.FileLoadException : Could not load file or assembly 'Microsoft.Windows.SDK.NET, Culture=neutral, PublicKeyToken=null'. An operation is not legal in the current state. (0x80131509)
  -------- System.InvalidOperationException : Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection's state is no longer correct.
  Stack Trace:
    D:\a\_work\1\s\src\Microsoft.Data.Sqlite.Core\SqliteConnection.cs(95,0): at Microsoft.Data.Sqlite.SqliteConnection..ctor()

Regression?

Yes. This code has worked consistently for several releases.

Known Workarounds

We could safely swallow the exception. This code is not critical and is only here to make the out-of-box experience on net8.0-windows (and uap10.0) better. The user can always call sqlite3_win32_set_directory themselves.

Configuration

.NET SDK:
 Version:   8.0.100-rc.1.23407.2
 Commit:    c7045b1a4a

Host:
  Version:      8.0.0-rc.1.23402.2
  Commit:       0d6d6c3435

.NET SDKs installed:
  8.0.100-rc.1.23407.2

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.0-rc.1.23401.1
  Microsoft.NETCore.App 8.0.0-rc.1.23381.3
  Microsoft.NETCore.App 8.0.0-rc.1.23402.2

Other information

No response

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 22 (22 by maintainers)

Most upvoted comments

I don’t think there was a good netstandard2.0 API

RuntimeInformation.IsOSPlatform(OSPlatform.Windows) is netstandard2.0.

I have stepped through the resolvers registered when the test is running under debugger. There are two resolvers registered: the xunit one and the SqlClient one that you have linked to above.

I think the race condition is in the xunit resolver:

xunit registers the resolver here: https://github.com/xunit/xunit/blob/v2/src/common/AssemblyResolution/AssemblyHelper_NetCoreApp.cs#L56

The resolver calls DependencyContextAssemblyCache.LoadManagedDll here: https://github.com/xunit/xunit/blob/v2/src/common/AssemblyResolution/AssemblyHelper_NetCoreApp.cs#L84-L85

The first thing that DependencyContextAssemblyCache.LoadManagedDll does is accessing Dictionary without any locks taken: https://github.com/xunit/xunit/blob/v2/src/common/AssemblyResolution/DependencyContextAssemblyCache.cs#L156-L158