Description:
Bug #119461 / #39328452 is listed as fixed in Connector/NET 26.7.0: "MySql.EntityFrameworkCore did not correctly translate LINQ queries that use .Contains with collection parameters. As of this release, .Contains queries with collection parameters are properly translated, preserving the appropriate element type mappings."
The fix is incomplete for one specific combination: an ARRAY of Guid. List<Guid> and HashSet<Guid> are now translated correctly, and arrays of other element types are fine, but Guid[] still throws.
Verified against:
MySql.EntityFrameworkCore 10.0.9 (assembly version 26.7.0.0)
Microsoft.EntityFrameworkCore 10.0.10
.NET 10, Windows 11
Full matrix - identical query, only the type of the local collection differs:
element type T[] List<T> HashSet<T>
------------ ---- ------- ----------
Guid FAIL OK OK
DateOnly OK OK OK
string OK OK OK
int OK OK OK
So the only failing combination is Guid[]. EF.Constant(guidArray) fails identically, since that is still an array.
Stack trace for the Guid[] case:
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.EntityFrameworkCore.Storage.Internal.TypeMappedRelationalParameter.AddDbParameter(DbCommand command, Object value)
at Microsoft.EntityFrameworkCore.Storage.Internal.RelationalParameterBase.AddDbParameter(DbCommand command, IReadOnlyDictionary`2 parameterValues)
at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.CreateDbCommand(RelationalCommandParameterObject parameterObject, Guid commandId, DbCommandMethod commandMethod)
at Microsoft.EntityFrameworkCore.Query.Internal.SingleQueryingEnumerable`1.CreateDbCommand()
at Microsoft.EntityFrameworkCore.Query.Internal.SingleQueryingEnumerable`1.ToQueryString()
at Microsoft.EntityFrameworkCore.EntityFrameworkQueryableExtensions.ToQueryString(IQueryable source)
The failure happens while binding the collection as a query parameter, before any SQL is generated. ToQueryString() alone reproduces it - no server connection, no schema and no data are required.
Because List<Guid> and HashSet<Guid> bind correctly and produce the expected SQL, the Guid element type mapping itself clearly works. The problem appears to be limited to the code path that binds an array-typed collection parameter, where the element type mapping is apparently not applied for Guid.
Expected result: Guid[] should translate exactly like List<Guid> does today, i.e.
WHERE `ExternalId` IN (@p0, @p1)
Actual result: NullReferenceException, no SQL produced.
Workaround: call .ToList() on the array before using it in the query. That is simple enough once you know it, but the symptom is a bare NullReferenceException from inside EF Core with nothing pointing at the array or at Guid, so it is quite hard to diagnose - which is the main reason I am reporting it rather than just working around it.
Note: I originally reported this as a comment on Bug #119461 (29 July 2026), at which point the failure looked broader. After retesting on 10.0.9 the remaining problem is specifically Guid[]. Since Bug #119461 is closed as fixed, I am filing this narrower case as a separate report.
How to repeat:
Self-contained console repro. No MySQL server, schema or data is needed - ToQueryString() alone triggers the failure, because it happens during parameter binding.
=== Probe.csproj ===
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net10.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="MySql.EntityFrameworkCore" Version="10.0.9" />
</ItemGroup>
</Project>
=== Program.cs ===
using Microsoft.EntityFrameworkCore;
namespace Probe;
public sealed class ProbeEntity
{
public int Id { get; set; }
public Guid ExternalId { get; set; }
public DateOnly Day { get; set; }
public string Code { get; set; } = string.Empty;
}
public sealed class ProbeContext : DbContext
{
public DbSet<ProbeEntity> Entities => Set<ProbeEntity>();
// Never actually opened - ToQueryString() only builds SQL and binds parameters.
protected override void OnConfiguring(DbContextOptionsBuilder builder)
=> builder.UseMySQL("Server=localhost;Database=probe;Uid=probe;Pwd=probe;");
}
public static class Program
{
public static void Main()
{
using var context = new ProbeContext();
Console.WriteLine($"Provider : {context.Database.ProviderName}");
Console.WriteLine($"EF Core : {typeof(DbContext).Assembly.GetName().Version}");
Console.WriteLine($"Provider assembly : {AppDomain.CurrentDomain.GetAssemblies()
.FirstOrDefault(a => a.GetName().Name == "MySql.EntityFrameworkCore")?.GetName().Version}");
Console.WriteLine();
var guids = new[] { Guid.NewGuid(), Guid.NewGuid() };
var days = new[] { new DateOnly(2026, 6, 25), new DateOnly(2026, 6, 26) };
var codes = new[] { "alpha", "beta" };
var ids = new[] { 1, 2 };
// Guid - array fails, List and HashSet work.
Run("Guid array ", () => context.Entities.Where(x => guids.Contains(x.ExternalId)).ToQueryString());
var guidList = guids.ToList();
Run("Guid List ", () => context.Entities.Where(x => guidList.Contains(x.ExternalId)).ToQueryString());
var guidSet = guids.ToHashSet();
Run("Guid HashSet", () => context.Entities.Where(x => guidSet.Contains(x.ExternalId)).ToQueryString());
// Control: arrays of other element types are fine.
Run("DateOnly array ", () => context.Entities.Where(x => days.Contains(x.Day)).ToQueryString());
Run("string array ", () => context.Entities.Where(x => codes.Contains(x.Code)).ToQueryString());
Run("int array ", () => context.Entities.Where(x => ids.Contains(x.Id)).ToQueryString());
// EF.Constant does not help - still an array.
Run("Guid EF.Constant", () => context.Entities.Where(x => EF.Constant(guids).Contains(x.ExternalId)).ToQueryString());
}
private static void Run(string label, Func<string> buildSql)
{
try
{
buildSql();
Console.WriteLine($"{label} -> OK");
}
catch (Exception ex)
{
Console.WriteLine($"{label} -> FAILED: {ex.GetType().FullName}");
Console.WriteLine(ex.ToString());
}
}
}
=== Run ===
dotnet run
=== Actual output ===
Guid array -> FAILED: System.NullReferenceException
(stack trace as quoted in the description)
Guid List -> OK
Guid HashSet -> OK
DateOnly array -> OK
string array -> OK
int array -> OK
Guid EF.Constant -> FAILED: System.NullReferenceException
=== Expected output ===
All lines OK, with the Guid array producing the same SQL as the Guid List case:
WHERE `ExternalId` IN (@p0, @p1)
Suggested fix:
Apply the same element-type-mapping logic that already works for List<T> / HashSet<T> to array-typed collection parameters, so that Guid[] gets the Guid element type mapping assigned like List<Guid> does.
Since arrays of DateOnly, string and int all work, and List<Guid> / HashSet<Guid> also work, the gap looks like a narrow one: the array path plus the Guid element type specifically.
It would also help if a missing element type mapping produced a descriptive exception instead of a NullReferenceException from TypeMappedRelationalParameter.AddDbParameter - the current symptom gives no hint about which parameter or which type is at fault.
