Exception when projecting nullable property value ("Argument Types do not match")

[hhhuut]

Description

Today I upgraded some test-projects of ours to .NET 5 to see what would break and something came up concerning nullable projections in LINQ database queries.

If found some old issues that seem to indicate that this was once a bug, namely #5522 and #5883, however I upgraded the test-projects from .NET Core 3.1, where everything worked as expected.

I also didn't find anything related to this in the breaking changes of .NET 5 nor EF Core.

Code

The essence is this piece of code in the select-part of a LINQ query:

from ...
where ...
select new MyObject
{
   // ...,
   time_public = tgv.time_public.HasValue ? tgv.time_public.Value.Ticks : 0,
   // ...,
}

where MyObject.time_public is of type long, and tgv.time_public is of type DateTime?.

I've found several workarounds, but all of them, except the first one, involve explicit casting in some form:

• time_public = tgv.time_public.Value.Ticks
• time_public = tgv.time_public.HasValue ? (long)(long?)tgv.time_public.Value.Ticks : 0
• time_public = tgv.time_public.HasValue ? (long)tgv.time_public.Value.Ticks : 0
• time_public = (long?)tgv.time_public.Value.Ticks ?? 0

I also traced with SQL Profiler and that query never makes it to the database, the exception is thrown beforehand, which seems weird to me since it could always throw after the fact if a null-value is returned, but in this scenario that would never happen anyway because that's what the HasValue check is for.

So is this a bug that was reintroduced with .NET 5? Since with .NET Core 3.1 it worked just fine and I couldn't find any documentary about this being intentional.
If it is intentional, could you give some insights into how and why, because we'd have to check and rewrite a lot of queries :/

Provider and version information

Database provider: Microsoft.EntityFrameworkCore
Target framework: .NET 5.0
Operating system: Windows 10 20H2
IDE: Visual Studio 2019 16.8.1

[smitpatel]

Duplicate of #23309

[hhhuut]

Issue is said to be fixed in .NET 5.0.1