Could not load type 'SqlGuidCaster' from assembly Microsoft.Data.SqlClient

[Alerinos]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Error:

System.Reflection.ReflectionTypeLoadException: „Unable to load one or more of the requested types.
Could not load type 'SqlGuidCaster' from assembly 'Microsoft.Data.SqlClient, Version=5.0.0.0, Culture=neutral, PublicKeyToken=23ec7fc2d6eaa4a5' because it contains an object field at offset 0 that is incorrectly aligned or overlapped by a non-object field.”

Code:

    public static IEnumerable<Assembly> GetAssembliesWithTypesImplementing<T>()
    {
        return AppDomain.CurrentDomain.GetAssemblies()
            .SelectMany(assembly => assembly.GetTypes())
            .Where(type => !type.IsAbstract && typeof(T).IsAssignableFrom(type))
            .Select(type => type.Assembly)
            .Distinct();
    }

line:
assembly.GetTypes()

The error appeared after upgrading from .net 7 to .net 8 preview 1.
I searched and I don't have such Microsoft.Data.SqlClient package installed

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[Wraith2]

Even if you aren't using it directly you must have a transitive reference to Microsoft.Data.SqlClient (probably through EFCore) in order to have it present in the assembly list. So can you provide the minimal reproduction that can be debugged which exhibits this problem?

[lcheunglci]

Hi @Alerinos Could you provide us with a sample repro? The provided code snippet is not enough information for us to investigate.

[Alerinos]

@Wraith2 @lcheunglci
I was able to reproduce the problem, here is the repo:
https://github.com/Alerinos/SQLError
Error:

[Alerinos]

@lcheunglci Let me know if there is a problem, if so is there a quick workaround? The problem occurs only on .net 8 in .net 7 everything is fine.

[Wraith2]

Ok. that's interesting. The problem isn't in SqlClient it's to do without how object layouts are computed in the Jit. It looks like a class that's laid out safely in 7 is now not safe in 8. Since 8 is still in very early preview this isn't a pressing problem but i'll see if i can find the people who might know what to do.

[Wraith2]

@David-Engel @MichalPetryka this is a result of the runtime optimization in dotnet/runtime#72549 which came from a suggestion on my new apis proposal dotnet/runtime#51836 (comment)

We've got a situation where the runtime was previously using struct SqlGuid{ byte[] _value; } and that has changed to struct SqlGuid{ Guid? _value; }. overlaying a struct with ref types in the same position was unsafe and icky but supported. In NET8 this changes to trying to overlay a value type and a ref type which is entirely illegal and causes the type loader to abort the assembly load.

I'm not sure of a good way to fix this. We can't detect the right pattern to use at runtime because we cannot have the old pattern in the assembly, the type loader will reject it.
If we choose to fix this only for net8 then we must have a day 1 build of SqlClient available to users when net8 launches or we prevent early adopters from using EFCore and NET8 which is a very poor PR look for this library.

[David-Engel]

@Wraith2
Well that's unfortunate. I thought we would be safe dynamically determining if we can call the new APIs at runtime, leaving the old SqlGuidCaster in there. If we create a .NET 8 target in the package to split it out, that would fix the problem, right? I had planned for us to do that later this year, but we might have to prioritize it sooner.

[Wraith2]

As long as no-one tries to load the non-8 assembly on 8 it should be ok. That would mean you can't take a <8 framework dependent install and run it on >= 8 but I'm not sure how important that scenario is.

I'd be nice to see if there's some way to have the <8 assembly work on 8 even if it was slow but i don't know how possible or performant that would be.

[David-Engel]

I forgot we left the hacky way in for .NET Core. It was significantly faster than the reflection method for the SqlTypeWorkarounds. So we have a couple of choices. Leave the hacks for < 8 and prioritize creating an 8+ assembly, or switch to reflection and take the perf hit to retain .NET 8 compatibility. Then we can add an 8+ assembly a little later and regain perf (on 8+ only) via the new SqlTypes APIs.

Edit: It was actually that the internal methods were stripped from .NET during the build and not available to even call via reflection. So perf would be even worse than I thought via the existing public APIs.

#1647